Bug#624469: udev: Intermittent failure to start. Timestamp conflict?
Tony Houghton
Version: 168-1
Severity: important
udev frequently fails to start at bootup, and I see these messages on
the console (I was unable to recover many of these from /var/log and had
to write them down):
udevd[87]: error: runtime directory '/run/udev' not writable, for now falling back to '/dev/.udev'
udevd[204]: exec of program 'net.agent' failed
udevd[265]: exec of program 'net.agent' failed
udevd[280]: exec of program 'net.agent' failed
...
Starting the hotplug events dispatcher: udevdudevd[435]: error: runtime directory '/run/udev' not writable, for now falling back to '/dev/.udev'
udevd[435]: bind failed: Address already in use
error binding udev control socket
udevd[435]: error binding udev control socket
failed!
As long as gdm3 is disabled (otherwise it effectively locks the system
because it has no input devices) I can log in and invoke-rc.d udev
manually and then it starts up with no issues at all and I can then
start gdm3 and operate the system normally.
I'm not 100% sure, but I think this is caused by conflicting timestamps.
I dual boot with Windows 7 which doesn't seem to have an option to
disable DST switching any more, so I let it set the hw clock incorrectly
and put UTC=no in /etc/default/rcS in Debian.
However, I noticed that timestamps of early parts of the boot sequence
in the logs were an hour ahead, so /etc/default/rcS doesn't seem to be
taking effect until some point after udev tries to start. But once the
system time is corrected udev seems to be able to start. I tried setting
the hw clock back to UTC and setting UTC=yes and udev started
successfully (although it does still complain about /run and net.agent).
I think udev is too vital to the system to allow it to fail for a reason
like this.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages udev depends on:
ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy
ii libc6 2.11.2-13 Embedded GNU C Library: Shared lib
ii libselinux1 2.0.98-1 SELinux runtime shared libraries
ii libudev0 168-1 libudev shared library
ii libusb-0.1-4 2:0.1.12-17 userspace USB programming library
ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip
ii util-linux 2.17.2-9.1 Miscellaneous system utilities
Versions of packages udev recommends:
ii pciutils 1:3.1.7-9 Linux PCI Utilities
ii usbutils 1:001-1 Linux USB utilities
udev suggests no packages.
-- Configuration Files:
/etc/modprobe.d/blacklist.conf changed:
blacklist evbug
blacklist usbmouse
blacklist usbkbd
blacklist eepro100
blacklist de4x5
blacklist am53c974
blacklist iTCO_wdt
-- debconf information:
udev/new_kernel_needed: false
udev/title/upgrade:
udev/reboot_needed:
udev/sysfs_deprecated_incompatibility:
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marco d'Itri
> udevd[435]: bind failed: Address already in use
> error binding udev control socket
> udevd[435]: error binding udev control socket
> failed!
I do not know why this happens.
You will need to find out why udevd is failing to start (probably
because there is already an udevd process running, but why?).
Debugging early boot
~~~~~~~~~~~~~~~~~~~~
If the system hangs at boot time or fails to boot properly, it may be
useful to examine in real time what is happening while "udevadm settle"
is running. A simple way to do this is:
* boot the system passing "init=/bin/bash" on the kernel command line
* start a getty on tty2 (or the serial console) with a command like
"/sbin/getty 38400 tty2 &"
* continue the boot process with "exec /sbin/init single"
The open console can be used to check which processes are running and
what they are waiting for.
> I'm not 100% sure, but I think this is caused by conflicting timestamps.
Not this.
> However, I noticed that timestamps of early parts of the boot sequence
> in the logs were an hour ahead, so /etc/default/rcS doesn't seem to be
> taking effect until some point after udev tries to start. But once the
This is even documented in README.Debian.
--
ciao,
Marco
Tony Houghton
m...@Linux.IT (Marco d'Itri) wrote:
> On Apr 28, Tony Houghton <h...@realh.co.uk> wrote:
>
> > udevd[435]: bind failed: Address already in use
> > error binding udev control socket
> > udevd[435]: error binding udev control socket
> > failed!
> I do not know why this happens.
> You will need to find out why udevd is failing to start (probably
> because there is already an udevd process running, but why?).
>
> Debugging early boot
> ~~~~~~~~~~~~~~~~~~~~
> If the system hangs at boot time or fails to boot properly, it may be
> useful to examine in real time what is happening while "udevadm
> settle" is running. A simple way to do this is:
>
> * boot the system passing "init=/bin/bash" on the kernel command line
> * start a getty on tty2 (or the serial console) with a command like
> "/sbin/getty 38400 tty2 &"
> * continue the boot process with "exec /sbin/init single"
>
> The open console can be used to check which processes are running and
> what they are waiting for.
That won't help, because nothing hangs (unless I let gdm3 start with no
input devices available). udev just fails to start but the boot sequence
continues. By the time I could run a command in another console the boot
sequence would have finished. It's very quick because I have an SSD.
I need some debugging in the start scripts and/or udev itself so that I
can check whether udev really is running when it finds the control
socket already in use. And if it is, why is it trying to start twice and
why doesn't the first instance stay running? I guess it isn't (still)
really running already but the new socket can't be created for some
reason. Beej's socket programming guide says a socket's address isn't
cleared for use for a minute or so unless you use SO_REUSEADDR and I
have experienced this in a server program I was writing. But I'm not
sure whether this only happens if the first program exits without
closing the socket.
> > I'm not 100% sure, but I think this is caused by conflicting
> > timestamps.
> Not this.
Definitely? There are sometimes error messages about timestamps in the
future. Even if this doesn't directly cause udev to fail could it cause
something that udev depends on to fail? Or could it cause the udev
control socket to exist (or at least its address to be reserved) while
udev isn't running?
> > However, I noticed that timestamps of early parts of the boot
> > sequence in the logs were an hour ahead, so /etc/default/rcS
> > doesn't seem to be taking effect until some point after udev tries
> > to start. But once the
> This is even documented in README.Debian.
Which README.Debian?
Marco d'Itri
> That won't help, because nothing hangs (unless I let gdm3 start with no
Again:
> > You will need to find out why udevd is failing to start (probably
> > because there is already an udevd process running, but why?).
If the early getty still does not help then you can manually run the
rcS.d scripts instead of starting init.
> > > I'm not 100% sure, but I think this is caused by conflicting
> > > timestamps.
> > Not this.
> Definitely? There are sometimes error messages about timestamps in the
Yes.
> > This is even documented in README.Debian.
> Which README.Debian?
Your guess.
--
ciao,
Marco