OpenSuse 12.2
Based on the /etc/init.d/skeleton I’ve made a new service script named “service.test” replacing all what is needed (binary name, conf file, etc.)
When i launch it (using: # service service.test start) it fails to launch. The /var/log/messages displays:
Jun 2 11:50:02 aforsrv service.test[26037]: Starting Service test Usage: /home/data2/sources/compiled/service.bin [command]
Jun 2 11:50:02 aforsrv service.test[26037]: Where command is one of the following:
Jun 2 11:50:02 aforsrv service.test[26037]: -i --install To install the program as a service
Jun 2 11:50:02 aforsrv service.test[26037]: -u --uninstall To uninstall the service
Jun 2 11:50:02 aforsrv service.test[26037]: -r --run To run the service
Jun 2 11:50:02 aforsrv service.test[26037]: An unhandled exception occurred at $000000000046E48A :
Jun 2 11:50:02 aforsrv service.test[26037]: EInOutError :
Jun 2 11:50:02 aforsrv service.test[26037]: $000000000046E48A
Jun 2 11:50:02 aforsrv service.test[26037]: $0000000000497C43 line 233 of ../lib/simplelogger.pas
Jun 2 11:50:02 aforsrv service.test[26037]: $0000000000473316 line 48 of DaemonMapper.pas
Jun 2 11:50:02 aforsrv service.test[26037]: $0000000000471C27
Jun 2 11:50:02 aforsrv startproc: startproc: exit status of parent of /home/data2/sources/compiled/service.bin: 217
Jun 2 11:50:02 aforsrv service.test[26037]: ..failed
Jun 2 11:50:02 aforsrv systemd[1]: service.test.service: control process exited, code=exited status=7
Jun 2 11:50:02 aforsrv systemd[1]: Unit service.test.service entered failed state.
The program itself is written in FPC using Lazarus and launched on its own it runs perfectly well:
./service.bin -r ( the -r parameter tells the program to run as a service).
Well, as 12.2 is bit old (and out of support) and also the way to start services using init is superseded by systemd, it could be a bit difficult for others to replay what you did.
A few suggestions though.
Did you take into account that the big difference between starting such a script from the CLI and from somwhere within the system is that the process environnment variables will be completely different (read most will be not there). Allways use full absolute pathes when calling things, etc.
I do not know for sure, but somewhere in my memory it says that those scripts are ‘sourced’ and thus should contain statements in the same language as the mother script (either sh or bash).
There is (in fact was) a skeleton script somewhere in /etc/init.d or so that you only had to fill in. Complete with the coment statements that where nevertheless no coment for higher tools like YaST and that configured the sequence of the script in the starting/stopping ctions and more.
But as said, it is all a bit old already and I can not check with any existing system here.
Did you take into account that the big difference between starting such a script from the CLI and from somwhere within the system is that the process environnment variables will be completely different (read most will be not there). Allways use full absolute pathes when calling things, etc.
Done. Nothing extra added except the line which launches the service (see script snippet):
case "$1" in
start)
echo -n "Starting Service test "
## Start daemon with startproc(8). If this fails
## the return value is set appropriately by startproc.
/sbin/startproc $FOO_BIN -r
# Remember status and be verbose
rc_status -v
;;
Don’t smile, I left the original script variable names but contents are ok. lol!
I only added the “-r” parameter needed by the program itself.
Antonio.
You should describe everything you did creating and registering the script as a service.
Can’t know if you missed a step if you don’t describe every step in detail.
> Code:
> --------------------
> Jun 2 11:50:02 aforsrv service.test[26037]: Starting Service test Usage: /home/data2/sources/compiled/service.bin [command]
> Jun 2 11:50:02 aforsrv service.test[26037]: Where command is one of the following:
> Jun 2 11:50:02 aforsrv service.test[26037]: -i --install To install the program as a service
> Jun 2 11:50:02 aforsrv service.test[26037]: -u --uninstall To uninstall the service
> Jun 2 11:50:02 aforsrv service.test[26037]: -r --run To run the service
> Jun 2 11:50:02 aforsrv service.test[26037]: An unhandled exception occurred at $000000000046E48A :
> Jun 2 11:50:02 aforsrv service.test[26037]: EInOutError :
> Jun 2 11:50:02 aforsrv service.test[26037]: $000000000046E48A
> Jun 2 11:50:02 aforsrv service.test[26037]: $0000000000497C43 line 233 of …/lib/simplelogger.pas
> Jun 2 11:50:02 aforsrv service.test[26037]: $0000000000473316 line 48 of DaemonMapper.pas
> Jun 2 11:50:02 aforsrv service.test[26037]: $0000000000471C27
> Jun 2 11:50:02 aforsrv startproc: startproc: exit status of parent of /home/data2/sources/compiled/service.bin: 217
> Jun 2 11:50:02 aforsrv service.test[26037]: …failed
> Jun 2 11:50:02 aforsrv systemd[1]: service.test.service: control process exited, code=exited status=7
> Jun 2 11:50:02 aforsrv systemd[1]: Unit service.test.service entered failed state.
> --------------------
>
>
> The program itself is written in FPC using Lazarus and launched on its
> own it runs perfectly well:
> # ./service.bin -r ( the -r parameter tells the program to run as a
> service).
You have forgotten to handle nicely the case when the user does not give
the “-r”. Your program detects that the entry parameters are wrong,
produces the corresponding help output, and then crashes, with a typical
fpc crash output.
If you are calling “Terminate”, you also need to call “Exit” after it.
Just found that out this minute…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Sorry guys, everything runs well.
I restarted the service script again from /etc/init.d/skeleton changing 4 lines and all runs OK.
I probably forget two or three things:
OK, nice you got it running this time. But please consider going to a supported openSUSE version. That will not only provide you with regular security updates (where you now lag more and more behind the threads of the nasty world), but also you will use the same software (version) of the people here, which will increase the amount and quality of the help you may get here.