[systemd-devel] why does nofail imply no After= in /etc/fstab

Colin Guthrie gmane at colin.guthr.ie
Thu Jan 16 08:04:34 PST 2014


'Twas brillig, and Chris Murphy at 16/01/14 15:34 did gyre and gimble:
> 
> On Jan 16, 2014, at 8:25 AM, Kay Sievers <kay at vrfy.org> wrote:
> 
>> On Thu, Jan 16, 2014 at 4:19 PM, Lennart Poettering 
>> <lennart at poettering.net> wrote:
>>> On Thu, 16.01.14 16:14, Zbigniew Jędrzejewski-Szmek
>>> (zbyszek at in.waw.pl) wrote:
>>> 
>>>> 
>>>> On Thu, Jan 16, 2014 at 03:51:02PM +0100, Lennart Poettering
>>>> wrote:
>>>>> On Wed, 15.01.14 20:20, Zbigniew Jędrzejewski-Szmek
>>>>> (zbyszek at in.waw.pl) wrote:
>>>>> 
>>>>>> I was a bit surprised that for mount points the dependency 
>>>>>> Before=local-fs.target is only added when nofail is not
>>>>>> used. This seems to be a concious decision (added by
>>>>>> Lennart in 155da457, and then survived all the refactorings
>>>>>> by Tom and Thomas...). Do we still want this behaviour?
>>>>> 
>>>>> Well, "nofail" means that we shouldn't bother if the device
>>>>> doesn't show up at boot. Now, if we add "After=" for it
>>>>> there, then we will time-out on it (though not fail) if
>>>>> something else pulls it in.
>>>>> 
>>>>> I figure this is a question what nofail really should mean:
>>>>> "never wait for it, never fail for it" (which is the status
>>>>> quo), or just "usually don't wait, never fail for it" (which
>>>>> would be the change if we added After= in). I am tempted to
>>>>> say that the status quo is more likely what people would
>>>>> expect, no?
>>>> 
>>>> The problem is that with current boot speeds, "usually don't
>>>> wait" means that it shows up at some "upredictable" time. With
>>>> a bit of luck, users might be able to log in before such mount
>>>> points which are declared in /etc/fstab are mounted. I think
>>>> that's unexpected, because it goes againt the general rule that
>>>> things declared in /etc/fstab (w/o automount or noauto) are
>>>> mounted at boot.
>>> 
>>> I'd argue that "nofail" is precisely what the admin can use to
>>> *enable* this race. If it should be avoided to allow the user to
>>> log in before the device has shown up and is hooked in the admin
>>> should not have used "nofail"...
>>> 
>>>> I'd prefer to keep things orthogonal. This feels like an
>>>> "optimization" that it user visible. We should rather encourage
>>>> people to use automounts if the don't want to wait for the
>>>> mountpoint to come up.
>>> 
>>> I am pretty sure people would be annoyed by this change of
>>> behaviour, simply because every boot would still delay for 90s if
>>> the device is not plugged in. I have the suspicion that people
>>> would really assume that using "nofail" would make their system
>>> boot-up cleanly, without delays if the file system cannot be
>>> found -- and that expection is something we'd not fulfill?
>> 
>> man mount 8: nofail -- Do not report errors for this device if it
>> does not exist.
>> 
>> Right, we cannot really re-define this. It's use is established
>> since years. Used for things like isci, which is often not
>> available at bootup.
> 
> 
> Although with faster boot times, a device in fstab not existing is
> probably increasingly common. What about splitting the scheduling of
> .mount jobs such that /sysroot happens early, and everything else
> listed in fstab happens much later, to give the underlying device
> every opportunity to appear before the attempt?

Primarily because special casing things is evil.

Perhaps it would be better to just use a much smaller timeout for these
generated units? Perhaps combine that with some kind of automount magic
and then we've done all we can?

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/



More information about the systemd-devel mailing list