On Tue, Apr 08, 2014 at 02:14:33AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
[..] > > > > Defining a new target which by default waits for all the local fs target > > > > sounds interesting. Again, I have the question, what will happen to > > > > local-fs-all.target if some device does not show up and say one of the > > > > mounts specified in /etc/fstab fails. > It result is different for Requires= and for Wants=. Iff there's a chain > of Requires= from the failing unit (.device in this case) to the target unit > it will fail. Otherwise, it'll just be delayed. If, as I suggested above > local-fs-all.target > would have Requires= on the .mount units, then your unit could still have > Wants=/After=local-fs-all.target, and it'll be started even if some mounts > fail. Thanks now I understand the difference between Requires= and Wants= better. > > > > > What we want is. > > > > > > > > - Wait for all devices to show up as specified in /etc/fstab. Run fsck > > > > on devices. Mount devices to mount points specified. > > > > > > > > - If everything is successful, things are fine and local-fs-all.target > > > > will be reached. > > > > > > > > - If some device does not show up, or if fsck fails or mount fails, > > > > still > > > > local-fs-all.target should reach so that kdump module can detect that > > > > failure happened and can take alternative action. > Alternatively, you can specify a soft depenendency on local-fs-all.target by > using Wants=local-fs-all.target. I think this is preferable, because we want > local-fs-all.target to be as similar as possible to local-fs.target, which > has Requires= on the mount points. > > With this caveat, this should all be satisfied with my proposal. Agreed. We could define Wants=local-fs-all.target and that would make sure that our unit will be started even if local-fs-all.target fails. > > > > You can use OnFailure= to define unit(s) started when > > > local-fs-all.target fails. But it sounds like you are not really > > > interested in *all* filesystems, but in specific fileststems defined in > > > kdump configuration. > > > > Kdump scripts registers with dracut as pre-pivot hook. And I believe > > that in initramfs environments /etc/fstab does not contain all > > filesystems. It prmarily contains root and any file system specified > > on dracut command line using --mount option during initramfs generation. > > > > So my understanding that given the fact that /etc/fstab is minimal in > > initramfs, we should be fine waiting for all the fs specified. > > > > Given the fact that we run under dracut pre-pivot hook callback, I think > > dracut-pre-pivot.service wil have to create a dependency to run after > > local-fs-all.target is reached. > Hm, maybe. It would be good to get some input from Harald here. > This is pretty specialized, so maybe it'd be better to have a separate unit > positioned before or after or parallel to dracut-pre-pivot.service. I am just thinking loud now. Taking a step back and going back to figure out why did we introduce "nofail" to begin with. If I go through kexec-tools logs, it says "nofail" was introduced otherwise we never reach initrd.target. I am wondering why that's the case. Current initrd.target seems to have following. [Unit] Description=Initrd Target Requires=basic.target Conflicts=rescue.service rescue.target After=basic.target rescue.service rescue.target AllowIsolate=yes OnFailure=emergency.target OnFailureIsolate=yes ConditionPathExists=/etc/initrd-release So it Requires=basic.target. Now let us say basic.target fails, then I am assuming emergency.target will be activated. And if we hook into emergency-shell binary and make it run a registered error handler if it is available, then kdump can drop its handler and take action on failure. IOW, what if we stop passing "nofail". Then local-fs.target practically becomes local-fs-all.target. Either services will start just fine (after a wait for deivces to show up). Or units will start failing and if boot can't cointinue then somewhere we will fall into emergency shell and then emergency shell will call into kdump handler. This is assuming that we have designed boot path in such a way that most of the time we will not do infinite wait (until and unless user asked us to do to. (x-systemd.device-timeout=0). So either we will wait for finite amount of time and then fail some services but continue to boot. And along the path if we can't make progress then we will drop into emergency shell. If above assumption is right, then hooking into emergency shell logic in initramfs should provide what I am looking for. Thanks Vivek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
