That's actually pretty neat. I don't have any real complaints about systemd, but every alternative I've looked at is more painful to use for service management. No longer having to hack together init scripts has been wonderful for me, it took a 10 line unit file to get YouTrack configured as a proper service on my CentOS 7 VM - I used to run JetBrains teamware products on Windows just because dealing with custom init scripts was such a pain in the ass.
> it took a 10 line unit file to get YouTrack configured as a proper service on my CentOS 7 VM
If you did it the way that other people have done it, wrapping youtrack.sh start and youtrack.sh stop in a systemd service unit, with a sprinkling of erroneous Type=forking to get around the fact that that ends up running the Java process as a quickly orphaned grandchild of where systemd expects the daemon to be, and with log output explicitly redirected away from where service management could handle it into an ever-growing private log file under /usr ... then you have entered systemd House of Horror territory. "proper" is not really the word.
I initially tried the Type=forking method, but systemd kept yelling at me (as it should have) because it doesn't really fork correctly. I actually just run the service in simple mode with a launcher script that contains this abomination of a command:
Just remember to do things the daemontools way, and chain to the final daemon binary from that script with the shell's exec command, and systemd should be happy.
That's actually pretty neat. I don't have any real complaints about systemd, but every alternative I've looked at is more painful to use for service management. No longer having to hack together init scripts has been wonderful for me, it took a 10 line unit file to get YouTrack configured as a proper service on my CentOS 7 VM - I used to run JetBrains teamware products on Windows just because dealing with custom init scripts was such a pain in the ass.