From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Buesch Date: Wed, 02 Jun 2004 18:26:15 +0000 Subject: Re: udev zombies Message-Id: <200406022026.24132.mbuesch@freenet.de> List-Id: References: <200406011914.13245.mbuesch@freenet.de> In-Reply-To: <200406011914.13245.mbuesch@freenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org -----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] root 1637 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1638 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1639 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1640 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1641 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1642 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1653 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1654 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1655 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1656 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1657 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1658 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1659 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1660 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1661 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1662 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1663 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1664 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1665 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1666 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1667 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1669 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1670 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1671 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1672 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1683 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1684 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1699 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1706 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1726 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1733 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1757 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1762 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1853 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1854 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1855 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1856 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1920 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] root 1927 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] 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