[Mageia-dev] Systemd improvement

[Colin Guthrie]

'Twas brillig, and Olivier Thauvin at 24/07/12 10:47 did gyre and gimble:
> * Colin Guthrie (mageia at colin.guthr.ie) wrote:
>> 'Twas brillig, and Olivier Thauvin at 24/07/12 10:02 did gyre and gimble:
>>> I have some minor issues with systemd so I report it in case some
>>> improvment could be done:
>>>
>>> 1) The timeout is very long when the system failed to ask the passphrase
>>> for encrypted partition, os it is very long to reach any console (this
>>> happend only when there is a problem)
>>>
>>> 2) When everything work fine, the timeout occur if the passphrase for
>>> encrypted partition is not enter early enough: I power up my laptop, do
>>> something else, come back and it report the boot has failed, surprising!
>>
>> So it's both too long and too short :)
>>
>> I'm not sure how to deal with this, but I would suggest that we need to
>> do something a bit more creative to deal with your particular use case.
>>
>> For yourself, it's not a "critical" filesystem - e.g. it's not /usr or
>> similar, but /home.
> 
> No you misunderstood, if the system succeed to launch
> '/usr/bin/ask-the-passphrase' or whatever its name is, it must wait an
> answer for ever and not continue booting and finally claim "hey
> surprising, I failed to boot w/o the passphrase".
> The firest time it happend I really thought my system was broken.

So what if you cannot enter your password and want to rescue the system?
Should it still wait forever until you enter your passphrase? Or would
you have to deliberately enter your passphrase wrong X number of times
to get the the rescue mode?

> However, if it cannot launch '/usr/bin/ask-the-passphrase' it is sure
> booting will failed as it cannot get the passphrase, no need to wait an
> impossible user input.
> Again, the case I just talk about happend only in case of bug and must
> not happend on stable distro.

In this particular case it was not that it could not run the password
prompt, simply that it didn't know how to mount something completely
alien to it.

You have to remember that all this is happening completely
asynchronously these days. It's not like systemd is specifically poking
things and failing. It's waiting for the system to do it itself, hence
the timeouts.

That's not to say this can't be solved, it's just that we're treating
one mount much like any other - and some mounts take a loooooong time to
happen (e.g. just try recent btrfs stuff with all the krud it does when
mounting).

But the "waiting-for-password" case and the "there is no subsystem to
handle even asking for the password" case are essentially treated the
same way.

This is likely a discussion to take to the upstream mailing list.

>>> 3) the boot process hang/stop/wait if my wireless card is down (using
>>> the hardware switch on the side of my laptop). This step need just one
>>> second when the card is on, even it does not connect to any network.
>>
>> If you have any NFS (or other network mounts) mounts that are NOT marked
>> with nofail, then we consider them to be "critical" filesystems. If
>> these filesystems are NOT needed for boot, then just mark them as
>> "nofail" and they will still be mounted but your DM/logins will not be
>> delayed while waiting for the network.
> 
> 
> I don't have nfs in my fstab but maybe this is triggered by another
> service.
> But I don't see the point of waiting the card to be on, especially when
> the card is on it don't connect to any network and don't wait this
> happend.

Hmm in that case it sounds like a different issue than the deliberate
stuff that waits for the network to be ready.

Do you know which bit of the system is waiting for this? Is it
network-up.service or something else? (I doubt it can be network-up as
this shouldn't delay logins unless the afore mentioned NFS mounts are
present)

Col




-- 

Colin Guthrie
colin(at)mageia.org
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/