0

My current issue is that I have a process hanging from supervisord that I want to make sure it gracefully sending network exists etc.., but by the time supervisor is brought down there is no network.

I've tracked this to the /etc/rc0.d/ folder in here I can see how K90network will be executed before S00killall which takes care of bringing down services, supervisord included. I find odd that this is the ordering because looking at S00killall it has a piece of code to avoid bringing down the network in case its needed.

[ $subsys = network ] && continue

So, I am not sure how S00killall could ever prevent network from going down if network is explicitly brought down for rc0

I am using CentOS release 6.8 (Final)

1 Answers1

1

Yes, network service is supposed to be stopped in runlevel 0 before the killall script is executed. "Killing" K* scripts are executed before "starting" S* scripts.

There's one exception when you have root filesystem mounted via NFS. "Killing" network script prevents from stopping the network to keep the root filesystem consistent. Here is the stop section of the script:

stop)
        [ "$EUID" != "0" ] && exit 4
        # Don't shut the network down if root is on NFS or a network
        # block device.
        rootfs=$(awk '{ if ($1 !~ /^[ \t]*#/ && $2 == "/" && $3 != "rootfs") { print $3; }}' /proc/mounts)
        rootopts=$(awk '{ if ($1 !~ /^[ \t]*#/ && $2 == "/") { print $4; }}' /etc/mtab)

        if [[ "$rootfs" == nfs* || "$rootopts" =~ _r?netdev ]] ; then
                net_log $"rootfs is on network filesystem, leaving network up"
                exit 1
        fi

For your "hanging" process, I would try to do the same. Put there a similar condition to keep the network up or reorder scripts so supervisord stuff is stopped before the network script is called.

dsmsk80
  • 5,757
  • 17
  • 22