sunrpc module doesn't work on Debian / Ubuntu - no runlevelByService impl about sos HOT 11 CLOSED

runlevelByService should have been implemented in the Ubuntu/Debian policy class, but it clearly wasn't. Anybody know how to provide the same information that is found in the redhat policy? (see sos/policies/redhat.py:50)

from sos.

So ill look at adding a method to interface with upstart to check existing processes

from sos.

Cool, thanks - might be an idea to sync up on that if you have some time? I was looking at the whole SysV/Upstart/Systemd spaghetti farm the other day and I'd like to make some cleanups here (either: one godlike startup module that handles all three, or as I'm leaning more toward right now, three separate modules for each - they are essentially orthogonal, can in some (weird) cases be installed together but also have a degree of overlap (compat. files and commands).

from sos.

Yea we should probably have a discussion on the best way to handle that

from sos.

Had a brief look at this today (to try to make a prototype cross-platform sunrpc). I can't seem to find a simple way of querying the runlevels that service $foo is enabled in on Debian/Ubuntu. I've looked at all the rc* and upstart commands and I don't see anything better than reading symlinks and parsing /etc/init stuff (which is gross).

from sos.

Parsing the output of initctl show-config seems to be the best I can find so far:

# initctl show-config| head -20
avahi-daemon
  start on (filesystem and started dbus)
  stop on stopping dbus
mountall-net
  start on net-device-up
passwd
  start on filesystem
rc
  emits deconfiguring-networking
  emits unmounted-remote-filesystems
  start on runlevel [0123456]
  stop on runlevel [!$RUNLEVEL]
rsyslog
  start on filesystem
  stop on runlevel [06]
tty4
  start on (runlevel [23] and ((not-container or container CONTAINER=lxc) or container CONTAINER=lxc-libvirt))
  stop on runlevel [!23]
udev
  start on virtual-filesystems

from sos.

Yea looks like initctl is the command referenced in the manpages for doing this sort of thing in upstart

from sos.

I'm revisiting this issue and I have a few questions :
runlevel_by_service is only used by two plugins : nfsserver & sunrpc. The other 26 plugins all use different ways of doing check_enabled().

Shouldn't we just rework these two plugins to not rely on runlevel information in order to defined them as enabled ? Most of the plugins do differently.

While I wait for your comment, I'll work on a patch set which will remove runlevel_by_service alltogether.

from sos.

Shouldn't we just rework these two plugins to not rely on runlevel information in order to defined them as enabled ? Most of the plugins do differently.

I think you should go ahead with the patch and we can review it to see if its feasible. Im guessing since the majority of other plugins tests enabled different ways we may be able to bypass 'runlevel_by_service'

from sos.

Run levels are being consigned to history anyway: what I'm interested in hearing proposals for is a service interface that's general enough to support SysV, systemd and non-Linux service management (i.e.. Windows services, Solaris SMF and OSX launchd). It should allow plug-ins to get a list of all services, as well as those enabled and disabled and to determine whether a given service is enabled or running (not the same thing!) by name.

from sos.

Closing this as the enablement check was simplified in a0410bd

from sos.