baselayout-2.0.0_rc2-r1 doesn't stop all init-scripts when switching to other runlevel Reproducible: Always Steps to Reproduce: # rc-status default Runlevel: default acpid [ started ] cpufreqd [ started ] cupsd [ started ] dbus [ started ] hald [ started ] local [ started ] net.eth0 [ inactive ] net.eth1 [ started ] ntpd [ started ] syslog-ng [ started ] vixie-cron [ started ] xdm [ started ] # rc-status battery Runlevel: battery acpid [ started ] cpufreqd [ started ] net.eth1 [ started ] syslog-ng [ started ] xdm [ started ] # rc battery local | * Stopping local ... [ ok ] cupsd | * Stopping cupsd ... [ ok ] ntpd | * Stopping ntpd ... [ ok ] vixie-cron | * Stopping vixie-cron ... [ ok ] Actual Results: # rc-status default Runlevel: default acpid [ started ] cpufreqd [ started ] cupsd [ stopped ] dbus [ started ] hald [ started ] local [ stopped ] net.eth0 [ inactive ] net.eth1 [ started ] ntpd [ stopped ] syslog-ng [ started ] vixie-cron [ stopped ] xdm [ started ] Notice that dbus, hald and net.eth0 are not stopped Expected Results: dbus [ stopped ] hald [ stopped ] net.eth0 [ stopped ] These init-scripts are not in battery runlevel and should be stopped. # emerge --info Portage 2.1.3.5 (default-linux/x86/2006.1, gcc-4.2.0, glibc-2.6.1-r0, 2.6.21-gentoo i686) ================================================================= System uname: 2.6.21-gentoo i686 Intel(R) Pentium(R) M processor 1.60GHz Gentoo Base System release 2.0.0_rc2 Timestamp of tree: Tue, 14 Aug 2007 09:30:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17-r1 sys-devel/gcc-config: 1.4.0 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium-m -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=pentium-m -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--noconfmem" FEATURES="ccache distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.ISO-8859-1" LC_ALL="en_US.ISO-8859-1" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/ftd4linux /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aac acpi aiglx alsa ares arts artswrappersuid asf bash-completion bzip2 cairo cddb cisco connectionstatus crypt css cups dbus directfb dri dvd dvdread encode exif fasttrack ffmpeg firefox flac foomaticdb gif glitz gnutella gphoto2 gtk gtkhtml hal history hpn ilbc imagemagick irc java jpeg kde kdeenablefinal kdehiddenvisibility kerberos libnotify mad midi mmx mng mozdevelop mp3 mp4 mpeg musicbrainz netmeeting network-cron nfs nptl nptlonly nsplugin ogg openft opengl pdf plugins png portaudio ppds python qt3 qt3support qt4 quicktime rdesktop readline real ruby samba sasl speex spell sqlite sse sse2 ssl statistics svg sysfs theora threads tiff tk translator truetype unicode usb vcd vorbis wavpack wifi win32codecs x264 x86 xcomposite xforms xine xorg xv xvid xvmc zlib zrtp" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="i810" Unset: CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
net.eth0 is probably coldplugged so it's "added" to the boot runlevel. You can control that behaviour in /etc/conf.d/rc The xdm init script "uses" hald which in turn "needs" dbus, so they are not stopped. In other words, this is not a bug :) To demonstrate, simply remove xdm from the battery runlevel and try again, as I don't think any other init scripts there use hald Re-open if you disagree
(In reply to comment #1) > net.eth0 is probably coldplugged so it's "added" to the boot runlevel. > You can control that behaviour in /etc/conf.d/rc You are right (as usual ;-) ), I didn't know that coldplugging adds the init-script to the boot runlevel. When I add RC_PLUG_SERVICES="!net.eth0 !net.eth1" to /etc/conf.d/rc it works as expected. What do you think about transferring "owner runlevel" for init-scripts that are coldplugged but are also specified in a runlevel other than boot? > The xdm init script "uses" hald which in turn "needs" dbus, so they are not > stopped. > > In other words, this is not a bug :) > To demonstrate, simply remove xdm from the battery runlevel and try again, as I > don't think any other init scripts there use hald > > Re-open if you disagree > The reason why I reopen this bug is that current behavior isn't consistent (IMHO). If you boot a system the init-scripts that are defined in a "use clause" are only started if the scripts are in the same runlevel as the init-scripts that have the use clause. However if you change manually to a runlevel this rule doesn't apply, then it's ok if they are not in the same runlevel. I think the behavior when manually changing and booting should be the same (again IMHO).
(In reply to comment #2) > You are right (as usual ;-) ), I didn't know that coldplugging adds the > init-script to the boot runlevel. When I add RC_PLUG_SERVICES="!net.eth0 > !net.eth1" to /etc/conf.d/rc it works as expected. What do you think about > transferring "owner runlevel" for init-scripts that are coldplugged but are > also specified in a runlevel other than boot? Not sure what you mean here. The boot and default runlevels are seperated like so just for bringing the system up. Once it's up it's effectively joined anyway. To see this, goto tty1 and enter single user mode and exit it # rc single .... exit (or ctrl-d) > > The xdm init script "uses" hald which in turn "needs" dbus, so they are not > > stopped. > > > > In other words, this is not a bug :) > > To demonstrate, simply remove xdm from the battery runlevel and try again, as I > > don't think any other init scripts there use hald > > > > Re-open if you disagree > > > > The reason why I reopen this bug is that current behavior isn't consistent > (IMHO). If you boot a system the init-scripts that are defined in a "use > clause" are only started if the scripts are in the same runlevel as the > init-scripts that have the use clause. However if you change manually to a > runlevel this rule doesn't apply, then it's ok if they are not in the same > runlevel. I think the behavior when manually changing and booting should be the > same (again IMHO). So if A uses B and really starts using it and B stops what should A do at this point? We have two options Keep B running to maintain A - this is what we currently do Stop A, then stop B, then start A so that it knows B is no longer there. Is this what you want, or something else?
(In reply to comment #3) > (In reply to comment #2) > > What do you think about > > transferring "owner runlevel" for init-scripts that are coldplugged but are > > also specified in a runlevel other than boot? > > Not sure what you mean here. > The boot and default runlevels are seperated like so just for bringing the > system up. Once it's up it's effectively joined anyway. > > To see this, goto tty1 and enter single user mode and exit it > # rc single > .... > exit > (or ctrl-d) That's not entirely correct, if you you switch to any runlevel other than single nothing happens with the init-scripts from the boot runlevel. By transferring the "ownership" for coldplugged init-scripts that are also defined in the default runlevel to the default runlevel then these init-scripts are evaluated if you change to another runlevel. > > The reason why I reopen this bug is that current behavior isn't consistent > > (IMHO). If you boot a system the init-scripts that are defined in a "use > > clause" are only started if the scripts are in the same runlevel as the > > init-scripts that have the use clause. However if you change manually to a > > runlevel this rule doesn't apply, then it's ok if they are not in the same > > runlevel. I think the behavior when manually changing and booting should be the > > same (again IMHO). > > So if A uses B and really starts using it and B stops what should A do at this > point? We have two options > > Keep B running to maintain A - this is what we currently do > Stop A, then stop B, then start A so that it knows B is no longer there. > > Is this what you want, or something else? > Actually we have another option; Just stop B and keep A running, in the example I gave you, xdm doesn't break (or even notice) when hald and dbus are stopped while X is running. There are so many use cases that it's impossible to choose a single option for all init-scripts. In some cases it's unnecessary to restart the init-scripts in other cases not restarting the init-script can break something. It would be very handy when it's possible to define in a configurationfile what a init-script should do when you change to another runlevel that doesn't have a started "use dependency init-script" in it. My personal preference/use case would be the possibility to switch to another runlevel and only the init-scripts in that specific runlevel are active, everything else is stopped (unless there is a "need dependency"). Do you think it's worth the effort to make this possible?
Created attachment 128378 [details, diff] Stop services not needed See how this patch works for you. I can see your reasoning. I suppose if it's really needed then it would be "need" instead of "use", so the application should be able to handle it suddenly vanishing. xdm is a special case though, as it's not really xdm that needs hald - the the DE like KDE or GNOME that does once the user logs in :)
(In reply to comment #5) > Created an attachment (id=128378) [edit] > Stop services not needed > > See how this patch works for you. The patch works great. Thanks a lot! > I can see your reasoning. I suppose if it's really needed then it would be > "need" instead of "use", so the application should be able to handle it > suddenly vanishing. > > xdm is a special case though, as it's not really xdm that needs hald - the the > DE like KDE or GNOME that does once the user logs in :) Yes, I know, I haven't seen any breakage in KDE if dbus/hald isn't available anymore. What is your opinion about transferring coldplugged scripts from boot runlevel to default runlevel if the coldplugged scripts are defined in default runlevel? Baselayout could check if a coldplug script candidate is in the default runlevel and apply the same logic as if it is defined in RC_PLUG_SERVICES="!<coldplug script candidate>". Then the script isn't coldplugged and therefor is under control of the default runlevel. rc to another runlevel evaluates all scripts except the scripts in the boot runlevel. If it is explicitly defined in default runlevel then it will be stopped if it's not in the other runlevel.
(In reply to comment #6) > > xdm is a special case though, as it's not really xdm that needs hald - the the > > DE like KDE or GNOME that does once the user logs in :) > > Yes, I know, I haven't seen any breakage in KDE if dbus/hald isn't available > anymore. Well, I know for sure the GNOME team will scream murder as things like CD automounting and stuff won't work anymore ;) > What is your opinion about transferring coldplugged scripts from boot runlevel > to default runlevel if the coldplugged scripts are defined in default runlevel? Doesn't make any difference - if it's in the default runlevel then it takes priority over anything coldplugged. Well, the bug here is fixed anyway - if you have more beef open a new bug :) Thanks
(In reply to comment #7) > (In reply to comment #6) > > > xdm is a special case though, as it's not really xdm that needs hald - the the > > > DE like KDE or GNOME that does once the user logs in :) > > > > Yes, I know, I haven't seen any breakage in KDE if dbus/hald isn't available > > anymore. > > Well, I know for sure the GNOME team will scream murder as things like CD > automounting and stuff won't work anymore ;) lol, we don't want to mess with the GNOME team ;-) > > What is your opinion about transferring coldplugged scripts from boot runlevel > > to default runlevel if the coldplugged scripts are defined in default runlevel? > > Doesn't make any difference - if it's in the default runlevel then it takes > priority over anything coldplugged. That's not correct or I misunderstand you, but currently anything coldplugged takes priority over scripts in the default runlevel. It's no problem though, this behavior can be changed with RC_PLUG_SERVICES="!<coldplug script candidate>". > Well, the bug here is fixed anyway - if you have more beef open a new bug :) > Thanks Thank you very much for your time and cooperation, it is really appreciated.
