For e.g. when you stop the nfs service, many other services (like portmap) do not stop, although they are not used by anyone...they are useless without nfs. So all dependencies which started cause of a service started by a user (the world set), should also be stopped when this service (which was manually trigger by the user) is stopped after checking if the dependencies are not required by any other service. It will be good if there's a 'depclean' option for services which stops all the service which the user (or the runlevel) did not trigger... or vacant dependencies. Reproducible: Always Steps to Reproduce:
Supposedly your 're running ~arch, you're using baselayout-2 which is openrc, if you read your /etc/rc.conf you'll see # Do we allow any started service in the runlevel to satisfy the depedency # or do we want all of them regardless of state? For example, if net.eth0 # and net.eth1 are in the default runlevel then with rc_depend_strict="NO" # both will be started, but services that depend on 'net' will work if either # one comes up. With rc_depend_strict="YES" we would require them both to # come up. #rc_depend_strict="YES" Does the above option helps you? I resolve the bug as TEST-REQUEST. Reopen only if you have something more specific to report, and include your emerge --info output. Thank you for this report.
No, meant if net.eth0 and net.eth1 are stopped, the services which are the dependencies of both will also be killed.
first off, portmap is not "useless without nfs". it is used with all the rpc related services. ignoring that, i dont see this being worth the hassle. no state is maintained that declares the source of the service start (user, runlevel, implicit, etc...). adding that info doesnt really gain us anything except for this new (and questionably useful) functionality. if you want to get back to a clean state, just reset to a known runlevel state. you can give `rc` the current runlevel and it'll work as expected.
It will kill the processes also? If this feature is not implemented, we have to 'reboot' again and again to clear the orphan process up. As of NFS, I just gave an e.g. here portmap starts only cause of NFS, and should also stop with NFS... and rpc should also stop. You might like to set this feature on low priority, but atleast do give it a consideration, it is a nice enhancement.
baselayout deals with services. if `/etc/init.d/foo status` says it is stopped but there are still processing laying around, that really has nothing to do with baselayout. the package and/or its init.d script is broken and you should report a bug about it. portmap needs wrt nfs is specific to an environment and not something that would ever be coded in a script. the gap between "implicitly started services" and just using `rc <a known runlevel>` isnt big enough imo to warrant the otherwise unnecessary overhead. especially considering how flexible runlevels are now: you can stack them ad infinitum. my laptop stacks a few networking runlevels on top of the "default" runlevel: $ ls -l /etc/runlevels/wireless/ lrwxrwxrwx 1 root root 10 Dec 23 20:01 default -> ../default lrwxrwxrwx 1 root root 19 Dec 23 23:26 dnsmasq -> /etc/init.d/dnsmasq lrwxrwxrwx 1 root root 20 Dec 5 07:05 netmount -> /etc/init.d/netmount lrwxrwxrwx 1 root root 21 Dec 23 23:26 net.wlan0 -> /etc/init.d/net.wlan0 $ ls -l /etc/runlevels/wired/ lrwxrwxrwx 1 root root 10 Dec 23 23:33 default -> ../default lrwxrwxrwx 1 root root 20 Dec 22 15:51 net.eth0 -> /etc/init.d/net.eth0 lrwxrwxrwx 1 root root 20 Dec 5 07:05 netmount -> /etc/init.d/netmount $ ls -l /etc/runlevels/default lrwxrwxrwx 1 root root 17 Dec 21 18:48 acpid -> /etc/init.d/acpid lrwxrwxrwx 1 root root 17 Dec 8 02:39 dcron -> /etc/init.d/dcron lrwxrwxrwx 1 root root 17 Dec 5 07:05 local -> /etc/init.d/local lrwxrwxrwx 1 root root 19 Dec 8 02:39 metalog -> /etc/init.d/metalog lrwxrwxrwx 1 root root 19 Dec 18 07:28 openvpn -> /etc/init.d/openvpn lrwxrwxrwx 1 root root 16 Dec 5 06:53 sshd -> /etc/init.d/sshd lrwxrwxrwx 1 root root 26 Dec 5 07:05 udev-postmount -> /etc/init.d/udev-postmount
is the current functionality enough to support your needs ?
Yes. Thanks.
Partially but... rpc.statd doest not get stopped when running rc default and also net.eth0 does not get stopped.
i need real details before i can comment on why. are the init.d scripts still started or are the processes still running ? run and post as attachment the output of: rc-status --all /etc/init.d/<script you think should be stopped> status
/etc/init.d/nfs start portmap | * Starting portmap ... [ ok ] rpc.statd | * Starting NFS statd ... nfs | * nfs: waiting for rpc.statd (50 seconds) nfs | * nfs: waiting for rpc.statd (41 seconds) nfs | * nfs: waiting for rpc.statd (32 seconds) ^Cnfs | * nfs: caught SIGINT, aborting rpc.statd | * rpc.statd: caught SIGINT, aborting localhost de # rc default portmap | * Stopping portmap ... [ ok ] localhost de # rc-status --all Runlevel: beta hald [ started ] local [ started ] Runlevel: boot hwclock [ started ] modules [ started ] fsck [ started ] root [ started ] mtab [ started ] localmount [ started ] swap [ started ] termencoding [ started ] hostname [ started ] sysctl [ started ] bootmisc [ started ] keymaps [ started ] consolefont [ started ] fbcondecor [ started ] procfs [ started ] urandom [ started ] Runlevel: default hald [ started ] local [ started ] Runlevel: shutdown savecache [ stopped ] killprocs [ stopped ] mount-ro [ stopped ] Runlevel: nonetwork local [ started ] Runlevel: sysinit dmesg [ started ] udev [ started ] devfs [ started ] Runlevel: single Dynamic Runlevel: hotplugged net.eth0 [ started ] Dynamic Runlevel: needed sysfs [ started ] dbus [ started ] Dynamic Runlevel: manual Here, the rpc.statd process is still running but rc default will not stop it (actually rc doesn't even know it has started, but the process is running), I have to kill it manually.
i wasnt kidding when i said "post as an attachment". your comment is all garbled because you inlined it. `rc-status -u` would be useful too. but you didnt post what i asked for: what does `/etc/init.d/rpc.statd status` say ? your output looks like you did ctrl+c in the middle there. that's a terrible idea for any service and not the original issue you brought up here.
Yeah, I did cntrl C...actually I had to cause the NFS modules were not loaded. Attaching....
No, actually it is working as expected if the process starts successfully. It will stop portmapper cause it started successfully. So, not a big issue I guess. The only issue is that it does not stop processors which did not start completely. In that case even - etc/init.d/rpc.statd stop rpc.statd | * WARNING: rpc.statd is already stopped But actually the process is running.
