Bug 127977 – hotplug/coldplug runs udevsend even if booted without udev support

• Product: Gentoo Linux
• Status: VERIFIED NEEDINFO

[Description Ian Abbott 2006-03-29 05:31:51 UTC]

On a system booted without udev support (e.g. using bootparam "gentoo=noudev") but with sys-fs/udev installed and sys-apps/coldplug installed and in the "boot" runlevel, there are several error messages during boot of the form:

udevsend[1234]: main: error sending message: Connection refused

Investigation shows that udevsend is being run via the symlink /etc/hotplug.d/default/10-udev.hotplug called from /sbin/hotplug.  Maybe it should be a wrapper script (to check if udev is active) instead of a symlink?

The error messages seem harmless, so I don't mind if it's not fixed. Just thought I'd mention it.

My system is a little out of date, currently using:

  sys-fs/udev-086
  sys-apps/coldplug-20040920
  sys-apps/hotplug-20040923-r1
  sys-apps/hotplug-base-20040401

emerge --info (yes, I know it's a bit strange that I'm currently using a gentoo-sources-2.6 kernel with a 2.4 profile, but this is a test system)

Gentoo Base System version 1.12.0_pre16
Portage 2.1_pre5-r4 (default-linux/x86/no-nptl/2.4, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-ija1 i686)
=================================================================
System uname: 2.6.15-gentoo-ija1 i686 AMD Duron(tm) processor
dev-lang/python:     2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.4.26-r1
ACCEPT_KEYWORDS="x86 ~amd64 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-march=athlon -O2 -pipe"
DISTDIR="/work/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="en_GB.UTF-8"
LINGUAS="en_GB"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X aac alsa apm arts avi berkdb bitmap-fonts bzip2 cdr cjk crypt cups curl doc dri eds emboss encode firefox flac foomaticdb fortran gdbm gif glut gmp gnome gpm gstreamer gtk gtk2 gtkhtml idn imlib ipv6 java jpeg kde lcms ldap libg++ libwww mad mikmod mng motif mozsvg mp3 mpeg ncurses nls no-helper nsplugin offensive ogg opengl oss pam pdflib perl png python qemu-fast qt quicktime readline samba sdl slang softmmu spell ssl svg tcpd tiff truetype truetype-fonts type1-fonts unicode usb vorbis win32codecs xine xml xmms xv zlib elibc_glibc kernel_linux linguas_en_GB userland_GNU video_cards_radeon"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LC_ALL, LDFLAGS, MAKEOPTS

[Comment 1 Greg Kroah-Hartman (RETIRED) 2006-04-03 10:08:14 UTC]

is there some reason you aren't using udev and want to use hotplug?

coldplug is now obsoleted by the latest udev, and hotplug is about to go away too.

[Comment 2 Ian Abbott 2006-04-03 11:23:19 UTC]

Yes, I often boot a 2.4 kernel for test purposes, which obviously doesn't support udev.

Will coldplug still be supported in 2.4 profiles?

[Comment 3 Greg Kroah-Hartman (RETIRED) 2006-04-03 12:24:34 UTC]

Yes, I'm not going to remove the package, so it is still present if you want
to use 2.4 kernels.

But if you emerge udev, coldplug will be removed, so that might be a problem.

[Comment 4 Ian Abbott 2006-04-28 03:02:58 UTC]

I've unemerged coldplug, which doesn't really remove anything if config file protection is used!  I modified the left-behind /etc/init.d/coldplug to do nothing if the /dev/.udev directory exists, so it now happily coexists with udev (apart from the harmless errors from /dev/hotplug.d/default/10-udev.hotplug mentioned earlier).