supervise-daemon was apparently overlooked when support for the
SSD_IONICELEVEL environment variable was added. This commit brings
supervise-daemon up to parity with start-stop-daemon with respect to
this environment variable.
Newer devices have multiple power_supply devices in sysfs:
$ grep ^ /sys/class/power_supply/*/type
/sys/class/power_supply/AC/type:Mains
/sys/class/power_supply/BAT0/type:Battery
/sys/class/power_supply/ucsi-source-psy-USBC000:001/type:USB
/sys/class/power_supply/ucsi-source-psy-USBC000:002/type:USB
There are two "USB" Type-C ports than can supply power and both are
aggregated into the "Mains" power supply by the firmware. The "Battery"
also counts as a power supply, but is missing the online attribute.
The -f check with a wildcard pattern results in an error, when multiple
devices are present:
/lib/rc/bin/on_ac_power: line 21: [: too many arguments
When the power_supply class is registered, check for a "Mains" device.
Fixes#427.
Since commit 6b475ab269, openrc tries to load
modules twice which have been defined in /etc/conf.d/modules via modules=
variable when /bin/sh points to dash shell.
The reason is that when the "modules-load" service was merged into "modules"
service, the "modules" variable name got used in both, load_modules()
function and in Linux_modules() function which both get called when modules
service is started. Although "modules" variable is marked as local in
load_modules(), dash simply ignores this.
Avoid the issue by renaming "modules" variable to "_modules" in
load_modules() function.
This fixes#419.
In legacy cgroups mode, we were running `mountinfo -q ""` which was
generating an error message. If we return immediately when
cgroup2_find_path returns an empty value, we avoid this message.
The previous fix excludes PIDs of processes running in a different namespace
regardless of whether the PID has been explicitly stored in a PID file mentioned
in the --pidfile parameter. The correct behavior is to only exclude the pid if
it is not stored in a pidfile.
X-Gentoo-Bug: 776010
X-Gentoo-Bug-URL: https://bugs.gentoo.org/776010
The cgroups v2 setup required the rc_cgroups_controllers variable
to be set to the list of controllers to enable regardless of whether the
mode was hybrid or unified.
This makes sense for hybrid mode since the controllers can't be in both
the cgroups v1 and v2 hierarchies, but for unified mode we should enable
all controllers that are configured in the kernel.
The test `[ -h "${ifname}" ] && continue` skips the symlinks while it is
the opposite that is the expected: ignoring files that are not symlinks.
Fixes commit f42ec82f21.
This fixes#391.
Otherwise this would create the following output:
rc-status -f ini
* Caching service dependencies ... [ ok ]
[default]
dbus = started
NetworkManager = started
syslog-ng = started
...
This fixes#364.
I found the original note a little confusing, since using rc-update will
add it to a runlevel so it *is* auto-started when the system reaches
that runlevel again, but I don't think that was the intended meaning of
'auto-start', so hopefully this makes it a little more clear.
Currently when osclock is enabled as a init.d service the following
messages appear during boot when osclock starts:
* The command variable is undefined.
* There is nothing for osclock to start.
* If this is what you intend, please write a start function.
* This will become a failure in a future release.
osclock is activated whenever a machine's system clock is automatically
configured from a RTC by the kernel and the osclock's only purpose is to
satisfy the "clock" dependency defined by other init.d services.
Adding a stub start() function prevents OpenRC from showing warnings but
continues to ensure that the osclock service still does not actually do
anything.
This fixes#377.
