Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 176452 - sys-apps/baselayout-2.0.0_alpha{1,6}'s stopping of a service returns an error code of 1 if the service is already stopped
Summary: sys-apps/baselayout-2.0.0_alpha{1,6}'s stopping of a service returns an error...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 199807 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-29 11:28 UTC by Mike Auty (RETIRED)
Modified: 2008-03-31 16:39 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Baselayout-2.0.0_rc6 start/stop return code patch (baselayout-2.0.0_rc6-start-stop.patch,924 bytes, patch)
2007-11-18 15:05 UTC, Mike Auty (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Auty (RETIRED) gentoo-dev 2007-04-29 11:28:21 UTC
Hiya, so I just noticed a minor change in semantics between previous baselayouts and baselayout-2.  Previously when using /etc/init.d/blah stop, if the service was already stopped, a yellow warning was printed but the program gave a return code of 0.  On baselayout-2 there's still the yellow warning, but there's now a return code of 1.

This breaks the vmware-config.pl script which tries to shut down the vmware services before configuration and fails if it receives an error code.  Unfortunately the service can't be successfully started until the configuration has completed, so the user's left in a bit of spot.

Whilst we could patch the vmware-config script, it does feel as though a success code should be returned since we're interested in whether the service has been stopped, and sure enough it has.

Looking in the code, it appears that ewarnx always returns ERROR_FAILURE, which may not always be appropriate.  I'm not sure how to go about fixing it other than perhaps making failures *failures* and warnings a success but with a user notification?  Perhaps modelling it on the previous baselayout's behaviour would be best?

As ever, I'm happy to test out any patches or dodgy hacks to help find a solution...  5:)
Comment 1 Roy Marples (RETIRED) gentoo-dev 2007-04-30 09:06:41 UTC
OK, I've fixed this in our svn repo.
Comment 2 Roy Marples (RETIRED) gentoo-dev 2007-05-04 15:36:45 UTC
Fixed in baselayout-2.0.0_alpha2
Comment 3 Roy Marples (RETIRED) gentoo-dev 2007-05-04 15:36:55 UTC
Fixed in baselayout-2.0.0_alpha2
Comment 4 Mike Auty (RETIRED) gentoo-dev 2007-11-16 09:37:50 UTC
Sadly, this appears to have regressed in the baselayout-2.0.0_alpha6 (possibly earlier) and it's now causing issues with vmware again.

Is there any way of bringing forward the regression fix again please?  A single change like this can make packages such as vmware, which uses "/etc/init.d/blah stop" rather than checking the status first, unusable without more extensive patching.  Since this is a behaviour change, it'd be great if this could be reverted, to give the defacto standard results of success unless there was a real problem getting the service into a stopped state...

Thanks  5:)
Comment 5 Mike Auty (RETIRED) gentoo-dev 2007-11-18 14:34:09 UTC
It appears this was re-introduced during a code shuffle in checkin 3021.

http://sources.gentoo.org/viewcvs.py/baselayout/trunk/src/runscript.c?r1=3018&r2=3021
Comment 6 Mike Auty (RETIRED) gentoo-dev 2007-11-18 15:05:13 UTC
Created attachment 136295 [details, diff]
Baselayout-2.0.0_rc6 start/stop return code patch

It turns out the patch is very, very similar to the originally checked in patch.

http://sources.gentoo.org/viewcvs.py/baselayout/trunk/src/runscript.c?r1=2659&r2=2666

Hopefully this can be fixed in time for baselayout-2.0.0_rc7 or the first release of openrc?
Comment 7 Roy Marples (RETIRED) gentoo-dev 2007-11-18 21:17:32 UTC
I already have this fixed locally.
Comment 8 Mike Auty (RETIRED) gentoo-dev 2007-11-25 13:45:57 UTC
*** Bug 199807 has been marked as a duplicate of this bug. ***
Comment 9 Doug Goldstein (RETIRED) gentoo-dev 2008-03-31 16:39:34 UTC
Fixed in OpenRC.