When rc scripts are started from interactive shell, be nice and when user
tries to start an unconfigured service, point him to rc.conf(5) and tell
him about the one* keyword. Also be more user friendly when an unknown
argument is entered.
Example:
# /etc/rc.d/cron start
$cron is not enabled - see rc.conf(5).
Use the following if you wish to perform the operation:
/etc/rc.d/cron onestart
# /etc/rc.d/cron nonsense
/etc/rc.d/cron: unknown directive 'nonsense'.
Usage: /etc/rc.d/cron [fast|force|one](start stop restart rcvar status poll)
Inspired by discussion on tech-userlevel:
http://mail-index.netbsd.org/tech-userlevel/2007/02/13/0010.htmlhttp://mail-index.netbsd.org/tech-userlevel/2007/02/13/0011.htmlhttp://mail-index.netbsd.org/tech-userlevel/2007/02/13/0012.html
Reminded about it and reviewed by <lukem>
by killing the parent process. The parent's PID is saved in $RC_PID.
* In all rc.d/* scripts that previously tried to stop the boot,
replace in-line code with "stop_boot".
* Document this.
This should fix PR 29822.
also recognize "interpreter: daemon" in ps(1) output.
That case statement should be rewritten with expr(1) if more flexibility is
needed.
Fixes PR 35366 by Dominik Joe Pantucek, debugged with much assistance
by him on IRC.
load_rc_config_var cmd var
to load the rc.conf(5) configuration for cmd and set var in the
current shell, using 'load_rc_config var' in a sub-shell to avoid
unwanted side-effects.
* Improve required_vars warning message.
name where the user should look at for documentation about rcvar. It defaults
to 'rc.subr(5)', as rc.subr is mainly used by rc.d scripts.
This variable is useful to let the daily, weekly, monthly and security scripts
tune the warning message shown when any of the variables they handle is not
properly set.
Closes PR misc/23908.
${rcvar}=yes yet all the other prerequisite tests are still performed.
The existing ``force'' prefix is a sledgehammer that ignores all the
prerequisite checks and always returns a zero exit status; this is a
more gentle approach to the problem of "manipulate this disabled
service without editing rc.conf(5)".
in some circumstances where run_rc_script()'s sourcing of an rc.d file
which then sourced rc.subr, the `optimisation' in rc.subr to "return as
we're already loaded" would finish more than just the inner-most sourcing.
I haven't tracked down the exact issue, but removing the `optimisation'
fixes the problem I noticed in starting up certain rc.d scripts, and
may fix [bin/22053] as well.
inetd) started from rc can now be run under systrace by setting
${name}_systrace to a set of flags to be passed to systrace. Note
that policies need to generated before you do this.
in and setting -kb, check it out again, since the initial check in
trashes any RCSIDs (because -kb wasn't set at that time).
This stops the annoying situation where you add a new file (e.g, "foo")
which contains an RCSID and you get *two* notifications of differences
in two successives runs of /etc/security; the first when the file is
initially checked in and a second when diff finds the RCSID is different
(contains "foo.conf,v 1.1" instead of "foo,v 1.66").
Replace $critical_filesystems with $critical_filesystems_remote .
The new names are now consistent with the type argument that
mount_critical_filesystems() is called with, and allows for other types to
be easily supported by that function.
For backwards compatibility purposes, if the now obsolete variable is defined
(even empty), it takes precedence over the new form, and you will be warned.
If you want to stop the warnings, update your rc.conf(5) settings!
make them "externally" available:
Previous Current Purpose
-------- ------- -------
_arg rc_arg Argument to command, after fast/force
processing performed (and prefix
removed)
_flags rc_flags Flags to start the default command
with. Defaults to ${name}_flags,
unless overridden by $flags from the
environment. This variable may be
changed by the precmd method.
_pid rc_pid PID of command (if appropriate).
_rc_run_fast rc_fast Not empty is "fast" was provided.
_rc_run_force rc_force Not empty is "force" was provided.
- Use rc_flags instead of _flags or ${name}_flags in various rc.d scripts,
so that $flags from the environment overrides ${name}_flags from rc.conf(5).
Fixes [bin/15800].
If set, the first line of $command is read, the leading #! is
removed, whitespace is normalised, the first word is checked
against $command_interpreter, and the result is used as the
string to match in the ps(1) output.
This code isn't infallable, but works for common cases such as
#!/bin/sh
#! /usr/pkg/bin/perl -w
This helps solve the problem described in [bin/15563], and by
Ed Ravin on tech-userlevel.
- Move the common elements of check_process() and check_pidfile() into
_find_processes(), and call appropriately.
- Don't su(1) to ${name}_user if running as that user.
- Support $procname as the name of the process to search for.
Defaults to the value of $command.
I can't remember the rationale for why I made that change in the first place,
and there's been some good arguments presented to me as to why the rcvar
should be checked before status is run.
- always unset the variables used by run_rc_command() before sourcing an
rc.d script, rather than just when rc_fast_and_loose is in effect.
this allows run_rc_command() to be used in .sh scripts (with care).
- remove comment describing now-former limitation of .sh scripts.
- make the rc_fast_and_loose check only after the `` not *.sh / not scratch
/ script-is-executable '' checks. rc_fast_and_loose now behaves a lot more
like the normal operation, in that it skips scratch files and
non-executable files
- Skip files that end with `~', `#', `.OLD' or `.orig', as these are usually
scratch or backup files created by programs, and we don't want to start them.
- Only try and run non `.sh' files if they're executable.
Per discussions with Andrew Brown, and closing his PR [bin/9981].
* change the default `stop' case to wait_for_pids after kill $sig_stop.
this means that "/etc/rc.d/foo stop" won't return until the service
has shut down. third party scripts that implement their own stop mechanism
should offer this functionality as well.
* in the default restart case, don't bother doing `$0 poll' in between
stop & start, because of the change above. (XXX: deprecate poll ?)
because /bin/sh needs a different syntax than ksh (and bash, etc).
Use a more obvious and less error prone method. (This complicated
use of ${:+} was only used to build the su command when running as
a separate user, but could always cause problems.)
Problem noted by Hubert Feyrer in conjunction with /etc/rc.d/sshd.
* run_rc_command():
- add support for "poll", which by default, uses wait_for_pids() on
the list of matching processes
- in the "restart" case, call "poll" between "stop" and "start"
this fixes the situation where certain services (e.g, amd, squid) would
take a bit longer to shutdown after receiving the kill signal to shutdown,
and "/etc/rc.d/foo restart" would fail in the `start' phase.
- only load rc.conf if $_rc_conf_loaded is not set
- use case instead of if for various string comparisons
- print the date at the start of the boot as well as at the end
- if $rc_fast_and_loose is set, always run the rc.d scripts in the
current shell rather than in a subshell. this is not on by default
because it's potentially dangerous (a rogue command could terminate
the boot), but it is provided as an optional speedup for people
with slow machines that have an expensive fork
* don't barf if `force' is used and $rcvar isn't set by the script
* only do the guts of `restart' once, by setting _rc_restart_done after the
first run through. this stops scripts which call run_rc_command more than
once (such as nfslocking) from doing the ``stop everything/start everything''
sequence n times.
