Am 28.04.2014 01:15, schrieb Corey Hickey: > Hi, > > With a recent upgrade, my sid system ended up with systemd-sysv, so I > rebooted it and worked through the problems. One problem I had a hard > time figuring out--I kind of guessed at how to fix it. I'd really like > to know the right way, though, so as to be able to troubleshoot problems > like that in the future. > > With a regular init script, I am used to doing the following: > bash -x /etc/init.d/foo > > How do I do something similar with a systemd unit? I can't figure out > how to find any indication of what programs are actually being run in > order to fulfill a unit.
See http://freedesktop.org/wiki/Software/systemd/Debugging/ if you want to debug/diagnose such problems. You can also inspect the units via systemctl status foo.{device,service,...} systemctl show foo.{device,service,...} > The unit in question was dev-mapper-common.device, and all journalctl > ever said was that it timed out. I'd paste all the information here, but > I can't figure out how to get information from prior to the current boot > either. Fixing the problem entailed finding an entry in /etc/fstab that > referenced a device "/dev/mapper/foo" that doesn't exist unless I create > it manually; I added the "noauto" parameter--I guess this failed in a > non-fatal fashion before. Yeah, a broken fstab configuration is more likely to be noticed under systemd. With sysvinit the initscripts did not wait for any devices to show up but simply mount what is available when the script is called during boot. That's why you never noticed the broken fstab before. Fwiw, I consider the systemd behaviour in that regard more correct / preferrable. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
