On Fri, Aug 22, 2014 at 01:51:56PM -0400, Stefan Monnier wrote: > >> In which way is it "safe and correct" to interrupt the boot in this case? > > In the way that missing some mounts may indicate a serious problem and > > could lead to incorrect behaviour or data loss. > > Haven't heard many complaints about that over the years, so it shouldn't > be a super-top-priority goal, I think. It is one of the mail goals of systemd to use the dependencies. In the end this is what allows us to achieve reliability.
> In any case, that's not incompatible with the desire to "boot enough for > remote maintenance to be possible". > > > stopped when something important fails. You can configure things > > otherwise, but the default is to strictly obey dependencies. > > To get the best of both worlds, I suggest that if a problem happens > during boot, systemd doesn't just interrupt the boot, but instead tries > to keep booting up to a "fallback/safe" state, so that maintenance can be > done conveniently over the network, instead of having to be done "on > console" which is all too often completely unworkable. Yes, you can configure such behaviour. You can add OnFailure= and OnFailureJobMode= to default.target (e.g. in /etc/systemd/system/default.target.d/failure.conf') to launch some target you define, and add e.g. sshd.service and other things to this target. It is hard to do something like this in a general way though. You can also add nofail where necessary. In systemd git, there's a more general setting StartTimeoutAction= [1] which makes it possible to configure an action that will fire also when boot "hangs" wait for password input or similar. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=2928b0a863 Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
