For executables which take a verb, we should list the verbs first, and
then options which modify those verbs second. The general layout of
the man page is from general description to specific details, usually
Overview, Commands, Options, Return Value, Examples, References.
The "include" files had type "book" for some raeason. I don't think this
is meaningful. Let's just use the same everywhere.
$ perl -i -0pe 's^..DOCTYPE (book|refentry) PUBLIC "-//OASIS//DTD DocBook XML V4.[25]//EN"\s+"http^<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"\n "http^gms' man/*.xml
No need to waste space, and uniformity is good.
$ perl -i -0pe 's|\n+<!--\s*SPDX-License-Identifier: LGPL-2.1..\s*-->|\n<!-- SPDX-License-Identifier: LGPL-2.1+ -->|gms' man/*.xml
(This also removes support for booting into the EFI firmware setup
without logind. That's because otherwise the non-EFI fallback logind
implements can't work.)
Fixes: #9896
Based on the journalctl documentation of this option added in 23ad99b519
(#10527), but with the first reference to “fields” replaced by “journal
messages”, since I think it’s less common to show other fields with
`systemctl status` (though it’s possible with the `-o` option).
Having systemctl disable/unmask remove all symlinks in /etc and /run is
unintuitive and breaks existing use cases.
systemctl should behave symmetrically.
A "systemctl --runtime unmask" should undo a "systemctl --runtime mask"
action.
Say you have a service, which was masked by the admin in /etc.
If you temporarily want to mask the execution of the service (say in a
script), you'd create a runtime mask via "systemctl --runtime mask".
It is is now no longer possible to undo this temporary mask without
nuking the admin changes, unless you start rm'ing files manually.
While it is useful to be able to remove all enablement/mask symlinks in
one go, this should be done via a separate command line switch, like
"systemctl --all unmask".
This reverts commit 4910b35078.
Fixes: #9393
The term “positive” is often read to exclude 0 (though “strictly
positive” is sometimes used to clarify this), so let’s explicitly state
that --lines=0 is legal and completely disables journal output.
Motivated by an answer on StackExchange [1].
[1]: https://unix.stackexchange.com/a/475068/44049
This makes it possible to wait until boot is finished without having to poll
for this command repeatedly, instead using the syntax:
$ systemctl is-system-running --wait
Waiting is implemented by waiting for the StartupFinished signal to be posted
on the bus.
Register the matcher before checking for the property to avoid race conditions.
Tested by artificially delaying startup with a oneshot service and calling this
command, checked that it emitted `running` and exited with a 0 return code as
soon as the delay service completed startup.
Also tested that booting to degraded state unblocks the command.
Inserted a delay between getting the property and waiting for the signal and
confirmed this seems to work free of race conditions.
Updated the --help text (under --wait) and the man page to document the new
feature.
Docbook styles required those to be present, even though the templates that we
use did not show those names anywhere. But something changed semi-recently (I
would suspect docbook templates, but there was only a minor version bump in
recent years, and the changelog does not suggest anything related), and builds
now work without those entries. Let's drop this dead weight.
Tested with F26-F29, debian unstable.
$ perl -i -0pe 's/\s*<authorgroup>.*<.authorgroup>//gms' man/*xml
These lines are generally out-of-date, incomplete and unnecessary. With
SPDX and git repository much more accurate and fine grained information
about licensing and authorship is available, hence let's drop the
per-file copyright notice. Of course, removing copyright lines of others
is problematic, hence this commit only removes my own lines and leaves
all others untouched. It might be nicer if sooner or later those could
go away too, making git the only and accurate source of authorship
information.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Since bb28e68477 parsing failures of
certain unit file settings will result in load failures of units. This
introduces a new load state "bad-setting" that is entered in precisely
this case.
With this addition error messages on bad settings should be a lot more
explicit, as we don't have to show some generic "errno" error in that
case, but can explicitly say that a bad setting is at fault.
Internally this unit load state is entered as soon as any configuration
loader call returns ENOEXEC. Hence: config parser calls should return
ENOEXEC now for such essential unit file settings. Turns out, they
generally already do.
Fixes: #9107
These states should never be visible to the outside, as they are used
only internally while loading unit. Hence let's drop them from the
documentation.
'systemctl disable --runtime' would disable a unit, but only if it was enabled
with '--runtime', and silently do nothing if the unit was enabled persistently.
And similarly 'systemctl disable' would do nothing if the unit was enabled in
/run. This just doesn't seem useful.
This pathch changes enable/disable and mask/unmask to be asymmetrical. enable
and mask create symlinks in /etc or /run, depending on whether --runtime was
specified. disable and unmask remove symlinks from both locations. --runtime
cannot be specified for the disable and unmask verbs.
The advantage is that 'disable' now means that the unit is disabled, period.
And similarly for 'unmask', all masks are removed.
Similarly for preset and preset-all, they now cannot be called with --runtime,
and are asymmetrical: when they enable a unit, symlinks are created in /etc.
When they disable a unit, all symlinks are nuked.
$ systemctl --root=/ enable bluetooth
Created symlink /etc/systemd/system/dbus-org.bluez.service → /usr/lib/systemd/system/bluetooth.service.
Created symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service → /usr/lib/systemd/system/bluetooth.service.
$ systemctl --root=/ --runtime enable bluetooth
Created symlink /run/systemd/system/dbus-org.bluez.service → /usr/lib/systemd/system/bluetooth.service.
Created symlink /run/systemd/system/bluetooth.target.wants/bluetooth.service → /usr/lib/systemd/system/bluetooth.service.
$ systemctl --root=/ disable bluetooth
Removed /run/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed /run/systemd/system/dbus-org.bluez.service.
Removed /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed /etc/systemd/system/dbus-org.bluez.service.
$ systemctl --root=/ disable --runtime bluetooth
--runtime cannot be used with disable
$ systemctl --root=/ mask --runtime bluetooth
Created symlink /run/systemd/system/bluetooth.service → /dev/null.
$ systemctl --root=/ mask bluetooth
Created symlink /etc/systemd/system/bluetooth.service → /dev/null.
$ systemctl --root=/ unmask bluetooth
Removed /run/systemd/system/bluetooth.service.
Removed /etc/systemd/system/bluetooth.service.
$ systemctl --root=/ unmask --runtime bluetooth
--runtime cannot be used with unmask
$ systemctl --root=/ --runtime enable bluetooth
Created symlink /run/systemd/system/dbus-org.bluez.service → /usr/lib/systemd/system/bluetooth.service.
Created symlink /run/systemd/system/bluetooth.target.wants/bluetooth.service → /usr/lib/systemd/system/bluetooth.service.
$ systemctl --root=/ enable bluetooth
Created symlink /etc/systemd/system/dbus-org.bluez.service → /usr/lib/systemd/system/bluetooth.service.
Created symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service → /usr/lib/systemd/system/bluetooth.service.
$ systemctl --root=/ preset bluetooth
Removed /run/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed /run/systemd/system/dbus-org.bluez.service.
Removed /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed /etc/systemd/system/dbus-org.bluez.service.
$ systemctl --root=/ preset --runtime bluetooth
--runtime cannot be used with preset
$ systemctl preset-all --runtime
--runtime cannot be used with preset-all
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
NAME is kind of meaningless, because everything has a name. "Unit"
makes it more obvious that a name of a unit is necessary. I was always
momentarily baffled by "set-property NAME ASSIGNMENT...", where there
are two objects (the unit and the property), and it's not clear which of
the two "NAME" is supposed to signify.
We already made a similar change when talking about the "restart"
command, let's also do this for "systemctl reload" and friends.
Follow-up for: 6539dd7c42
See: #7126
This documents the status quo, clarifying when we are synchronous and
when asynchronous by default and when --no-block is support to force
asynchronous operation.
See: #6479
I think this matches the spirit of "indirect" well: the unit
*might* be active, even though it is not "installed" in the
sense of symlinks created based on the [Install] section.
The changes to test-install-root touch the same lines as in the previous
commit; the change in each case is from
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_ENABLED)
to
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_DISABLED)
to
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_INDIRECT)
in the last two commits.
When a unit has a symlink that makes an alias in the filesystem,
but that name is not specified in [Install], it is confusing
is the unit is shown as "enabled". Look only for names specified
in Alias=.
Fixes#6338.
v2:
- Fix indentation.
- Fix checking for normal enablement, when the symlink name is the same as the
unit name. This case wasn't handled properly in v1.
v3:
- Rework the patch to also handle templates properly:
A template templ@.service with DefaultInstance=foo will be considered
enabled only when templ@foo.service symlink is found. Symlinks with
other instance names do not count, which matches the logic for aliases
to normal units. Tests are updated.
The irreversible job mode is required to ensure that shutdown is not
interrupted by the activation of a unit with a conflict.
We already used the correct job mode for `ctrl-alt-del.target`. But not
for `exit.target` (SIGINT of user manager). The SIGRT shutdown signals
also needed fixing.
Also change SIGRTMIN+0 to isolate default.target, instead of starting
it. The previous behaviour was documented. However there was no reason
given for it, nor can we provide one. The problem that isolate is too
aggressive anywhere outside of emergency.target (#2607) is orthogonal.
This feature is "accessible by different means and only really a safety
net"; it is confusing for it to differ from `systemctl default` without
explanation.
`AllowIsolate=yes` is retained on poweroff.target etc. for backwards
compatibility.
`sigpwr.target` is also an obvious candidate for linking to a shutdown
target. Unforunately it is also a possible hook for implementing some
logic like system V init did, reading `/etc/powerstatus`. If we switched
to starting `sigpwr.target` with REPLACE_IRREVERSIBLY, attempts to run
`systemctl shutdown` from it would fail, if they had not thought to set
`DefaultDependencies=no`. We had provided no examples for `sigpwr`, and
the whole idea is cruft to keep legacy people happy. For the moment, I
leave `sigpwr` alone, with no risk of disrupting anyone's
previously-working, half-working, or untested setup.
Fixes#6484. See also #6471
