4 ms·
Actually, systemd is pretty awesome for servers. I wrote a simple program that outputs to stdout and ran it under systemd. * it automatically cares about sta
by LeonidasXIV 12y ago
Actually, systemd is pretty awesome for servers. I wrote a simple program that outputs to stdout and ran it under systemd.
* it automatically cares about starting it
* it automatically puts the programs stdout into the journal (from which I can filter the output of my specific program without having to syslog() everything)
* it allows me to run the program as user with one line in the INI unit file
* it allows to make the users home directory read-only (or even inaccessible), so in case someone takes over, there is only so much they can break
* it can create a private /tmp for my program
Actually, for desktops I don't care but for servers systemd is pretty awesome.
- Zancarius 12y agoYou hit on some of the points that won me over when I first started using systemd. Writing services is easy and logging their output is a breeze. Not having to fret with supervisor processes or daemonizing code shifts some of the complexity out of the application and into the init process[1] where I'd argue process management ought to live. Given that targeting sysvinit for all the various sysvinit-compatible systems out there can be an exercise in frustration (OpenRC, Debian, the *BSDs, all of whom have subtly different flavors for starting and stopping processes) better left to individual maintainers, it's nice that I can write a unit file and pretty much have it work on any system that's running systemd. [1] I'm aware that some people might argue additional complexity doesn't belong in an init. That's fine. You're probably right.
- 23david 12y agoAnd if there is a situation where your program is acting wonky, what non-systemd command can you use from the shell prompt to debug and reproduce exactly what systemd is doing?