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

[WANG Chao]

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 <vgoyal at 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