Convert these messages to warnings that are only displayed if
EINFO_VERBOSE is set to yes in the environment.
This is based on a suggestion from Patrick Lauer <patrick@gentoo.org>.
X-Gentoo-Bug: 487588
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=487588
There's no need to loop until flock was successfully as flock() would simply
block till a previous lock has been released.
There's more to do to fix it properly, see my comments in the patch.
Reported-by: James Le Cuirot <chewi@aura-online.co.uk>
X-Gentoo-Bug: 360013
X-Gentoo-Bug-URL: https://bugs.gentoo.org/360013
The old behaviour was to exit(EXIT_SUCCESS) in case the service has been stopped
already, even if further commands has been passed to the init script
(like zap, start).
So using for example /etc/init.d/foo stop zap start would abort immediately
after "stop" if the service has been stopped already. Though there may be cases
were we need it to proceed with the remaining commands, zap and start in this
case.
This patch fixes the behaviour to continue and proceed with the remaining
commands whenever necessary.
X-Gentoo-Bug: 371845
X-Gentoo-Bug-URL: https://bugs.gentoo.org/371845
symbolic links should not be followed in an attempt to work out the name
of the service we are running. Also, @sysconfdir@/conf.d should be tried
as a backup directory for configuration files.
I would like to thank Robin Johnson for his input on this change.
X-Gentoo-Bug: 350910
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=350910
runscript will try to get the dir and basename of a file/link in case it
contains at least one slash. This patch gives a temporary copy of the path to
the dirname() function since dirname() can modify its argument.
* status on a stopped service now has a return code of 3 (was 1)
* starting an already started service now has a return code of 0 (was 1)
* stopping an already stopped service now has a return code of 0 (was 1)
Under normal conditions, runscript creates one child and waits for its
termination, which is signaled by a pipe write from the SIGCHLD
sighandler.
When running killprocs however more than one SIGHCLD signal is generated, at
least on all of my amd64 boxes running on real hardware and in vmware.
When the first SIGCHLD occurs svc_exec leaves the loop and closes the pipe.
Subsequent SIGCHLDs during the close can lead to a race condition and create an
EBADF error in the pipe write (pipe is closed but the file handle is still !=
-1).
We avoid this by blocking SIGHCHLD during the pipe close.
OpenRC version is now stored as plaintext in /libexec/rc/version
Plugins (cursplash, splashutils) will have to be re-compiled to pickup
the new directories. State data needs to be moved from /lib/rc/init.d
to /libexec/rc/init.d as well.
