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
