Without this change, pressing ^T could result in rc.d script putting
junk strings like:
Script <filename> running
in configuration files when redirecting standard output to these files.
MFC after: 2 weeks
1. Add new functionality to the force_depend method to incorporate the
tests for whether the service is enabled and/or already running.
2. Add a new option to bypass checking only that the service is enabled
at boot time, and always check if it is running.
3. Use this new functionality to greatly simplify the rc.d scripts that
use force_depend.
4. Add a force_depend for statd in lockd
5. Remove the check that either nfs_server or nfs_client is _enable'd
from statd and lockd. This was always overkill, and prevented using
the {one|force}start options, as well as stop'ing on the command line.
6. The yp* scripts had some of their arguments in various weird orders.
Bring them into line with the model.
7. If mountd fails to create /var/db/mountdtab, err out.
Ideas, suggestions, and/or review from delphij and jilles.
Pointy hats are completely my responsibility however.
The concept of set_rcvar() was nice in theory, but the forks
it creates are a drag on the startup process, which is especially
noticeable on slower systems, such as embedded ones.
Document the current semantics of the 'quiet' command prefix
in the rc.subr(8).
Fix dhclient rc.d script: it should not call err() for
non-DHCP-enabled interface when it is called from devd, because the
latter just blindly calls 'service dhclient quietstart' on each "link
up" event.
Since the 'quietstart' will silence the message "Cannot 'start' <foo>.
Set <foo>_enable to YES in /etc/rc.conf or use 'onestart' instead of
'start'." and running dhclient on the non-DHCP-enabled interface is
the same thing as running the service <foo> without <foo>_enable set,
such modification is in sync with the current semantics of the 'quiet'
prefix.
Approved by: glebius
Reviewed by: freebsd-rc list
MFC after: 2 weeks
With the current sh, placing eval in a command substitution always results
in a fork(), even if it is the only command and only executes a single
simple command. Therefore, avoid it where it can be avoided easily.
Side effect: values starting with a hyphen and all whitespace are preserved.
The values are defaults and names for rc.conf variables and messages to be
given about obsolete ones.
MFC after: 2 weeks
like, determines the path to a pid file as it is specified in a conf file.
Use the new feature for rc.d/named and rc.d/devd, the 2 services in the
base that list their pid files in their conf files.
Remove the now-obsolete named_pidfile, and warn users if they have it set.
that is running even though not _enable'd had an annoying side effect.
If the service was already started at boot time by another means when
the related script came around again in rcorder it would start again,
regardless of _enable, because there was a valid pid. [1]
So, split the test into 2 parts, one for (!rcvar && !stop), and one
for (stop && !valid_pid). This preserves the behavior from r206686
while preventing the undesired side effect.
PR: conf/156427 [1]
Submitted by: Eugene Grosbein <eugen@grosbein.pp.ru> [1]
to repeatedly read the conf files. Depending on what is enabled the
files are being read anywhere from 15, 30, or more times currently.
By loading the values in the environment this is reduced to 1, with
perhaps a couple more, again depending on what is enabled.
The speed-up for boot and shutdown is negligible when rc.conf is
on local disk, noticable when accessing files over NFS, and dramatic
when pulling rc.conf values from a database.
This change also includes a minor optimization to the conditional
for $_rc_conf_loaded.
still exists as a zombie. The 'kill -0' test in this function can
therefore return true even if the process isn't actually running.
This could lead to wait_for_pids() printing an endless string of the
pid number until the zombie finally exits.
Solve this problem by moving the sleep up to after the 'kill -0' test, but
only after we've run through the function once already. In the common case
(only one pid in the list) this will always do the right thing. On the rare
occasion that there is more than one pid in the list this will sleep 1
second per zombie process which will allow that process, and any other
in the list a chance to exit.
While I'm here, local'ize the variables that this function uses.
This waits for the requested process(es) to terminate, rather than polling
with an interval of 2 seconds.
If pwait is not available, the old method is used.
PR: conf/132766
Reviewed by: dougb
employ a more generic solution, and use it in the individual rc.d scripts
that also have an $rc_quiet test:
1. Add check_startmsgs() to rc.subr.
2. In the rc.d scripts that use rc_quiet (and rc.subr) substitute
variations of [ -z "$rc_quiet" ] with check_startmsgs
3. In savecore add a trailing '.' to the end of the message to make it
more consistent with other scripts.
4. In newsyslog remove a : before the terminal '.' since we do not expect
there to be anything printed out in between to make it more consistent.
5. In the following scripts change "quotes" to 'quotes' where no variables
exist in the message: savecore pf newsyslog
6. In the following scripts substitute if/then/fi for the simpler (and
more consistent) check_startmsgs &&: faith stf
7. In the following scripts separate the "Starting foo:" from the terminal
'.' to make them more consistent: moused hostname pf
8. In nfsclient move the message to its own line to avoid a style bug
9. In pf rc_quiet does not apply to the _stop method, so remove the
test there.
10. In motd add 'quotes' around the terminal '.' for consistency
and $desc.
The set_rcvar_obsolete() is for displaying an obsolete variable
and the new one. More specifically, a warning is displayed when
a variable is removed or changed in the source tree and the user
still defines the old one.
$router* and $ipv6_router* are replaced with $routed_* and
$route6d_* for consistency. The old variables still work but
can be removed in the future.
MFC after: 3 days
service behind $rc_quiet. Instead, output a warning if the pre-command
routine or the command itself failed. Arguably, it's more useful to know when
a command failed to start than it is to have an endless list of
"Starting ...." lines[1].
[1] - This change actually helped me to discover a bug in rc.d/{lockd,statd}
(fixed in r179941) that used to fail silently before.
out because the rc.conf(5) variable was not enabled. Display a
message that the command wasn't run and offer suggestions on
what the user can do.
Implement a quiet prefix, which will disable some diagnostics. The
fast prefix also implies quiet. During boot we use either fast or
quiet. For shutdown we already use 'faststop'. So, this informational
message should only appear during interactive use.
An additional benefit of having a quiet prefix is that we can start
putting some of our diagnostic messages behind this knob and start
"de-cluttering" the console during boot and shutdown.
during boot and shutdown. I think I'll hide it behind autoboot or
maybe take brooks@ suggestion and implement a different command
prefix for booting/shutdown purposes, but in any case it needs more
thought and attention.
Noticed by: ceri
Pointyhat to: mtm
