Nowadays systemd prefixes all the arguments it reads from /proc/cmdline. This is the correct approach, the kernel owns it's own cmdline, and if other components want to use it they should namespace themselves.
It may be Stockholm Syndrome but I have come to appreciate systemd-style unit files for services. Being able to say "here's the binary, run it as this user, restart it if it exits" beats copying & tweaking bash scripts which is how I dimly remember sysv init working. Doubtless other more recent init systems have similar capabilities.
Anything to do with systemd logging is a goddamn nightmare though. It loves to tell you that a service has failed to start, but doesn't try to do anything like show you stderr from the process that might help debug.
Debugging is harder until you get used to systemd but otherwise it's a great improvement over sysvinit. The biggest issue I have is that it's apparently not well-supported inside containers and people recommend supervisord instead.
> It makes logging harder.
journalctl -u or tail your daemon's log file
> The documentation stinks.
It's actually pretty decent, and once you dig through it a lot of the unit file properties are genuinely useful and solve real problems that shell scripts can't deal with.
> It inserts bizarre delays.
Like what? Nowadays all distros boot pretty fast with it.
16 comments
[ 2.4 ms ] story [ 44.1 ms ] threadIt apparently still interprets the global "debug" flag as well: https://www.freedesktop.org/software/systemd/man/systemd.htm...
Systemd's primary selling point is that it has already convinced distros to use it.
It inserts bizarre delays.
It makes debugging harder.
It makes logging harder.
The documentation stinks.
It infects other systems (libvirtd, GNOME) and convinces them that SystemD is a necessary dependency.
In short: SystemD doesn't play well with others. It is not a good citizen.
Anything to do with systemd logging is a goddamn nightmare though. It loves to tell you that a service has failed to start, but doesn't try to do anything like show you stderr from the process that might help debug.
It does, actually.
...prints out the last few lines of the service log. ...shows you all the logs. You can jump to the bottom if you want and start debugging right away.> It makes logging harder.
journalctl -u or tail your daemon's log file
> The documentation stinks.
It's actually pretty decent, and once you dig through it a lot of the unit file properties are genuinely useful and solve real problems that shell scripts can't deal with.
> It inserts bizarre delays.
Like what? Nowadays all distros boot pretty fast with it.
journalctl is a terrible interface.
As for delays: you've never seen "waiting for [thing]... 5 min 30s" before? You're lucky.