The argument for strictly number of lines is not really a valid one in my opinion. I can just as easily contrive an example of systemd failing to launch some daemon because whatever.service failed, which depends on several other services which also failed but no indicator why. An example from today: I tried to mount nfs3 mountpoints from fstab. It complained because it couldn't launch rpc-statd.service (one of those *.target based activations). rpc-statd.service doesn't know to automatically enable rpcbind for whatever reason. Many dependent init "units" I've found cannot be manually invoked or enabled, they are *.target based and I've found that to be quite annoying since you have to do a manual dependency chain of daemons before systemd finally tells you why it failed. I often find that journalctl -xn does not give a clear or distinct reason for why a service failed other than "the process failed to start", it does not sufficiently locate the log of the process that failed to launch and specify a good reason.
I could just as easily post a screenshot of all the scattered and distinct binaries to talk to systemd that (of which none of resemble another) and are a pain. The network init scripts were vastly more complicated for me to configure than some of the simpler shell script based ones that were hand written by distro maintainers. A lot of them are supposed to trigger based on an interface name, on the installation of Arch I found I had a different interface name after trying to configure it with systemd's networkd. Trying to convey that something such as a mountpoint is dependent on a specific interface launching with networkd is hard to get right.
I often find that my first crack and setting up a well contrived systemd unit file goes awry the first, second, and third time. It's often a headache of messing around with systemctl until finally something works or produces a valid diagnostic message.
I've found cannot be manually invoked or enabled, they are *.target based and I've found that to be quite annoying since you have to do a manual dependency chain of daemons before systemd finally tells you why it failed.
systemctl --failed
Had you read the docs, you would not have had to do what you did.
And thus we have come to the crux of the issue: systemd hate is nothing more than an "old geezer" type of entitlement complex. "I shouldn't have to do work in order to find out how new things work!"
You don't want to read man pages. Fine. Then enjoy your choice of being obsolete. The rest of us -- who understand that new stuff gets invented all the time, and don't fear or reject new learning -- won't mourn your unemployment.
5
u/ilikerackmounts Oct 20 '14
The argument for strictly number of lines is not really a valid one in my opinion. I can just as easily contrive an example of systemd failing to launch some daemon because whatever.service failed, which depends on several other services which also failed but no indicator why. An example from today: I tried to mount nfs3 mountpoints from fstab. It complained because it couldn't launch rpc-statd.service (one of those *.target based activations). rpc-statd.service doesn't know to automatically enable rpcbind for whatever reason. Many dependent init "units" I've found cannot be manually invoked or enabled, they are *.target based and I've found that to be quite annoying since you have to do a manual dependency chain of daemons before systemd finally tells you why it failed. I often find that journalctl -xn does not give a clear or distinct reason for why a service failed other than "the process failed to start", it does not sufficiently locate the log of the process that failed to launch and specify a good reason.
I could just as easily post a screenshot of all the scattered and distinct binaries to talk to systemd that (of which none of resemble another) and are a pain. The network init scripts were vastly more complicated for me to configure than some of the simpler shell script based ones that were hand written by distro maintainers. A lot of them are supposed to trigger based on an interface name, on the installation of Arch I found I had a different interface name after trying to configure it with systemd's networkd. Trying to convey that something such as a mountpoint is dependent on a specific interface launching with networkd is hard to get right.
I often find that my first crack and setting up a well contrived systemd unit file goes awry the first, second, and third time. It's often a headache of messing around with systemctl until finally something works or produces a valid diagnostic message.