- Add support for "setvar", which allows setting of arbitrary wsconsctl(8)
variables. Per email on tech-userlevel from Julio Merino <jmmv@hispabsd.org>
make -V FILES
from being useful (and given that every other variable can be
extracted using make -V, the behaviour was unusually inconsistent
given that the original reason for clearing it doesn't seem to be
relevant anymore)
- use <bsd.prog.mk> instead of directly including <bsd.files.mk>
(and possibly <bsd.man.mk> or <bsd.own.mk>)
- remove obsolete NOPROG
+ it was not discussed first
+ it is not consistent with the rest of the rc.d system. everything else:
- has defaults & example configuration in /etc/defaults/rc.conf
- uses lower-case variable names, including ipmon itself
Similar functionality added by the change I'm backing out may be
reintroduced in the future once it's been changed to meet our de-facto
rc.d standards, as opposed to something that appears to have been
lifted from a non-NetBSD source (HP/UX ?) ...
This occurs before the first load_rc_config() so that it may be
overridden by the user, and appears in single quotes so the
variables don't get evaluated until the eval in run_rc_command().
Problem noted by Patrick Welche <prlw1@cam.ac.uk> in [bin/15912].
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!
NETWORKING, and SERVERS) by specifying that certain things should
come BEFORE a given barrier, rather than having the barrier REQUIRE
a service. This allows scripts to be removed without having to
edit the barrier dependencies.
As discussed on tech-userlevel, and approved by Luke.
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 to yes, block-type swap partitions will be deleted upon shutdown.
This can be useful if swapping onto a RAIDframe device, but may cause
unnecessary delays during shutdown for the general case, so it's
disabled by default.
Should resolve [bin/14433] and [kern/14769].
become ippp (ISDN ppp) and irip (ISDN raw IP). The character device now
are called: /dev/isdn (isdnd <-> kernel communication), /dev/isdnctl (dialing
and other control), /dev/isdntrc* (tracing), /dev/isdnbchan* (raw B channel
access, i.e. for user land PPP) and /dev/isdntel* (telephone devices, i.e.
for answering machines).
you'll see the following message:
# /etc/rc.d/ipfs stop
/etc/rc.d/ipfs: WARNING: $ipfs is not set properly.
This horrible change is needed because of the "shutdown" keyword.
keep state to be locked (modification prevented) and then saved to disk,
allowing for the system to experience a reboot, followed by the restoration
of that information, resulting in connections not being interrupted.
To activate this feature, set ipfs=YES in /etc/rc.conf
and links exist:
${ntpd_chrootdir}/dev/clockctl
/var/db/ntp.drift -> ${ntpd_chrootdir}/var/db/ntp.drift
and then start ntpd with the appropriate options to run chroot(2)ed
under $ntpd_chrootdir as user ntpd group ntpd.
to take advantage of this, set ntpd_chrootdir in /etc/rc.conf.
[this is based on similar work i did for rc.d/named]
always perform the disk check (unless /fastboot exists). Previously
this would only occur when booting directly to multi-user, so the
fsck wouldn't happen after a single user boot going into multi-user.
releases, but has been ignored since an am-utils update six months ago.
This fixes [misc/11971] submitted by Jun-ichiro itojun Hagino. (Note that
$amd_flags is still supported, contrary to what the PR says).
lukem