whenever cups is updated, using "/etc/init.d/cupsd stop||restart" doesn't work. Stopping cups fails. I tried to manually execute start-stop-daemon --stop --exec /usr/sbin/cupsd -v and it just reports "No /usr/sbin/cupsd found running; none killed." This problem might be more specific to start-stop-daemon. According to the man page for start-stop-daemon, --exec attempts to check for the process that's an instance of the executable via /proc/pid/exe. I've manually checked this and exe is linked to /usr/sbin/cupsd so I'm not entirely sure what's going on. Currently, in order to properly restart cups, I always manually kill the process, run /etc/init.d/cupsd zap; /etc/init.d/cupsd start. This sorta beats the point of having a nice init script to do it for you. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I can confirm this. Before the emerge, the symlink is correct: adora root # ls -l /proc/$(pidof cupsd)/exe lrwxrwxrwx 1 root root 0 Nov 3 17:34 /proc/21460/exe -> /usr/sbin/cupsd But after the emerge, the symlink is dangling: adora root # ls -l /proc/$(pidof cupsd)/exe lrwxrwxrwx 1 root root 0 Nov 3 17:34 /proc/21460/exe -> /var/tmp/portage/cups-1.1.20-r5/image/usr/sbin/cupsd (deleted) Note that the cupsd pid did not change. I currently have maketest in my FEATURES, which starts a cupsd process as part of the tests. To be sure, I disabled maketest and had the same results. I really can't figure out how or why the symlink is being changed. Portage 2.0.51-r2 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9 i686) ================================================================= System uname: 2.6.9 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.4.16 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.21-r1,sys-kernel/linux-headers-2.4.19-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc distlocks maketest sandbox strict userpriv" GENTOO_MIRRORS="http://open-systems.ufl.edu/mirrors/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.oregonstate.edu" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://dwc.homedns.org/gentoo-portage" USE="3dnow X aalib acpi alsa apm avi berkdb bitmap-fonts cdr crypt cups divx4linux dvd encode f77 fbcon foomaticdb gdbm gif gnome gpm gtk gtk2 gtkhtml guile imlib java jpeg kde libg++ libwww mad maildir mikmod mmx motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pda pdflib perl png python qt quicktime readline sdl slang spell ssl svga tcpd tiff truetype unicode x86 xml xml2 xmms xv xvid zlib"
screwed me up too.
*** Bug 85629 has been marked as a duplicate of this bug. ***
BUG 85629 suggests what seems to be the correct solution to this bug.
gentoo's policy on upgrading packages is not to touch running daemons, so this is not a solution
This is fixed in baselayout-1.12.0_pre14
