On Fri, May 13, 2011 at 09:44:44PM +0200, Marco d'Itri wrote:
> On May 13, j...@joshtriplett.org wrote:
>
> > Does udevd normally have multiple processes?
> Yes. It would be useful to determine if the problem is that:
> - there is a race between the initial wildcard expansion by the shell
> and
On May 13, j...@joshtriplett.org wrote:
> Does udevd normally have multiple processes?
Yes. It would be useful to determine if the problem is that:
- there is a race between the initial wildcard expansion by the shell
and further forking by udev, or
- the killed processes do not die quickly enou
On Thu, May 12, 2011 at 11:46:23AM +0200, Marco d'Itri wrote:
> On May 11, Marco d'Itri wrote:
>
> > > bind(3, {sa_family=AF_FILE, path=@"/org/kernel/udev/udevd"}, 25) = -1
> > > EADDRINUSE
> > > (Address already in use)
> > OK, so it looks like that there *is* an udevd process left around by
>
On May 11, Marco d'Itri wrote:
> > bind(3, {sa_family=AF_FILE, path=@"/org/kernel/udev/udevd"}, 25) = -1
> > EADDRINUSE
> > (Address already in use)
> OK, so it looks like that there *is* an udevd process left around by
> the initramfs.
> Can you confirm this with ps at the first prompt?
If thi
On May 11, Josh Triplett wrote:
> bind(3, {sa_family=AF_FILE, path=@"/org/kernel/udev/udevd"}, 25) = -1
> EADDRINUSE
> (Address already in use)
OK, so it looks like that there *is* an udevd process left around by
the initramfs.
Can you confirm this with ps at the first prompt?
--
ciao,
Marco
On May 08, Josh Triplett wrote:
> Any chance this represents a conflict with udev from the initramfs?
This is the only explanation, but in this case you should see the old
process with ps.
Try again by immediately running something like "strace -v -s 200 udevd"
at the shell prompt so we can see e
Package: udev
Version: 168-1
Followup-For: Bug #624469
One more note: this occurred after a fresh install of stable and upgrade
to unstable, with no unusual steps taken.
- Josh Triplett
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Archi
Package: udev
Version: 168-1
Followup-For: Bug #624469
retitle 624469 Fails to start: failed to bind control socket (address in use)
thanks
I've just checked, and if I boot the system with init=/bin/sh and then
manually run the first two rcS.d scripts (mountkernfs and udev), udev
starts just fine
Package: udev
Version: 168-1
Followup-For: Bug #624469
I experience this problem as well. It definitely has nothing to do with
timestamps; I use UTC, and time doesn't jump forward or backward during
the boot process.
When udev attempts to start during the boot process, it complains that
it can't
9 matches
Mail list logo