[Bug 839595] Re: failsafe.conf's 30 second time out is too low
Clint Byrum
clint at fewbar.com
Fri Sep 9 20:07:03 UTC 2011
Excerpts from Leo Milano's message of Fri Sep 09 18:55:11 UTC 2011:
> Robert, Chris, I think you are both hitting also the other problem I
> encountered, namely the fact that X is not starting until failsafe is up
> (even though theoretically this should not be the case).
>
> Could you please look at comment #21 by Clint and post the info he is
> asking for as well? I will, later today, but I am guessing the more the
> merrier, since this looks like it would become a high impact issue (I am
> glad we found it)
>
Ok, so I took a second look and now I realize that the display managers all
delay their startup until runlevel 2 with something like this (from lightdm)
if [ -n "$UPSTART_EVENTS" ]
then
[ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/lightdm" -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/lightdm" ] || { stop; exit 0; }
if [ "$RUNLEVEL" = S -o "$RUNLEVEL" = 1 ]
then
# Single-user mode
plymouth quit || :
exit 0
fi
fi
That actually does make sense as the whole point of the transition from
S -> 2 is to signal that the system is ready for users to log in.
No need for any of that debugging info, I see whats going on.
Is there any actual reason to have 'auto eth0' in there if you're not
going to wait for it to come up? If its really a dynamic interface that
isn't always plugged in, it should be configured via network manager or
brought up and down manually, no? Was the intention that it would just
run dhclient on it forever and get an address if and when it was plugged
in? That still seems like a job for network manager, though I could be
swayed on that.
Maybe we should change update manager to detect this situation and
display the release note? That seems a bit heavy handed though.
At this point I'm still thinking we should leave it as it is, but possibly
change the wording and priority of the release note.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/839595
Title:
failsafe.conf's 30 second time out is too low
Status in Release Notes for Ubuntu:
New
Status in “upstart” package in Ubuntu:
Fix Released
Bug description:
**** RELEASE NOTES ****
If a system has network interfaces defined in /etc/network/interfaces
as "auto", the operating system will wait up to 120 seconds for those
interfaces to be fully detected and configured before continuing to
boot the system. Most users of Ubuntu will not be affected by this
change, as only servers and dedicated workstations should have network
interfaces configured in this way.
************************
as far as I can understand, the 30 second sleep in failsafe.conf means
that /etc/init/rc-sysinit.conf will start within at most 30 seconds of
'filesystem' and 'ifup lo' having occurred.
I think that is really to small a number. You're only safeguarding
against the case where a user had an entry in /etc/network/interfaces
that where the device was removed or is not connected. Thats a very
rare case. Increasing the timeout to 60 seconds would make it less
likely to have a false positive and have rc-sysinit start early. (Ie,
the case where a dhcp took 35 seconds).
The user will only be punished by waiting an additional 30 seconds in
the case that they have a misconfigured or out of date
/etc/network/interfaces.
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: upstart 1.3-0ubuntu6
ProcVersionSignature: Ubuntu 3.0.0-9.14-generic 3.0.3
Uname: Linux 3.0.0-9-generic x86_64
Architecture: amd64
Date: Fri Sep 2 10:02:10 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100318)
ProcEnviron:
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: upstart
UpgradeStatus: Upgraded to oneiric on 2010-11-15 (290 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/839595/+subscriptions
More information about the foundations-bugs
mailing list