Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 241884 - sys-apps/openrc: gets restart() wrong and does not run a custom restart() block
Summary: sys-apps/openrc: gets restart() wrong and does not run a custom restart() block
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 241152 295613
  Show dependency tree
 
Reported: 2008-10-14 07:48 UTC by Robin Johnson
Modified: 2009-12-19 23:11 UTC (History)
3 users (show)

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


Attachments
testcase for problem (testcase,536 bytes, text/plain)
2008-10-14 07:50 UTC, Robin Johnson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-10-14 07:48:49 UTC
baselayout/openrc is screwing up restart, not running the real restart() block, but instead deciding to run stop/start on it's own. This is specifically a problem when start()/stop()/restart() are part of a more complex init where another function does the actual stop/start.

Will attach testcase next.

Actual results:
# /etc/init.d/testcase start
: Begin start
: SPECIAL start
: start_testcase
: End start
# /etc/init.d/testcase restart
: Begin stop
: SPECIAL stop
: stop_testcase
: End stop
: Begin start
: SPECIAL start
: start_testcase
: End start
# /etc/init.d/testcase stop
: Begin stop
: SPECIAL stop
: stop_testcase
: End stop


Expected results:
# /etc/init.d/testcase start
: Begin start
: SPECIAL start
: start_testcase
: End start
# /etc/init.d/testcase restart
: Begin restart
: SPECIAL restart
: stop_testcase
: start_testcase
: End restart
# /etc/init.d/testcase stop
: Begin stop
: SPECIAL stop
: stop_testcase
: End stop
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-10-14 07:50:48 UTC
Created attachment 168364 [details]
testcase for problem
Comment 2 Roy Marples 2008-10-23 16:25:50 UTC
This is non trivial to "fix".
OpenRC (and baselayout-2 before OpenRC) has never run the restart function because of this.

Nearly every init script "restart" is really a "reload" - ie, reload the configuration file without stopping and starting the daemon.
The easiest solution, by a very long margin, is to rename the init script functions accordingly and document it. This approach works fine with baselayout-1
Comment 3 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-10-23 18:57:39 UTC
auditd in this case isn't a reload in the sense of reload config.
reload is actually the one thing that it isn't in fact.

start is:
1. start daemon
2. load active ruleset for running if successful.
stop is:
1. load pre-stop ruleset
2. stop daemon
3. load post-stop ruleset
restart is:
1. stop daemon
2. start daemon
(audit logging continues in the kernel buffers during this time)
Comment 4 Roy Marples 2008-10-26 19:37:22 UTC
In the stop function you could avoid running the pre/post rules by testing RC_CMD=restart or RC_CMD=stop.
Comment 5 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-12-19 16:26:11 UTC
This bug has been idle for over a year... What is the consensus, Robin? Add the workaround for auditd as outlined in Comment #4? Is that route is taken, then this bug shouldn't block the openrc stable tracker
Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-12-19 22:09:05 UTC
work-around used for now.

Maybe we should have something to QA for init.d scripts containing a restart block that isn't being called?
Comment 7 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-12-19 23:11:54 UTC
Some init scripts' QA wouldn't be bad, given it would also have to look for stuff like, say, init scripts that run complex scripts during dependencies regeneration (the tinderbox gets quite a bit of load when it has to regenerate the rc dependency cache :().