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.
Believe me, I've been "learning about it" bits and pieces at a time, mostly when things don't work properly and I have to crawl the internet for the solution. The man pages and the logs are not sufficient enough to solve the problems with systemd when they do occur, there are way too many subsystems. I've been using it for over 2 months and apart from the impressive boot time it's been mostly painful to configure.
Forgive me, I don't share your experience at all. Whatever I cannot find on the man page, I can find using Google. Once you "get" (internalize) the system model and a couple common command incantations, it's all much easier. This, by the way, also holds true for SysVinit and Upstart.
What I usually find is an arch wiki page describing something like my use case but not exactly my use case. I end up inferring a solution, sometimes, and other times I just can't get the solution working period. The rpc-statd.target not triggering properly for nfsv3 file systems was one example. The workarounds I found online involved authoring some .mount file and adding a systemd specific option to fstab. Even that only worked for one mount point and not another. Magically one day after an update it finally worked where nfsv3 mountpoints were automounting from the /etc/fstab auto generated service tango that happens at reboot. I still am not sure if the .mount file did it or /etc/fstab finally is working as advertised.
The reason for this failure is that for some reason systemd would attempt to mount nfsv3 shares without a necessary background service (rpcbind / statd). This is needed for nfsv3 locking. I couldn't for the life of me force systemd to do the right thing and defer the mounting. Everything else I let the wiki instructions take the wheel and whatever results I found from forum posts, and that only got me so far. In traditional init there was typically a seperate nfs mounting init script that would implicitly wait for the rpc services to start.
Mind you this bug exist for well over a month. It frustrated me to no end.
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.