Forcing /var/lock/subsys file if init script didn't start a given service?
Posted 01-30-2014 at 03:46 PM by MensaWater
Tags init, init scripts, lockfile
Today I was creating a new init script on RHEL6. This isn't something I've had to do often.
I ran into the common problem that although the new script successfully started and stopped the service from command line and also started it on reboot it did NOT stop it before the server went down when the shutdown was done.
The reason for that is because on RHEL they run a killall script that checks for files in /var/lock/subsys and only run the "stop" portion of the individual init scripts if there is a file in that directory of the same name as the base init script. (e.g. If it is /etc/init.d/netbackup then the lock file must be named /var/lock/subsys/netbackup.) This lockfile is typically created at the "start" section of the specific init script then removed in the stop section. I won't go into detail on that as it has been discussed in many posts. If you examine existing scripts in /etc/init.d you'll see how to add the creation and the removal in the start/stop section of most (if not all) of them.
The link here goes into reasoning and is where I discovered the comment about killall:
http://www.redhat.com/magazine/008ju...s/tips_tricks/
The reason for my post is that while I was able to resolve my issue relatively quickly my init script was based on calling a vendor provided script in the start, stop (and status) sections. The question is what happens if someone calls the original vendor provided script instead of the init script?
I didn't want to edit the original script on the off chance it gets changed by a later patch. Also since that script runs as a specific user I found that user does not have write access to /var/lock/subsys so I couldn't force it to write there without changing that directory's permissions which I really didn't want to do either. (I'd have same issue if I put a wrapper script.)
However, after some thought it occurred to me this really is a non-issue. So long as the process was started by the init script the lock file will have been created. If the specific user later runs the original script rather than the init script to start the service they almost certainly would have first used that same script to stop it. Since the stop from original script does not remove the lock file any more than its start creates it then the original lockfile from most recent boot (or run of the init script) will still be there on the next system reboot so it will be stopped properly.
Of course this doesn't address the case where the init script didn't run properly on boot (so didn't create the lockfile) but my assumption is that in such a case I'd be involved as System Administrator and would use "service <init script> start" rather than the original vendor script once I'd resolved whatever problem prevented the start.
The above may seem obvious to others but wasn't to me and I didn't find where anyone had mentioned it in the plethora of posts that talked about /var/lock/subsys.
I ran into the common problem that although the new script successfully started and stopped the service from command line and also started it on reboot it did NOT stop it before the server went down when the shutdown was done.
The reason for that is because on RHEL they run a killall script that checks for files in /var/lock/subsys and only run the "stop" portion of the individual init scripts if there is a file in that directory of the same name as the base init script. (e.g. If it is /etc/init.d/netbackup then the lock file must be named /var/lock/subsys/netbackup.) This lockfile is typically created at the "start" section of the specific init script then removed in the stop section. I won't go into detail on that as it has been discussed in many posts. If you examine existing scripts in /etc/init.d you'll see how to add the creation and the removal in the start/stop section of most (if not all) of them.
The link here goes into reasoning and is where I discovered the comment about killall:
http://www.redhat.com/magazine/008ju...s/tips_tricks/
The reason for my post is that while I was able to resolve my issue relatively quickly my init script was based on calling a vendor provided script in the start, stop (and status) sections. The question is what happens if someone calls the original vendor provided script instead of the init script?
I didn't want to edit the original script on the off chance it gets changed by a later patch. Also since that script runs as a specific user I found that user does not have write access to /var/lock/subsys so I couldn't force it to write there without changing that directory's permissions which I really didn't want to do either. (I'd have same issue if I put a wrapper script.)
However, after some thought it occurred to me this really is a non-issue. So long as the process was started by the init script the lock file will have been created. If the specific user later runs the original script rather than the init script to start the service they almost certainly would have first used that same script to stop it. Since the stop from original script does not remove the lock file any more than its start creates it then the original lockfile from most recent boot (or run of the init script) will still be there on the next system reboot so it will be stopped properly.
Of course this doesn't address the case where the init script didn't run properly on boot (so didn't create the lockfile) but my assumption is that in such a case I'd be involved as System Administrator and would use "service <init script> start" rather than the original vendor script once I'd resolved whatever problem prevented the start.
The above may seem obvious to others but wasn't to me and I didn't find where anyone had mentioned it in the plethora of posts that talked about /var/lock/subsys.
Total Comments 0
