rkhunter thinks OpenRC is a rootkit because of the hidefirstrout
variable. This has been renamed to hideFirstroute in order to get past
rkhunter.
I realize this is not an openrc bug. In this case though I do not have a
problem renaming the variable.
Reported-by: ago@gentoo.org
X-Gentoo-Bug: 339714
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=339714
The /run directory is a mount point for a tmpfs and should not contain
any files or directories. This cleans out the /run/openrc
symlink and any other files which were incorrectly placed in /run.
Thanks to Ian Stakenvicius for pointing out this solution.
If an init script or service was upgraded while it was running and the
settings for the pid file, command and process name were changed, it
would not be possible to stop the old service.
Runscript now saves the values it used to start the service and re-uses
them to stop the service.
Reported-by: flameeyes@gentoo.org
X-Gentoo-Bug: 434032
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=434032
This directory will contain tools which are not necessary for OpenRC to
run, but which some users have found useful.
The first of these is deptree2dot, which converts /run/openrc/deptree to
a .dot file for use with graphviz. This can assist in finding circular
dependencies.
miimon & mode must be set before other parameters, and then not changed
again. Prior commit f671e0a28 per bug #421757 introduced a small logic
error. Fixed & refactored to prevent it happening as easily.
X-Gentoo-Bug: 447790
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=447790
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
In order to make migration from /lib*/rc/init.d to /run/openrc possible
without rebooting, the migration script creates a symlink from
/run/openrc to /lib*/rc/init.d. We were trying to remove it on the next
reboot, but this is not possible since / is ro when /run is mounted.
Reported-by: fturco@fastmail.fm
X-Gentoo-Bug: 447678
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=447678
For devices that are always connected (e.g. ethernet cards), the current
carrier always wastes time by sleeping for 1 second. This is because the
code sleeps first, then checks for carrier. Invert the order so that we
return quickly for devices already active. For devices which are not yet
up, there shouldn't be any real difference.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This doesn't affect us on gentoo, but on archlinux, which has done the
/usr merge, OpenRC was looking for /run under PREFIX. /run is always at
the root level, so it shouldn't have prefix appended to it.
Reported-by: udeved@openrc4arch.site40.net
Currently, we have the net virtual, so we should use it as the default
in this instance so that netmount comes up after it thinks the network
is up. However, this is technically eroneous, because there is no way to
know from the init system that we really have network connectivity.
Reported-by: cheepeero@gmx.net
X-Gentoo-Bug: 445116
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=445116
Add a test when localmount is started to determine if /usr is mounted
from inside an initramfs for Linux systems. If it is not, we can unmount it when
localmount stops.
On *bsd systems, we always unmount /usr if it is separate.
Reported-by: ryao@gentoo.org
This commit was modified by William Hubbs as follows:
- The paths in the cgroup fs were put into variables to ease
maintenance.
- Documentation was added to rc.conf.Linux.
- The services were added originally to openrc/svcname cgroups under the
controller cgroups, but this left an "openrc" cgroup which was unused.
Now they are added to individual cgroups with the name openrc_${RC_SVCNAME}.
In a pathname expansion, specifically single-character match, the pure
POSIX specification uses '!' as the Negation character where a regular
expression would normally be '^'.
Regular expression: "a[^a]a"
Pathname expansion pattern: "a[!a]a"
Reference:
IEEE Std 1003.1, 2004 Edition
2. Shell Command Language
2.13 Pattern Matching Notation
2.13.1 Patterns Matching a Single Character
> The description of basic regular expression bracket expressions in the
> Base Definitions volume of IEEE Std 1003.1-2001, Section 9.3.5, RE
> Bracket Expression shall also apply to the pattern bracket expression,
> except that the exclamation mark character ( '!' ) shall replace the
> circumflex character ( '^' ) in its role in a "non-matching list" in
> the regular expression notation. A bracket expression starting with an
> unquoted circumflex character produces unspecified results.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
I have learned that it is better to increment the version early. This
way keeps track of the version that is being worked on on the branch and
the tag marks when the release actually happens.
Initially, we were creating tmpfiles entries in the sysinit runlevel and
again in the boot runlevel. Systemd runs the --create and --remove
options in one service called systemd-tmpfiles-setup after the local
file systems are mounted. Now we have a service called tmpfiles.setup
which emulates this.
This also closes the bug mentioned below, since we were originally
writing to files that were on read-only file systems and that were not
available.
Reported-by: <devurandom@gmx.net>
X-Gentoo-Bug: 439012
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=439012
The original documentation for these variables did not give an example
of what to do if the service had a name that had illegal characters in
it, so this commit adds an example. There was no bug report; this was
suggested by Tobias Klausmann.
Checkpath was printing the path it was working with unless it was
correcting the owner. In this case, it was printing "checkpath", which
is not very useful.
Reported-by: <devurandom@gmx.net>
X-Gentoo-Bug: 439014
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=439014
Previously, we were setting the quiet flag before the command line was
parsed. Since the flag is only used once, we can just read the
environment variable which is set by the parsing process.
Reported-by: <devurandom@gmx.net>
X-Gentoo-Bug: 439010
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=439010