4 ms·
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 abst
by 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 agoSurely 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?