This change allows to specify a watchdog(9) timeout for a system
shutdown. The timeout is activated when the watchdogd daemon is
stopped. The idea is to a prevent any indefinite hang during late
stages of the shutdown. The feature is implemented in rc.d/watchdogd,
it builds upon watchdogd -x option.
Note that the shutdown timeout is not actiavted when the watchdogd
service is individually stopped by an operator. It is also not
activated for the 'shutdown' to the single-user mode. In those cases it
is assumed that the operator knows what they are doing and they have
means to recover the system should it hang.
Significant subchanges and implementation details:
- the argument to rc.shutdown, completely unused before, is assigned to
rc_shutdown variable that can be inspected by rc scripts
- init(8) passes "single" or "reboot" as the argument, this is not
changed
- the argument is not mandatory and if it is not set then rc_shutdown is
set to "unspecified"
- however, the default jail management scripts and jail configuration
examples have been updated to pass "jail" to rc.shutdown, just in case
- the new timeout can be set via watchdogd_shutdown_timeout rc option
- for consistency, the regular timeout can now be set via
watchdogd_timeout rc option
- watchdogd_shutdown_timeout and watchdogd_timeout override timeout
specifications in watchdogd_flags
- existing configurations, where the new rc options are not set, should
keep working as before
I am not particularly wed to any of the implementation specifics.
I am open to changing or removing any of them as long as the provided
functionality is the same (or very close) to the proposed one.
For example, I think it can be implemented without using watchdogd -x,
by means of watchdog(1) alone. In that case there would be a small
window between stopping watchdogd and running watchdog, but I think that
that is acceptable.
Reviewed by: bcr (man page changes)
MFC after: 5 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D21221
after opening the console, replacing init as PID 1.
From the user point of view, it makes it possible to run eg the
shell as PID 1, using 'set init_exec=/bin/sh' at the loader(8)
prompt.
Reviewed by: kib
MFC after: 2 weeks
Relnotes: yes
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D16625
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
If the environment doesn't offer a working /dev/console, the existing
version of init(8) will simply refuse running rc(8) scripts. This means
you'll only have a system running init(8) and nothing else.
Change the code to do the following:
- Open /dev/console like we used to do, but make it more robust to use
O_NONBLOCK to prevent blocking on a carrier.
- If this fails, use /dev/null as stdin and /var/log/init.log as stdout
and stderr.
- If even this fails, use /dev/null as stdin, stdout and stderr.
So why us this useful? Well, if you remove the `getpid() == 1' check in
main(), you can now use init(8) inside jails to properly execute rc(8).
It still requires some polishing, as existing tools assume init(8) has
PID 1.
Also it is now possible to use use init(8) on `headless' devices that
don't even have a serial boot console.
This has the following advantages:
- During boot, the BOOT_TIME record is now written right after the file
systems become writable, but before users are allowed to log in. This
means that they can't cause `hidden logins' by logging in right before
init(8) kicks in.
- The pututxline(3) function may potentially block on file locking,
though this is very rare to occur. By placing it in an rc script, the
user can still kill it with ^C if needed.
- Most importantly: jails don't use init(8). This means that a force
reboot of a system running jails will leave stale entries in the
accounting database of the jails individually.
shutdown procedures (which have a duration of more than 120 seconds).
We have two user-space affecting shutdown timeouts: a "soft" one in
/etc/rc.shutdown and a "hard" one in init(8). The first one can be
configured via /etc/rc.conf variable "rcshutdown_timeout" and defaults
to 30 seconds. The second one was originally (in 1998) intended to be
configured via sysctl(8) variable "kern.shutdown_timeout" and defaults
to 120 seconds.
Unfortunately, the "kern.shutdown_timeout" was declared "unused" in 1999
(as it obviously is actually not used within the kernel itself) and
hence was intentionally but misleadingly removed in revision 1.107 from
init_main.c. Kernel sysctl(8) variables are certainly a wrong way to
control user-space processes in general, but in this particular case the
sysctl(8) variable should have remained as it supports init(8), which
isn't passed command line flags (which in turn could have been set via
/etc/rc.conf), etc.
As there is already a similar "kern.init_path" sysctl(8) variable which
directly affects init(8), resurrect the init(8) shutdown timeout under
sysctl(8) variable "kern.init_shutdown_timeout". But this time document
it as being intentionally unused within the kernel and used by init(8).
Also document it in the manpages init(8) and rc.conf(5).
Reviewed by: phk
MFC after: 2 weeks
Files used both "securelevel" and either "secure level" or
"security level"; all are now "security level".
PR: docs/84266
Submitted by: garys
Approved by: keramida
MFC after: 3 days
Avoid using parenthesis enclosure macros (.Pq and .Po/.Pc) with plain text.
Not only this slows down the mdoc(7) processing significantly, but it also
has an undesired (in this case) effect of disabling hyphenation within the
entire enclosed block.
not -tag. Instead, put a period after the error messages to aide
those using dumb terminals not capable of properly displaying markup.
Requested by: ru
assumption that only getty processes can be managed. Describe the
SysV-like ability to keep arbitrary long-running processes alive
using a non-device first field in /etc/ttys.
PR: 12767
Submitted by: Peter Jeremy <peter.jeremy@alcatel.com.au>
init(8) cannot decrease securelevel. The manual page explains this
and single_user() doesn't try to downgrade kernel to insecure mode.
Reviewed by: bde (manual page)
