Summary:
The intention of the original author (I assume) was to add this logic
for testing. This removes the debug statement so it no longer shows up
in calls to `status`.
MFC after: 2 weeks
MFC with: 0661f9389
Reviewers: kevans
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D40055
If ${name}_cpuset is specified (and /usr is mounted), cpuset(1) will be
run to limit the service to the configured cpuset.
PR: 142434
Reviewed by: kevans
None of tools working with login classes change umask(1)
and we had no ways to specify non-default umask for a service
not touching its startup script. This change makes in possible.
Some file-sharing services that create new files may benefit from it.
Differential: https://reviews.freebsd.org/D36309
MFC-after: 3 days
Run a service-based setup script before running the start command.
Useful for automatic configuration file generation.
Reviewed by: https://reviews.freebsd.org/D36006
The rc(8) framework support protecting services from OOM killer.
The current implementation applies the protection after the service has
already started. This works fine if only the main process is to be
protected (*_oomprotect=yes). However, the current implementation fails
to protect existing children when children are also to be protected
(*_oomprotect=all). This patch fixes that.
Note: it is not easy to apply the protectoin earlier because we want to
support both the services which use the "command" variable and those
that use the "start_cmd" variable.
PR: 256148
Approved by: adrian, osogbo
Tested by: Jamie Landeg-Jones <jamie@catflap.org>
Fixes: 3bead71e95 - Add a global option where we can protect
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35747
startmsg is a new rc.subr(8) function function to be used instead of
echo(1) when for boot messages. It replaces the often forgotten
check_startmsgs && echo ...
with
startmsg ...
No functional change intended.
I adjusted the commit message and did some final clean-ups of the patch
before committing.
PR: 255207
Reported by: Jose Luis Duran <jlduran@gmail.com>
Reviewed by: imp, 0mp
Approved by: imp (src)
Differential Revision: https://reviews.freebsd.org/D34514
When enabled, have the framework use the boottrace(8) utility to execute
each rc script, generating trace entries for the entire suite of
scripts.
Reviewed by: 0mp (slightly earlier version)
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D31930
define procname or have a PID file. This might be useful for cases,
such as mounting local FS, when there is no running daemon
still some other persistent state in the system which status
can be checked.
It is still possible to have a status method before this by having
extra_commands="status", but it's not obvious and might give
an script writer some extra legwork to figure out how and why
the straight method is not working.
Reviewed by: cy
MFC after: 1 week
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D31614
This is a more reliable method that accounts for existing pidfiles,
procname and interpreter settings.
Current method of obtaining the pid for oomprotect="YES"|"ALL" processes
in certain cases fails to find a unique pid.
One such case are rc.d scripts defining command as:
command="daemon"
which results in all processes started via daemon being selected and
passed to protect(1) which fails and prints usage:
$ /etc/rc.d/exampled restart
Stopping exampled.
Starting exampled.
usage: protect [-i] command
protect [-cdi] -g pgrp | -p pid
Running the same with -x reveals what happens:
+ pid='3051 4268 4390 4421 4427 4470 4588 4733 4740 4870 4949 4954 4979
5835 5866 55487 55583 56525 57643 57789 57882 58072 58167 99419'
+ /usr/bin/protect -p 3051 4268 4390 4421 4427 4470 4588 4733 4740 4870
4949 4954 4979 5835 5866 55487 55583 56525 57643 57789 57882 58072 58167
99419
usage: protect [-i] command
protect [-cdi] -g pgrp | -p pid
We have a more reliable way of obtaining pid already defined in rc.subr
and available when protect(1) needs it. We can simply `eval $_pidcmd`
which also invokes `check_process` but properly accounts for existing
pidfile, procname and interpreter settings.
With the change the pidfile is properly obtained.
Submitted by: Adam Wolk <a.wolk at fudosecurity.com>
Sponsored by: Fudo Security
Differential Revision: https://reviews.freebsd.org/D30367
A user may set ${name}_env variable in rc.conf(5) in order to set additional
environment variables for a service command. Unfortunately, at the moment
this variable is only honored when the command is specified via the command
variable. Those additional environment variables coming from ${name}_env
are never set if the service is started via the ${rc_arg}_cmd variable (for
example start_cmd).
PR: 239692
Reviewed by: bcr, jilles
Approved by: src (jilles)
Differential Revision: https://reviews.freebsd.org/D21228
Since r233109, kldload has the -n option, which silently ignores options
that are already loaded.
https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
Note that this script no longer reports if the module is already loaded,
but it could be argued this wasn't particularly useful information.
PR: docs/234248
Reviewed by: bcr (docs), kib, rgrimes (visual)
Approved by: jilles
Differential Revision: https://reviews.freebsd.org/D18670
Originally intended as 'in case in needs to be re-invoked', but it was later
decided (by myself) that 're-invoke itself' makes it more clear that the
script is expected to use this in a way.
Reported by: Jose Luis Duran (jlduran @ github)
X-MFC-With: r342792
Some rc scripts in ports (e.g. uwsgi, apache, openvpn) allow for
'application profiles' that usually require the rc script to be invoked
again for each active profile. Because there's no consistent way to
determine the path because it differs between manual/service(8) invocations
and /etc/rc invocations, this leads to patterns like these:
- www/uwsgi hardcodes the script path
- security/openvpn guesses either $_file or $0 based on $0 = /etc/rc
Instead of forcing rc scripts to guess, provide an rc_service variable to
the scripts that gets set appropriately both for direct execution or when a
script is being executed via run_rc_script (e.g. /etc/rc).
This is our analog of an OpenRC variable with the same name, different case
(RC_SERVICE).
PR: 234614
Reported by: koobs
Reviewed by: dteske, jilles
MFC after: 3 days
'read' pessimistically read(2)s one byte at a time, which can be quite
silly for large environments in slow emulators.
In my boring user environment, truss shows that the number of read()
syscalls to source rc.subr and invoke list_vars is reduced by something like
3400 to 60. ministat(1) shows a significant time difference of about -71%
for my environment.
Suggested by: jilles
Discussed with: dteske, jhb, jilles
Differential Revision: https://reviews.freebsd.org/D18481
This adds new keywords to rc/service to enable/disable a service's
rc.conf(5) variable and "delete" to remove the variable.
When the "service_delete_empty" variable in rc.conf(5) is set to "YES"
(default is "NO") an rc.conf.d file (in /etc/ or /usr/local/etc) is
deleted if empty after modification using "service $foo delete".
Submitted by: lme (modified)
Reviewed by: 0mp (previous version), lme, bcr
Relnotes: yes
Sponsored by: Smule, Inc.
Differential Revision: https://reviews.freebsd.org/D17113
The reasons for this are forward looking to pkgbase:
* /sbin/init is a special binary; try not to replace it with
every package update because an rc script was touched.
(a follow-up commit will make init its own package)
* having rc in its own place will allow more easy replacement
of the rc framework with alternatives, such as openrc.
Discussed with: brd (during BSDCam), kmoore
Requested by: cem, bz
PR: 231522
Approved by: re (gjb)
