[systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts

[Vivek Goyal]

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