From: Michael Buesch <mbuesch@freenet.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev zombies
Date: Wed, 02 Jun 2004 18:26:15 +0000 [thread overview]
Message-ID: <200406022026.24132.mbuesch@freenet.de> (raw)
In-Reply-To: <200406011914.13245.mbuesch@freenet.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 02 June 2004 18:53, you wrote:
> I would expect them not to be there too :)
>
> Care to rebuild udev with
> make USE_LOG=true DEBUG=true
> and let us know what the syslog messages are for those dead udev
> instances?
Hm, I found out, that zombies appear only when linked agains klibc.
mb@lfs:~> ps aux|grep udev
root 380 0.0 0.0 84 64 ? S< 20:15 0:00 udevd
root 1636 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1637 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1638 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1639 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1640 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1641 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1642 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1653 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1654 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1655 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1656 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1657 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1658 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1659 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1660 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1661 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1662 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1663 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1664 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1665 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1666 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1667 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1669 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1670 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1671 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1672 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1683 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1684 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1699 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1706 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1726 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1733 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1757 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1762 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1853 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1854 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1855 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1856 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1920 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1927 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
Whoo, there are millions of debugging messages.
I'll pick up a few ones I find useful.
Jun 2 21:16:18 lfs kernel: udev[1636]: sysfs_path_is_link: stat() failed
^(This line is repeated a few times)
Jun 2 21:16:18 lfs kernel: udev[1636]: get_sysfs_device: timed out waiting for device symlink, continuing on anyway...
Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: class_dev->name = 'vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: udev->kernel_name = 'vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: kernel_number='1'
Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: name, 'vcs1' is going to have owner='root', group='root', mode = 0600
Jun 2 21:16:18 lfs kernel: udev[1636]: udev_add_device: name='vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: reading '/etc/passwd' as db file
Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: id for 'root' is '0'
Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: reading '/etc/group' as db file
Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: id for 'root' is '0'
Jun 2 21:16:18 lfs kernel: udev[1636]: creating device node '/udev/vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: make_node: preserve file '/udev/vcs1', cause it has correct dev_t
Jun 2 21:16:18 lfs kernel: udev[1636]: make_node: chmod(/udev/vcs1, 020600)
Jun 2 21:16:18 lfs kernel: udev[1636]: udevdb_add_dev: store key '/class/vc/vcs1' for device 'vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: dev_d_send: DEVNAME='/udev/vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: open directory '/etc/dev.d/vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: unable to open '/etc/dev.d/vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: open directory '/etc/dev.d/vc'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: unable to open '/etc/dev.d/vc'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: open directory '/etc/dev.d/default'
> thanks,
>
> greg k-h
PS:
and isn't that strange, too?
Jun 2 21:16:18 lfs kernel: udevd[380]: sig_handler: unhandled signal
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAvhvOFGK1OIvVOP4RAqaSAJ9vrmtNeD1yskvrYl9sOKLy625CngCgtgf6
5D+HpFjhRydQ3U0nQcJKlS8=g9yk
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2004-06-02 18:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-01 17:14 udev zombies Michael Buesch
2004-06-02 16:53 ` Greg KH
2004-06-02 18:26 ` Michael Buesch [this message]
2004-06-03 8:24 ` Harald Hoyer
2004-06-03 8:27 ` Harald Hoyer
2004-06-03 8:54 ` jnf
2004-06-04 1:45 ` jnf
2004-06-04 8:03 ` Kay Sievers
2004-06-04 8:36 ` jnf
2004-06-04 8:39 ` jnf
2004-06-04 9:32 ` Kay Sievers
2004-06-04 17:23 ` jnf
2004-06-06 10:08 ` Michael Buesch
2004-06-06 10:52 ` Kay Sievers
2004-06-06 11:16 ` Michael Buesch
2004-06-06 13:16 ` Kay Sievers
2004-06-06 13:38 ` Michael Buesch
2004-06-06 23:37 ` Kay Sievers
2004-06-07 2:20 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200406022026.24132.mbuesch@freenet.de \
--to=mbuesch@freenet.de \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).