Re: wrong exit code for sv status in lsb mode

2019-04-17 Thread James Byrne
Hi Gerrit, On 13/03/2019 08:04, Gerrit Pape wrote: > I'm looking forward to do a maintenance release of runit eventually and > am collecting patches. I'm glad to hear that you're collecting patches for a maintenance release. In case you don't already have these, please can I ask you to consider

Re: wrong exit code for sv status in lsb mode

2019-03-13 Thread David Mountney via supervision
We went ahead and applied the patch in GitLab back in January: https://gitlab.com/gitlab-org/omnibus-gitlab/commit/cdecb4ecc52f8f9aa845df5e73473f2b3af291b0 And it's worked fine for our use of it there. On Wed, Mar 13, 2019 at 1:11 AM Gerrit Pape wrote: > On Tue, Jan 08, 2019 at 08:19:30AM

Re: wrong exit code for sv status in lsb mode

2019-03-13 Thread Gerrit Pape
On Tue, Jan 08, 2019 at 08:19:30AM -0800, David Mountney via supervision wrote: > The error was introduced in commit 5fe1bc773c2d979093fe4b1f3ecbbed5e6acdaf0 > "sv.c: properly format status command's output on failure cases." > > Where the log status is being saved to the same variable as the

Re: wrong exit code for sv status in lsb mode

2019-01-08 Thread David Mountney via supervision
The error was introduced in commit 5fe1bc773c2d979093fe4b1f3ecbbed5e6acdaf0 "sv.c: properly format status command's output on failure cases." Where the log status is being saved to the same variable as the service status. The quick fix would be to not record the log status for now: $ git diff

Re: wrong exit code for sv status in lsb mode

2019-01-08 Thread Gerrit Pape
Hi, donations for my free software increased recently, not sure why, but thanks. runit upstream sources with history still are available through $ git clone http://smarden.org/git/runit.git Below is the diff for sv.c from 2.1.1 to 2.1.2. Possibly anyone can spot the error and create a patch

wrong exit code for sv status in lsb mode

2015-08-18 Thread Fabian Ruff
Hi, I just noticed that the exit code of sv status in lsb mode is not 3 in all cases when the service is down. The problem arises when a service defines a log handler. In that case the return code of svstatus_print for the log process overwrites the return code of svstatus_print of the actual