You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[JENKINS-11306] Debian init script: status command exit code is always 0 #16151
Under debian Lenny, the /etc/init.d/jenkins status script always exit with return code 0, even it the service is not running. According to LSB standard, the return code should be the following:
Under debian Lenny, the /etc/init.d/jenkins status script always exit with return code 0, even it the service is not running. According to LSB standard, the return code should be the following:
The situation of LSB compliance in Debian is indeed quite unclear, there is clearly no Debian way for the status command. Now in my use-case, I would find quite convenient to have a proper exit code if the service is not running, and I am probably not the only one in that case.
Do you see any obvious case where this could have side effect?
The situation of LSB compliance in Debian is indeed quite unclear, there is clearly no Debian way for the status command. Now in my use-case, I would find quite convenient to have a proper exit code if the service is not running, and I am probably not the only one in that case.
Do you see any obvious case where this could have side effect?
In the end, it looks like its up to the maintainer of the package to decide which way to go. I have manually patched the script on my Jenkins installations and my patch is not erased after each package upgrade, if anyone wants to apply the same patch, I opened a pull request: #281
I looked at the debian bug #208010 and my reading is that the only disputed point is on a narrow point of "what exit code to return if the package is removed but not purged" (see msg #233 for example).
I further looked /etc/init.d/ssh, which uses the standard /lib/lsb/init-functions code. The pidofproc() function in this script implements the same set of exit code as the proposed change.
Furthermore, it's easy to ignore the status code if the caller doesn't care if we integrate this change, yet there's no easy workaround for the caller if we leave it out.
So on the whole, I'm going to merge this change in.
I looked at the debian bug #208010 and my reading is that the only disputed point is on a narrow point of "what exit code to return if the package is removed but not purged" (see msg #233 for example).
I further looked /etc/init.d/ssh, which uses the standard /lib/lsb/init-functions code. The pidofproc() function in this script implements the same set of exit code as the proposed change.
Furthermore, it's easy to ignore the status code if the caller doesn't care if we integrate this change, yet there's no easy workaround for the caller if we leave it out.
So on the whole, I'm going to merge this change in.
Activity
jenkins-infra-bot commentedon Oct 12, 2011
oldelvet:
Raw content of original comment:
The Debian Wiki collects together relevant information at
http://wiki.debian.org/LSBInitScripts
In particular the final comment says that Debian policy diverges from LSB in that Debian always uses return code 0.
There is much discussion at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208010
It looks to me like current Debian behaviour/best practice is to return 0 as Jenkins currently does.
jenkins-infra-bot commentedon Oct 12, 2011
Raw content of original comment:
The situation of LSB compliance in Debian is indeed quite unclear, there is clearly no Debian way for the status command. Now in my use-case, I would find quite convenient to have a proper exit code if the service is not running, and I am probably not the only one in that case.
Do you see any obvious case where this could have side effect?
In the end, it looks like its up to the maintainer of the package to decide which way to go. I have manually patched the script on my Jenkins installations and my patch is not erased after each package upgrade, if anyone wants to apply the same patch, I opened a pull request: #281
jenkins-infra-bot commentedon Nov 8, 2011
Raw content of original comment:
I looked at the debian bug #208010 and my reading is that the only disputed point is on a narrow point of "what exit code to return if the package is removed but not purged" (see msg #233 for example).
I further looked /etc/init.d/ssh, which uses the standard /lib/lsb/init-functions code. The pidofproc() function in this script implements the same set of exit code as the proposed change.
Furthermore, it's easy to ignore the status code if the caller doesn't care if we integrate this change, yet there's no easy workaround for the caller if we leave it out.
So on the whole, I'm going to merge this change in.
jenkins-infra-bot commentedon Nov 8, 2011
Raw content of original comment:
Code changed in jenkins
User: Reynald Borer
Path:
changelog.html
debian/debian/jenkins.init
http://jenkins-ci.org/commit/jenkins/2f9fff923981c7aeccca9ca88482062a7e578a24
Log:
JENKINS-11306Debian init script: return a proper status code when Jenkins is not running.jenkins-infra-bot commentedon Nov 8, 2011
Raw content of original comment:
Code changed in jenkins
User: Reynald Borer
Path:
debian/debian/jenkins.init
http://jenkins-ci.org/commit/jenkins/2cc316cb6e170b238598d0f38a8d7e7fe87c989e
Log:
JENKINS-11306Debian init script: return a proper status code when Jenkins is not running.jenkins-infra-bot commentedon Nov 8, 2011
Raw content of original comment:
Integrated in
jenkins_main_trunk #1274
JENKINS-11306Debian init script: return a proper status code when Jenkins is not running.Kohsuke Kawaguchi : 2f9fff923981c7aeccca9ca88482062a7e578a24
Files :
jenkins-infra-bot commentedon Apr 3, 2015
Raw content of original comment:
Code changed in jenkins
User: Reynald Borer
Path:
debian/jenkins.init
http://jenkins-ci.org/commit/packaging/69e2d324eb23122ddf35a4b687c5bc0589b15c23
Log:
JENKINS-11306Debian init script: return a proper status code when Jenkins is not running.Originally-From: jenkins-ci.org/commit/core/2f9fff923981c7aeccca9ca88482062a7e578a24