Module: sip-router Branch: master Commit: 4975d655b58033ee215d1f98daebb78556845b3a URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4975d655...
Author: Klaus Darilion klaus.mailinglists@pernau.at Committer: Klaus Darilion klaus.mailinglists@pernau.at Date: Mon Mar 14 11:01:13 2011 +0100
proper LSB return values of init script
The init script should return proper LSB error values also if kamailio ist not configured yet.
---
pkg/kamailio/deb/debian/kamailio.init | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/pkg/kamailio/deb/debian/kamailio.init b/pkg/kamailio/deb/debian/kamailio.init index a53ec3e..0f23fa4 100644 --- a/pkg/kamailio/deb/debian/kamailio.init +++ b/pkg/kamailio/deb/debian/kamailio.init @@ -93,7 +93,14 @@ fi
if [ "$RUN_KAMAILIO" != "yes" ]; then echo "Kamailio not yet configured. Edit /etc/default/kamailio first." - exit 0 + case "$1" in + status) + exit 4 + ;; + *) + exit 1 + ;; + esac fi
set -e
2011/3/14 Klaus Darilion klaus.mailinglists@pernau.at:
if [ "$RUN_KAMAILIO" != "yes" ]; then echo "Kamailio not yet configured. Edit /etc/default/kamailio first."
- exit 0
- case "$1" in
- status)
- exit 4
- ;;
- *)
- exit 1
- ;;
- esac
fi
Hi Klaus, I agree, but in case of "stop" action is should return 0 as the daemon is indeed stoped (LSB compliant).
Am 15.03.2011 00:25, schrieb Iñaki Baz Castillo:
2011/3/14 Klaus Darilion klaus.mailinglists@pernau.at:
if [ "$RUN_KAMAILIO" != "yes" ]; then echo "Kamailio not yet configured. Edit /etc/default/kamailio first."
- exit 0
- case "$1" in
- status)
exit 4;;- *)
exit 1;;- esac
fi
Hi Klaus, I agree, but in case of "stop" action is should return 0 as the daemon is indeed stoped (LSB compliant).
Is it really stoped? Kamailio is not configured so it is hard to tell if it is running or not. The script does not perform any checks to find out if Kamailio is stopped, thus I think it is more correct to indicate an error.
regards Klaus
2011/3/15 Klaus Darilion klaus.mailinglists@pernau.at:
Hi Klaus, I agree, but in case of "stop" action is should return 0 as the daemon is indeed stoped (LSB compliant).
Is it really stoped? Kamailio is not configured so it is hard to tell if it is running or not. The script does not perform any checks to find out if Kamailio is stopped, thus I think it is more correct to indicate an error.
Hi Klaus, I don't agree. If the daemon is not enabled (/etc/default/kamailio has RUN=NO) then it must be uspposed not to be running. In fact, you can not run the daemon using the init script (due to RUN=NO). Note that the init script is supposed to manage a process which has been started using same init script (so you control de PID file and so). If you run kamailio from command line by setting some other PID file then the "stop" action of the init script would not find the PID file so would also return 0. This is, a init script is not supposed to control a process started without its init script.
So I insist that the stop action should return 0 in case of kamailio not enabled in its default file.
On 15.03.2011 11:03, Iñaki Baz Castillo wrote:
2011/3/15 Klaus Darilionklaus.mailinglists@pernau.at:
Hi Klaus, I agree, but in case of "stop" action is should return 0 as the daemon is indeed stoped (LSB compliant).
Is it really stoped? Kamailio is not configured so it is hard to tell if it is running or not. The script does not perform any checks to find out if Kamailio is stopped, thus I think it is more correct to indicate an error.
Hi Klaus, I don't agree. If the daemon is not enabled (/etc/default/kamailio has RUN=NO) then it must be uspposed not to be running. In fact, you can not run the daemon using the init script (due to RUN=NO). Note that the init script is supposed to manage a process which has been started using same init script (so you control de PID file and so). If you run kamailio from command line by setting some other PID file then the "stop" action of the init script would not find the PID file so would also return 0. This is, a init script is not supposed to control a process started without its init script.
So I insist that the stop action should return 0 in case of kamailio not enabled in its default file.
(this whole discussion is very theoretically) So, what if I start kamailio with init script. Then I configure RUN=NO and then I call "stop". Then it will report 0 although kamailio is still running. Anyway, IMo if the service is not configured it should not report success.
regards klaus
PS: Feel free to fix it, I won't fix it as IMO it is not a bug.
2011/3/15 Klaus Darilion klaus.mailinglists@pernau.at:
(this whole discussion is very theoretically)
So, what if I start kamailio with init script. Then I configure RUN=NO and then I call "stop". Then it will report 0 although kamailio is still running.
And what about if I start kamailio with init script and then delete the PID file. In this case all the init actions would fail. Obviously we can suggest lot of exotic cases in which the whole mechanism gets broken. IMHO we shouldn't cover such cases.
Anyway, IMo if the service is not configured it should not report success.
Ok, then a better status code (for *any* init action) would be 4:
0 program is running or service is OK 1 program is dead and /var/run pid file exists 2 program is dead and /var/lock lock file exists 3 program is not running 4 program or service status is unknown 5-99 reserved for future LSB use 100-149 reserved for distribution use 150-199 reserved for application use 200-254 reserved
http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generi...
Regards.
On 15.03.2011 15:40, Iñaki Baz Castillo wrote:
2011/3/15 Klaus Darilionklaus.mailinglists@pernau.at:
(this whole discussion is very theoretically)
So, what if I start kamailio with init script. Then I configure RUN=NO and then I call "stop". Then it will report 0 although kamailio is still running.
And what about if I start kamailio with init script and then delete the PID file. In this case all the init actions would fail. Obviously we can suggest lot of exotic cases in which the whole mechanism gets broken. IMHO we shouldn't cover such cases.
Anyway, IMo if the service is not configured it should not report success.
Ok, then a better status code (for *any* init action) would be 4:
0 program is running or service is OK 1 program is dead and /var/run pid file exists 2 program is dead and /var/lock lock file exists 3 program is not running 4 program or service status is unknown 5-99 reserved for future LSB use 100-149 reserved for distribution use 150-199 reserved for application use 200-254 reserved
http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generi...
That's the wrong table. The correct one is:
In case of an error while processing any init-script action except for status, the init script shall print an error message and exit with a non-zero status code:
1 generic or unspecified error (current practice) 2 invalid or excess argument(s) 3 unimplemented feature (for example, "reload") 4 user had insufficient privilege 5 program is not installed 6 program is not configured 7 program is not running 8-99 reserved for future LSB use 100-149 reserved for distribution use 150-199 reserved for application use 200-254 reserved
So, can we agree on 4 for status and 6 for start/stop? :-)
2011/3/15 Klaus Darilion klaus.mailinglists@pernau.at:
That's the wrong table. The correct one is:
Sorry, I pasted the wrong text :)
In case of an error while processing any init-script action except for status, the init script shall print an error message and exit with a non-zero status code:
1 generic or unspecified error (current practice) 2 invalid or excess argument(s) 3 unimplemented feature (for example, "reload") 4 user had insufficient privilege 5 program is not installed 6 program is not configured 7 program is not running 8-99 reserved for future LSB use 100-149 reserved for distribution use 150-199 reserved for application use 200-254 reserved
So, can we agree on 4 for status and 6 for start/stop? :-)
6 seems to be a really appropriate choice :)
I don't like the meaning of 4, as init script are always supposed to be managed by root user (even if the daemon later is configured to run as other non-privileged user).
-
Iñaki Baz Castillo -
Klaus Darilion