Bug 1262663

Was the service running before the shutdown? Systemd will only call stop action on running stuff.

(In reply to Lukáš Nykrýn from comment #2)
> Was the service running before the shutdown? Systemd will only call stop
> action on running stuff.

Yes, The service is running. I use the chkconfig command, do not use the systemd service.  The issue was not present in RHEL7.0, was only present in RHEL7.1

Well chkconfig only enables the service. It does not start it.

Can you send me some logs from that machine?
https://wiki.freedesktop.org/www/Software/systemd/Debugging/#index2h1 and the section Shutdown Completes Eventually

1. I use chkconfig command to enable the service, then start the service.

Then I reboot the machine and find that the stop action was not called.

2. i check the document, could you tell me which information are you need.
   Could you tell me the detailed methond to collect the debug log?

(In reply to Lukáš Nykrýn from comment #4)
> Well chkconfig only enables the service. It does not start it.
> 
> Can you send me some logs from that machine?
> https://wiki.freedesktop.org/www/Software/systemd/Debugging/#index2h1 and
> the section Shutdown Completes Eventually

Just follow the instructions from the section 
"Shutdown Completes Eventually" from that page

Sorry, Could you tell me how to modify the boot option?

(In reply to Lukáš Nykrýn from comment #6)
> Just follow the instructions from the section 
> "Shutdown Completes Eventually" from that page

Put that on kernel cmdline in grub

Created attachment 1074248 [details]
the log information

The splx service did not be stopped when the system shutdown, please check the attachment log file

(In reply to Lukáš Nykrýn from comment #8)
> Put that on kernel cmdline in grub

I am running into the same problem, so I recreated a *very* minimal script that reproduces the same problem. Here it is.

--- /etc/init.d/fakeservice ---
$ cat /etc/init.d/fakeservice 
#! /bin/bash

# chkconfig: 345 98 05
# description: fakeservice

lockfile=/var/lock/subsys/fakeservice
logfile=/service.log
timestamp=`date`

case "$1" in
    start)
	echo "${timestamp} service started" >> $logfile
	touch $lockfile
	;;

    force-reload|restart)
	echo "${timestamp} service restarted" >> $logfile
	touch $lockfile
	;;

    status)
	if [ -f $lockfile ]; then
	    echo "${timestamp} service is running" >> $logfile
	else
	    echo "${timestamp} service is stopped" >> $logfile
	fi
	;;

    stop)
	echo "${timestamp} service is stopping" >> $logfile
	rm -f $lockfile
	;;

    *)
	echo "Usage: fakeservice {force-reload,restartstart,status,stop}"
	exit 1
	;;
esac
exit 0 # not always right, but this is just a test
--- EOF ---

I run "chkconfig fakeservice on" to enable it.

Start with "service fakeservice start" as root. I can verify that the lockfile is generated, and the log file is updated.

# reboot

After the machine starts up, I can only see the following.

# cat /service.log
Sun Dec 13 01:42:56 EST 2015 service started
Sun Dec 13 01:43:51 EST 2015 service started

The first line is from when I manually started the service. The second line is from systemd starting starting it on bootup. Notice there is no stop message. If I manually run "service fakeservice stop" and check the log, it shows the stop command working just fine. If I look in /etc/rc.d I see the links to kill the service in runlevel 0 and 6 as expected.

$ find /etc/rc.d/ -name "*fakeservice"
/etc/rc.d/init.d/fakeservice
/etc/rc.d/rc2.d/S98fakeservice
/etc/rc.d/rc3.d/S98fakeservice
/etc/rc.d/rc4.d/S98fakeservice
/etc/rc.d/rc5.d/S98fakeservice

I think it's pretty clear that the kill action for (some?) legacy scripts is not being invoked.

I remember running into a problem in RHEL6/CentOS6 where I needed to put a lockfile with the same name as the init script in /var/lock/subsys, i.e. in this case it's named /var/lock/subsys/fakeservice. I am doing that correctly in this case, at least according to RHEL6 but maybe for some reason in CentOS 7 the expected lock file path was changed, or there is some new additional shutdown prerequisite criteria, then maybe systemd doesn't "think" it has to stop this service.

According to the OP, this issue was not present in 7.0, and was introduced in 7.1. I can confirm it's in 7.1, but I don't have an older 7.0 release machine to test.

Please omit the line "$ cat /etc/init.d/fakeservice" at the top of the script section above. If it wasn't obvious, that wasn't intended to be part of the script and it's just how I outputted the contents. My apologies for any confusion.

I was able to get this to work. There must have been some subtle script error that wasn't being picked up by 'bash -n'.

Also some other subtle differences, on RHEL6 your shutdown script was invoked by calling the /etc/rc0.d/fakeservice/K05fakeservice script. I used to depend on that in my init script to log a special message that the reason the service was stopping is due to a reboot or shutdown if $0 matched K05fakeservice, as opposed to a normal 'service fakeservice stop' command. However, now it seems to be killed by systemd by running /etc/rc.d/init.d/fakeservice (this is what $0 is set to when your script is run). So it's still possible to tell when someone did 'service foo stop' versus 'reboot'/'poweroff'/etc...

For a 'service foo stop', $0 = /etc/init.d/service
For a poweroff/reboot event, $0 = /etc/rc.d/init.d/cloudarray

This is probably very brittle though, and I think we are being nudged to switch to systemd.

In your initscript, do you source /etc/init.d/functions?
Because otherwise you are missing some systemd wrappers.

My script is perl script, so did no source /etc/init.d/functions.

Hmm that is the problem, systemd does not know that the service is running, so it will not stop it.

Maybe we should modify service command to run it through systemctl every time for the start action.

We can't track services which does not parse the rc.d/init.d/function

Hi Lukáš,


    Could you tell me the detailed logic why the systemd does not know that the servic is running and why team can't track the services.

    Thanks in advancce.

Derrick

If you are using shell and source function, than during invocation of initscripts starts this code https://git.fedorahosted.org/cgit/initscripts.git/tree/rc.d/init.d/functions#n593 which call systemctl and this calls the initsript again, but this time systemd can place the process into its cgroup.