Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On Thu, Apr 10, 2014 at 06:38:59AM +0400, Andrey Borzenkov wrote: [..] So with nofail opion for rootfs we should have following situation. - sysroot.mount Before=initrd-root-fs.target - initrd-root-fs.target Requires=sysroot.mount OnFailure=emergency.target - initrd.target Wants=initrd-root-fs.target OnFailure=emergency.target - dracut-pre-pivot.service After=initrd.target sysroot.mount Now let us say sysroot.mount failed activation because root device did not show up. We waited for certain time interval, then time out. Now what will happen to initrd-root-fs.target and initrd.target states. Assuming initrd-root-fs.target Requires sysroot.mounts it enters Failed state and systemd effectively executes analog of systemctl start emergency.target. What happens after that is defined entirely by what emergency.target pulls in. initrd.target in your example does not depend on sysroot.mount in any way so unless there are further indirect dependencies it actually should be reached at this point. initrd.target Wants initrd-root-fs.target which inturn depends on sysroot.mount. systemd automatically generates a Requires=sysroot.mount in initrd-root-fs.target. So if sysroot.mount fails, that should start emergency.target as initrd-root-fs.target will fail. As initrd.target has Wants=initrd-root-fs.target, and initrd-root-fs.target activation has failed. So does that mean that initrd.target will reach the failed state too and we will try to launch emergency.target. What will happen to dracut-pre-pivot.service. It is supposed to run after intird.target has reached. Now initrd.target has failed activation. Will dracut-pre-pivot.service be activated? Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
В Thu, 10 Apr 2014 09:46:56 -0400 Vivek Goyal vgo...@redhat.com пишет: On Thu, Apr 10, 2014 at 06:38:59AM +0400, Andrey Borzenkov wrote: [..] So with nofail opion for rootfs we should have following situation. - sysroot.mount Before=initrd-root-fs.target - initrd-root-fs.target Requires=sysroot.mount OnFailure=emergency.target - initrd.target Wants=initrd-root-fs.target OnFailure=emergency.target - dracut-pre-pivot.service After=initrd.target sysroot.mount Now let us say sysroot.mount failed activation because root device did not show up. We waited for certain time interval, then time out. Now what will happen to initrd-root-fs.target and initrd.target states. Assuming initrd-root-fs.target Requires sysroot.mounts it enters Failed state and systemd effectively executes analog of systemctl start emergency.target. What happens after that is defined entirely by what emergency.target pulls in. initrd.target in your example does not depend on sysroot.mount in any way so unless there are further indirect dependencies it actually should be reached at this point. initrd.target Wants initrd-root-fs.target which inturn depends on sysroot.mount. Wants does not imply any sort of mandatory dependency. Unit A wants unit B means that when systemd gets request to start A it will additionally attempt to start B. Whether it will actually be able to start B is irrelevant. systemd automatically generates a Requires=sysroot.mount in initrd-root-fs.target. So if sysroot.mount fails, that should start emergency.target as initrd-root-fs.target will fail. As initrd.target has Wants=initrd-root-fs.target, and initrd-root-fs.target activation has failed. So does that mean that initrd.target will reach the failed state too and we will try to launch emergency.target. No, unless it has some other mandatory dependency (Requires, BindsTo). As already explained, Wants does not imply any sort of dependency between unit states; it is simply convenient shortcut to start multiple units at once. After start job is submitted, units run independently on each other. What will happen to dracut-pre-pivot.service. It is supposed to run after intird.target has reached. Now initrd.target has failed activation. Will dracut-pre-pivot.service be activated? Yes. Again, After does not imply any mandatory dependency. A After B only says that when two units are started together, A should wait until B startup is complete. If B fails to start, its startup obviously is complete :) so systemd will just continue. One thing I'm not sure about - what are started together actually means. I.e. common sense suggests that systemctl start A B causes them both be started together. But what if I do systemctl start A and later systemctl start B while job for A is still running and B has After=A. Will it wait for A startup to complete? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On Fri, Apr 04, 2014 at 05:30:03PM -0400, Vivek Goyal wrote: What happens if nofail is specified and device is present and there are file system errors. Will fsck continue with boot or drop user into a shell during boot and force to fix file system failures? fsck cares about nofail option only if the device does not exist -- it's evaluated before FS check. Note that fsck(8) itself does not check filesystems, and fsck.type helpers does not have a clue about nofail at all. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On 04/08/14 at 06:02pm, Vivek Goyal wrote: 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 dracut doesn't use this initrd.target. It uses the stock one from systemd: [Unit] Description=Initrd Default Target Documentation=man:systemd.special(7) OnFailure=emergency.target OnFailureIsolate=yes ConditionPathExists=/etc/initrd-release Requires=basic.target Wants=initrd-root-fs.target initrd-fs.target initrd-parse-etc.service After=initrd-root-fs.target initrd-fs.target basic.target rescue.service rescue.target AllowIsolate=yes In sysroot.mount context, if we don't use nofail in case of root disk failure, we will never reach initrd-root-fs.target and hence we never reach initrd.target and dracut-pre-povit.service never get a chance to start. 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.
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On Wed, Apr 09, 2014 at 05:36:13PM +0800, WANG Chao wrote: On 04/08/14 at 06:02pm, Vivek Goyal wrote: 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 dracut doesn't use this initrd.target. It uses the stock one from systemd: [Unit] Description=Initrd Default Target Documentation=man:systemd.special(7) OnFailure=emergency.target OnFailureIsolate=yes ConditionPathExists=/etc/initrd-release Requires=basic.target Wants=initrd-root-fs.target initrd-fs.target initrd-parse-etc.service After=initrd-root-fs.target initrd-fs.target basic.target rescue.service rescue.target AllowIsolate=yes In sysroot.mount context, if we don't use nofail in case of root disk failure, we will never reach initrd-root-fs.target and hence we never reach initrd.target and dracut-pre-povit.service never get a chance to start. Ok, I want to understand what is never reach a target means. So with nofail opion for rootfs we should have following situation. - sysroot.mount Before=initrd-root-fs.target - initrd-root-fs.target Requires=sysroot.mount OnFailure=emergency.target - initrd.target Wants=initrd-root-fs.target OnFailure=emergency.target - dracut-pre-pivot.service After=initrd.target sysroot.mount Now let us say sysroot.mount failed activation because root device did not show up. We waited for certain time interval, then time out. Now what will happen to
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
В Wed, 9 Apr 2014 13:49:47 -0400 Vivek Goyal vgo...@redhat.com пишет: On Wed, Apr 09, 2014 at 05:36:13PM +0800, WANG Chao wrote: On 04/08/14 at 06:02pm, Vivek Goyal wrote: 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 dracut doesn't use this initrd.target. It uses the stock one from systemd: [Unit] Description=Initrd Default Target Documentation=man:systemd.special(7) OnFailure=emergency.target OnFailureIsolate=yes ConditionPathExists=/etc/initrd-release Requires=basic.target Wants=initrd-root-fs.target initrd-fs.target initrd-parse-etc.service After=initrd-root-fs.target initrd-fs.target basic.target rescue.service rescue.target AllowIsolate=yes In sysroot.mount context, if we don't use nofail in case of root disk failure, we will never reach initrd-root-fs.target and hence we never reach initrd.target and dracut-pre-povit.service never get a chance to start. Ok, I want to understand what is never reach a target means. So with nofail opion for rootfs we should have following situation. - sysroot.mount Before=initrd-root-fs.target - initrd-root-fs.target Requires=sysroot.mount OnFailure=emergency.target - initrd.target Wants=initrd-root-fs.target OnFailure=emergency.target -
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On 04/08/14 at 02:14am, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Apr 07, 2014 at 03:10:14PM -0400, Vivek Goyal wrote: On Mon, Apr 07, 2014 at 10:07:20PM +0400, Andrey Borzenkov wrote: В Mon, 7 Apr 2014 13:40:17 -0400 Vivek Goyal vgo...@redhat.com пишет: 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. 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. Actually, With current implementation, whether Wants or Requires depends on if nofail is specified. With this caveat, this should all be satisfied with my proposal. 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. Now I am not sure who will generate local-fs-all.target. It would become a standard unit in systemd, like local-fs.target. Mount units would be added to this target by fstab-generator. If dracut generates it then dracut will also specify OnFailure=. Question will still remain how dracut modules will communicate to dracut that what to run after local-fs-all.target fails. In fact if dracut is doing all this, we don't have to create a separate target. Right now we force nofail so that if mount fails, initrd.target is still reached. If we can create a separate service to just handle failures, then we probably should be able to spcify OnFailure=dracut-failure-hander.service in right file and as modules to register their failure handler hooks there. Something like create new hook called pre-pivot-failure and modules register a hook to handle pre-pivot-failure. Then kdump can get the control and handle failure. And this should allow dracut pre pivot service to specify to launch dracut-failure-handler.service upon failure. For example, Asssume a user wants to save vmcore to nfs destination. Now for whatever reason, nfs target could not be mounted. In that case kdump will still like to get control and alternatively save dump to local root fs. Without knowing details it sounds like RequiresMountsFor is more appropriate (and can be set by generator based on actual kdump configuration). I am not sure how is it useful for this case. dracut already generates all dependencies and puts them in /etc/fstab. And only entries in /etc/fstab should be which dracut wants. So I guess we should be fine and not need using RequiresMountsFor. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On Tue, Apr 08, 2014 at 06:35:03PM +0800, WANG Chao wrote: On 04/08/14 at 02:14am, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Apr 07, 2014 at 03:10:14PM -0400, Vivek Goyal wrote: On Mon, Apr 07, 2014 at 10:07:20PM +0400, Andrey Borzenkov wrote: В Mon, 7 Apr 2014 13:40:17 -0400 Vivek Goyal vgo...@redhat.com пишет: 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. 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. Actually, With current implementation, whether Wants or Requires depends on if nofail is specified. It is specified for local-fs.target, which doesn't necessarilly influence local-fs-all.target, and anyway, here we're talking about the relationship between local-fs-all.target and some dracut units. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
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
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On Sat, Apr 05, 2014 at 04:24:01AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Apr 04, 2014 at 05:30:03PM -0400, Vivek Goyal wrote: On Fri, Apr 04, 2014 at 02:44:50PM +0800, WANG Chao wrote: In kdump kernel, we need mount certain file system, and we use nofail for all mounts specified in /etc/fstab. Because we don't want any mount failure to interrupt the boot process to arrive at dracut-pre-pivot.service (This is the point just before we switch root). And at that dracut-pre-pivot, we run our kernel dump capture script (called kdump.sh). Our kdump.sh needs every .mount is mounted (or started in systemd context) before it gets run by dracut-pre-pivot.service. And dracut-pre-pivot.service is configured to run after local-fs.target. So what we expect is no matter nofail is configured or not, local-fs.target should be delayed after all mount units are started. And it's also the same for remote nofail mounts and remote-fs.target. Chao, will this change not force boot to stop if fsck on said device failed? And in that case we will not get a chance to run default action in kdump. I think there is conflict in the definiton of nofail as defined by fstab/fsck and as interpreted by systemd fstab generator. Current behaviour has an important reason: it is not possible to implement wait mode without heavily penalising the case of missing devices. Since systemd boots rather quickly, it has not way of knowing whether the device in question is genuinly missing, or just slow to be detected, and has to wait the device timeout (3 min, iirc) before continuing. In the light of this, current behaviour seems to be a reasonable reinterpretation of nofail for an event-based boot system. I have couple of questions. - Assume nofail is not specified and device specified in /etc/fstab does not show up. How long will we wait before we give up? Looks like you think it is 3 mins? So by default it is time bound wait and not an infinite wait. - Say, we timed out and device was not found. I think foo.mount service will fail. Now what will happen to all dependent services or targets. For example, will initrd.target be reached or not. In the past looks like we faced the problem that initrd.target was not reached because device could not be found and kdump never got to run. Nevertheless, I understand the motivation for this patch, and this is something that has been discussed before. What about adding an local-fs-all.target, something like [Unit] Description=All local mount points configured in /etc/fstab [Install] WantedBy=multi-user.target and having fstab-generator add Before=local-fs-all.target, RequiredBy=local-fs-all.target to the units it generates. Then if someone wants to wait for all local mounts, they can use Requires=,After=local-fs-all.target. And thanks to the [Install] section, a user can do 'systemctl enable local-fs-all.target' to wait for 'nofail' devices. 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. 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. For example, Asssume a user wants to save vmcore to nfs destination. Now for whatever reason, nfs target could not be mounted. In that case kdump will still like to get control and alternatively save dump to local root fs. If systemd just hangs because nfs mounting failed and local-fs-all.target was never reached, then we can't take backup action. Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
В Mon, 7 Apr 2014 13:40:17 -0400 Vivek Goyal vgo...@redhat.com пишет: 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. 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. 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. For example, Asssume a user wants to save vmcore to nfs destination. Now for whatever reason, nfs target could not be mounted. In that case kdump will still like to get control and alternatively save dump to local root fs. Without knowing details it sounds like RequiresMountsFor is more appropriate (and can be set by generator based on actual kdump configuration). If systemd just hangs because nfs mounting failed and local-fs-all.target was never reached, then we can't take backup action. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On Mon, Apr 07, 2014 at 10:07:20PM +0400, Andrey Borzenkov wrote: В Mon, 7 Apr 2014 13:40:17 -0400 Vivek Goyal vgo...@redhat.com пишет: 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. 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. 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. Now I am not sure who will generate local-fs-all.target. If dracut generates it then dracut will also specify OnFailure=. Question will still remain how dracut modules will communicate to dracut that what to run after local-fs-all.target fails. In fact if dracut is doing all this, we don't have to create a separate target. Right now we force nofail so that if mount fails, initrd.target is still reached. If we can create a separate service to just handle failures, then we probably should be able to spcify OnFailure=dracut-failure-hander.service in right file and as modules to register their failure handler hooks there. Something like create new hook called pre-pivot-failure and modules register a hook to handle pre-pivot-failure. Then kdump can get the control and handle failure. And this should allow dracut pre pivot service to specify to launch dracut-failure-handler.service upon failure. For example, Asssume a user wants to save vmcore to nfs destination. Now for whatever reason, nfs target could not be mounted. In that case kdump will still like to get control and alternatively save dump to local root fs. Without knowing details it sounds like RequiresMountsFor is more appropriate (and can be set by generator based on actual kdump configuration). I am not sure how is it useful for this case. dracut already generates all dependencies and puts them in /etc/fstab. And only entries in /etc/fstab should be which dracut wants. So I guess we should be fine and not need using RequiresMountsFor. Thanks Vivek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On Mon, Apr 07, 2014 at 03:10:14PM -0400, Vivek Goyal wrote: On Mon, Apr 07, 2014 at 10:07:20PM +0400, Andrey Borzenkov wrote: В Mon, 7 Apr 2014 13:40:17 -0400 Vivek Goyal vgo...@redhat.com пишет: 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. 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. 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. Now I am not sure who will generate local-fs-all.target. It would become a standard unit in systemd, like local-fs.target. Mount units would be added to this target by fstab-generator. If dracut generates it then dracut will also specify OnFailure=. Question will still remain how dracut modules will communicate to dracut that what to run after local-fs-all.target fails. In fact if dracut is doing all this, we don't have to create a separate target. Right now we force nofail so that if mount fails, initrd.target is still reached. If we can create a separate service to just handle failures, then we probably should be able to spcify OnFailure=dracut-failure-hander.service in right file and as modules to register their failure handler hooks there. Something like create new hook called pre-pivot-failure and modules register a hook to handle pre-pivot-failure. Then kdump can get the control and handle failure. And this should allow dracut pre pivot service to specify to launch dracut-failure-handler.service upon failure. For example, Asssume a user wants to save vmcore to nfs destination. Now for whatever reason, nfs target could not be mounted. In that case kdump will still like to get control and alternatively save dump to local root fs. Without knowing details it sounds like RequiresMountsFor is more appropriate (and can be set by generator based on actual kdump configuration). I am not sure how is it useful for this case. dracut already generates all dependencies and puts them in /etc/fstab. And only entries in /etc/fstab should be which dracut wants. So I guess we should be fine and not need using RequiresMountsFor. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On Fri, Apr 04, 2014 at 02:44:50PM +0800, WANG Chao wrote:
In kdump kernel, we need mount certain file system, and we use nofail
for all mounts specified in /etc/fstab. Because we don't want any mount
failure to interrupt the boot process to arrive at
dracut-pre-pivot.service (This is the point just before we switch root).
And at that dracut-pre-pivot, we run our kernel dump capture script
(called kdump.sh).
Our kdump.sh needs every .mount is mounted (or started in systemd
context) before it gets run by dracut-pre-pivot.service. And
dracut-pre-pivot.service is configured to run after local-fs.target. So
what we expect is no matter nofail is configured or not, local-fs.target
should be delayed after all mount units are started.
And it's also the same for remote nofail mounts and remote-fs.target.
Chao, will this change not force boot to stop if fsck on said device
failed? And in that case we will not get a chance to run default
action in kdump.
I think there is conflict in the definiton of nofail as defined by
fstab/fsck and as interpreted by systemd fstab generator.
man fstab says following.
nofail do not report errors for this device if it does not exist.
man fsck says following.
fsck normally does not check whether the device actually exists
before calling a filesystem specific checker. Therefore non-
existing devices may cause the system to enter filesystem repair
mode during boot if the filesystem specific checker returns a
fatal error. The /etc/fstab mount option nofail may be used to
have fsck skip non-existing devices. fsck also skips non-exist‐
ing devices that have the special filesystem type auto.
To me, that means one will still try to run fsck on the device and continue
if device is not available, instead of forcing an error. I am not sure what
error code fsck returns in this acse.
But systemd seems to be implementing *do not wait for device to mount or
do not wait for fsck results*
http://www.freedesktop.org/software/systemd/man/systemd.mount.html
If nofail is given, this mount will be only wanted, not required, by the
local-fs.target. This means that the boot will continue even if this mount
point is not mounted successfully. Option fail has the opposite meaning
and is the default.
*
To me systemd seems to be implementing mountall nobootwait which seems to
imply that boot does can continue without this mount being successful.
If I go by fsck definition, nofail will imply that start the unit but
if mount fails, still continue with rest of the units. It does not mean
that other dependent units can be started before starting this unit.
So I think nofail should map force Before=.
What happens if nofail is specified and device is present and there
are file system errors. Will fsck continue with boot or drop user into
a shell during boot and force to fix file system failures?
I think we also need an option which tells that continue to start
dependent units even if you failed to mount a filesystem. If nofail
semantics implies that, it is fine, otherwise we will have to create
a systemd specific semantic to imply that to meet our needs.
Thanks
Vivek
---
src/fstab-generator/fstab-generator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index a9a5c02..55938b5 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -225,7 +225,7 @@ static int add_mount(
Documentation=man:fstab(5)
man:systemd-fstab-generator(8)\n,
source);
-if (post !noauto !nofail !automount)
+if (post !noauto !automount)
fprintf(f, Before=%s\n, post);
if (passno != 0) {
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
On Fri, Apr 04, 2014 at 05:30:03PM -0400, Vivek Goyal wrote: On Fri, Apr 04, 2014 at 02:44:50PM +0800, WANG Chao wrote: In kdump kernel, we need mount certain file system, and we use nofail for all mounts specified in /etc/fstab. Because we don't want any mount failure to interrupt the boot process to arrive at dracut-pre-pivot.service (This is the point just before we switch root). And at that dracut-pre-pivot, we run our kernel dump capture script (called kdump.sh). Our kdump.sh needs every .mount is mounted (or started in systemd context) before it gets run by dracut-pre-pivot.service. And dracut-pre-pivot.service is configured to run after local-fs.target. So what we expect is no matter nofail is configured or not, local-fs.target should be delayed after all mount units are started. And it's also the same for remote nofail mounts and remote-fs.target. Chao, will this change not force boot to stop if fsck on said device failed? And in that case we will not get a chance to run default action in kdump. I think there is conflict in the definiton of nofail as defined by fstab/fsck and as interpreted by systemd fstab generator. Current behaviour has an important reason: it is not possible to implement wait mode without heavily penalising the case of missing devices. Since systemd boots rather quickly, it has not way of knowing whether the device in question is genuinly missing, or just slow to be detected, and has to wait the device timeout (3 min, iirc) before continuing. In the light of this, current behaviour seems to be a reasonable reinterpretation of nofail for an event-based boot system. Nevertheless, I understand the motivation for this patch, and this is something that has been discussed before. What about adding an local-fs-all.target, something like [Unit] Description=All local mount points configured in /etc/fstab [Install] WantedBy=multi-user.target and having fstab-generator add Before=local-fs-all.target, RequiredBy=local-fs-all.target to the units it generates. Then if someone wants to wait for all local mounts, they can use Requires=,After=local-fs-all.target. And thanks to the [Install] section, a user can do 'systemctl enable local-fs-all.target' to wait for 'nofail' devices. To me systemd seems to be implementing mountall nobootwait which seems to imply that boot does can continue without this mount being successful. Yeah, it can do that because upstart does not really support dynamic boot, and assumes that there's a point in time where everything is detected. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
