#90 Linux service scripts not compatible with chkconfig
Linux service scripts, generated under /etc/init.d/, do not survive chkconfig changes at least in SUSE Linux Enterprise Server.
The problem is that these lines in startup script, which are coming from daemon.vm file, are not updated with actual values, which would be compatible with chkconfig/insserv:
Required-Start: $start_dependencies
Required-Stop: $stop_dependencies
Default-Start: $w_start_levels
Default-Stop: $w_stop_levels
For example, I run following commands:
chkconfig <service_name> off
chkconfig <service_name> on</service_name></service_name>
After this, my service get priority S02, which is WAY too early, since e.g. network is started only at S03!
Two bug proposals:
1) There should be some way to set Required-Start and also Should-Start dependencies (see /etc/init.d/skeleton for more details) via wrapper.conf file. Then yajsw should use that information and update the generated startup script accordingly.
2) Yajsw should update the start and stop levels correctly into the generated startup script: running wrapper.jar currently creates the startup links (under rcX.d directoris), as specified by wrapper.daemon.update_rc property in wrapper.conf file, but the generated startup scripts lacks these values, rendering the startup scripts uncompatible with changes done with chkconfig.
Notice that it does not matter which service I modify with chkconfig, as chkconfig/insserv will update all startup links to match service startup files! That is, if I modify e.g. ntp daemon to start at different run levels, it will break the startup of yajsw generated services.
Related
Sorry, I didn't realize the formatting help soon enough. Correcting the formatting for these lines:
# Required-Start: $start_dependencies
# Required-Stop: $stop_dependencies
# Default-Start: $w_start_levels
# Default-Stop: $w_stop_levels
And also for these commands:
chkconfig off <my service>
chkconfig on <my service>
hello,
thank you for pointing this out.
this should be solved for the next release.
pls test it on your platform and let me know if it is ok.
-- Ron
Hi Ron,
I'll try it out today or by the latest early next week. Thanks for the fix!
Cheers,
Jari
On Thu, Dec 19, 2013 at 5:13 PM, rzo rzorzorzo@users.sf.net wrote:
Related
Bugs:
#90Hi,
I tried this out, but it didn't still work quite as expected. Here are my findings:
Start and stop levels are now working as they should, and Default-Start and Default-Stop lines in the generated Linux service script are correctly filled with appropriate run level numbers. A good fix!
However, Required-Start and Required-Stop, i.e. the start and stop dependencies part in Linux startup scripts, are both always empty! That is, the dependencies are not listed there, but also the "$start_dependencies" and "$stop_dependencies" strings are not there anymore, so it works differently, but not correctly yet.
I tested this by adding following line to my wrapper.conf file, right after the wrapper.daemon.update_rc line:
wrapper.ntservice.stop_dependency = $network
Then I ran following command:
sudo java -jar wrapper.jar -i conf/wrapper.conf
, and checked the generated service file (i.e. /etc/init.d/my_service).
Could it be that there's a typo in the instructions, i.e. the variable name that I tried to use (wrapper.ntservice.stop_dependency) in wrapper.conf file is wrong?
I also did try with "wrapper.daemon.stop_dependency" variable name, and I also tried "wrapper.daemon.start_dependency" variable, but the result was same, Required-Start and Required-Stop both remained empty.
Btw. At least I believe that Required-Start is much more relevant than Required-Stop! If Required-Start is empty, the startup happens usually way too early, by default at "S02" priority, which is even before the network! If Required-Stop is empty, the stopping just happens at "K01" priority, which is usually fine, i.e. I usually want that my service stops as early as possible, e.g. before network.
seems to be resolved in 12.04
if this is still an issue pls reopen.
note: Required-Start and stop are set to the same values:
the correct property to use:
wrapper.ntservice.dependency.<n></n>