Device nodes are normally never device_t so this type does not
have many permissions. After the mknod, the device should have
its label corrected before any other operations (like chmod).
The clock_hctosys variable should be set to YES if you are not using NTP to
synchronize your system time; it doesn't have anything to do with the
kernel configuration.
According to the sysctl man page, the --system option causes sysctl to
process all system configuration files, which include the following:
/run/sysctl.d/*.conf
/etc/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf
X-Gentoo-Bug: 484796
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=484796
- Rename the static_dev switch in conf.d/devfs to skip_mount_dev since
this is a better description of what the switch does.
- Clarify the error messages in the devfs service script based on the
new name of the switch.
install is in /usr which causes problems if /usr is not mounted.
Instead, checkpath and "mkdir -p" can do everything required and are
both available before /usr is mounted.
Since checkpath also handles selinux labels correctly,
_restorecon after is not required.
X-Gentoo-Bug: 503408
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=503408
The stat structure was not being initialized correctly in do_check. This
was causing the owner adjustment to be skipped if the first path had the
correct owner.
Also, the "correcting owner" message should always be printed when the
owner is being changed.
X-Gentoo-Bug: 518042
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=518042
The hwclock service should set the time zone regardless of the setting
of the clock_hctosys variable. This needs to be done to prevent issues
when the system time is being synchronized using ntp.
X-Gentoo-Bug: 434410
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=434410
Remove the recursive call in print_stacked_services which was causing an
infinite loop when using stacked runlevels.
I would like to thank Doug Freed and Jason Zaman for assisting with
tracking this down.
X-Gentoo-Bug: 514972
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=514972
The -W option does not need an argument of its own; it can take the
first path after all other options are processed on the command line.
Also, move the processing for the -W option out of the switch so it will
be in the same loop as the other processing.
Before this commit, not specifying -d, -f, -p or -W in a checkpath
command meant the command exited successfully but actually did nothing.
This is an error condition, so report it as such.
Status call should not set limits as it requires root permissions,
also this is not safe, as current process may reach limitation.
Solution is to set limits and move process to service cgroup only
on start.
X-GENTOO-BUG: 500364
X-GENTOO-BUG-URL: https://bugs.gentoo.org/show_bug.cgi?id=500364
- remove the has_executables variable since it isn't used.
- Convert the conditional calls to ewend/vewend to a single call to veend.
- Always call eend after all scripts are executed passing the appropriate
error code.
Because of this change, you will see only an overall status when
starting or stopping local unless you are using verbose mode.
With this patch, the "local" service runscript will be verbose like the
"sysctl" service when 'rc_verbose="yes"' is set.
Example output successful start:
* Stopping local ...
* Executing "/etc/local.d/00will-stop.stop" ... [ ok ]
* Starting local ...
* Executing "/etc/local.d/00will-start.start" ... [ ok ]
* Executing "/etc/local.d/01 test.start" ... [ ok ]
Example output with failing executables:
* Stopping local ...
* Executing "/etc/local.d/00will-stop.stop" ... [ ok ]
* Executing "/etc/local.d/will-fail.stop" ...
mount: can't find foo in /etc/fstab
* Execution of "/etc/local.d/will-fail.stop" failed. [ !! ]
* Starting local ...
* Executing "/etc/local.d/00will-start.start" ... [ ok ]
* Executing "/etc/local.d/01 test.start" ... [ ok ]
* Executing "/etc/local.d/will-fail2.start" ...
mount: can't find bar in /etc/fstab
* Execution of "/etc/local.d/will-fail2.start" failed. [ !! ]
* Executing "/etc/local.d/will-fail.start" ...
mount: can't find foo in /etc/fstab
* Execution of "/etc/local.d/will-fail.start" failed. [ !! ]
X-Gentoo-Bug: 489274
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=489274
We were not checking to see if /sys/fs/cgroup/openrc was already mounted
before we mounted it. This fixes that issue.
Thanks to Robin Johnson <robbat2@gentoo.org> for pointing this out.
Move the additional history information from Daniel Robbins' wiki
page along with the history from README to a separate file,
README.history.
X-Gentoo-Bug: 513024
X-Gentoo-Bug-URL: https://bugs.gentoo.org/513024
The SELinux filesystem has been moved to /sys/fs/selinux for quite some
time. We kept supporting /selinux for backwards compatibility, but it's
time to move forward on this.
X-Gentoo-Bug: 511718
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=511718
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
As the author of our tmpfiles.sh script, I hereby license it under
2-clause BSD, like the rest of openrc.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Thanks to info and testing done by Daniel Robbins <drobbins@funtoo.org>,
there is now a fix for this. Below is his description of the steps
OpenRC needed to use.
1) See if /proc/<pid>/status exists
2) If it does, see if it has a "envID:" field
3) If it does, see if "envID:" is set to "0"
4) If so, then it's one of the host's processes and should be a
candidate for the list. Otherwise, it is one of the container's
processes and should be ignored.
This should fix the bug and allow start-stop-daemon to work properly on
OpenVZ hosts.
X-Gentoo-Bug: 376817
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=376817
