3 ms·

I despise systemd. Having shell scripts that you can read and edit makes so much more sense. Putting a script in a directory to have it run at startup makes s

by Timja 4y ago

I despise systemd. Having shell scripts that you can read and edit makes so much more sense. Putting a script in a directory to have it run at startup makes sense. Systemd's approach of "registering a service" is hell. Having logs in plain text is beautiful. Having to use special software to read logs is hell.

Octabrain 4y ago
You can still have your wonderful script but in the case of systemd, you delegate the execution lifecycle of that script to a unit, which, IMHO, is a great abstraction compared to the mess of having to deal with the status of the service from the script itself. You simply throw the unit file into directory, then enable it. Your script does its thing, systemd deals with when to run it, in which runlevel etc About the logs, yes, plain text files, commands and pipes are great, but journalctl is really great too. It is powefull and includes everything you might need to inspect logs with accuracy in the same tool. Just to clarify: I'm not a fanboy, I'm just pragmatic.
- lakomen 4y ago
  > journalctl is really great too until you're forced to run a rescue system without systemd and try to read logs. And don't say that it doesn't happen, because that situation is 99%.
  - fullstop 4y ago
    Surely the answer here is to add tools to the rescue system. You could make the same complaint with systems that use file systems not yet supported in rescue systems, such as zfs, btrfs, etc. Why would you limit what can be done based on the current abilities of a rescue system?
tenebrisalietum 4y ago
So I think systemd is becoming a tentacle demon upon Linux but "registering a service" is not hell. - You create a new whatever.service text file with some data=value pairs and put it in /etc/systemd/system. Doing this is at least only 25% as hard as learning bash. - systemctl daemon-reload - systemctl start whatever.service Not hard.

by Timja 4y ago

Octabrain 4y ago

You can still have your wonderful script but in the case of systemd, you delegate the execution lifecycle of that script to a unit, which, IMHO, is a great abstraction compared to the mess of having to deal with the status of the service from the script itself. You simply throw the unit file into directory, then enable it. Your script does its thing, systemd deals with when to run it, in which runlevel etc About the logs, yes, plain text files, commands and pipes are great, but journalctl is really great too. It is powefull and includes everything you might need to inspect logs with accuracy in the same tool. Just to clarify: I'm not a fanboy, I'm just pragmatic.

lakomen 4y ago
> journalctl is really great too until you're forced to run a rescue system without systemd and try to read logs. And don't say that it doesn't happen, because that situation is 99%.
- fullstop 4y ago
  Surely the answer here is to add tools to the rescue system. You could make the same complaint with systems that use file systems not yet supported in rescue systems, such as zfs, btrfs, etc. Why would you limit what can be done based on the current abilities of a rescue system?

tenebrisalietum 4y ago

So I think systemd is becoming a tentacle demon upon Linux but "registering a service" is not hell. - You create a new whatever.service text file with some data=value pairs and put it in /etc/systemd/system. Doing this is at least only 25% as hard as learning bash. - systemctl daemon-reload - systemctl start whatever.service Not hard.