execute: minor ExecOutput handling beautification (#6711)
Let's clean up the checking for the various ExecOutput values a bit,
let's use IN_SET everywhere, and the same concepts for all three bools
we pass to dprintf().
Alan Jenkins [Fri, 1 Sep 2017 00:02:32 +0000 (01:02 +0100)]
systemctl: remove compiler warning (#6717)
913c1916 changed _ACTION_INVALID to negative, changing the enum to a
signed type. Take care to avoid comparing it with an unsigned type.
../src/systemctl/systemctl.c: In function ‘start_unit’:
../src/systemctl/systemctl.c:3107:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
assert(arg_action < ELEMENTSOF(action_table));
Alan Jenkins [Mon, 31 Jul 2017 16:36:58 +0000 (17:36 +0100)]
manager: fix job mode when signalled to shutdown etc
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.
Alan Jenkins [Wed, 2 Aug 2017 15:19:22 +0000 (16:19 +0100)]
manager: remove fallback for user/exit.target
The comment here was misleading: the job can fail to enqueue for reasons
other than the target not existing.
The fallback caused an error to be logged, and dates back to when the
"user" directory was named "session". units/session/exit.target was added
later the same year.
This is consistent with the documentation (man systemd), and the handling
of similar signals. It's also consistent with `systemctl exit`, which is
what most people would expect.
Alan Jenkins [Mon, 31 Jul 2017 16:50:38 +0000 (17:50 +0100)]
man: dbus method Manager.Exit() does not start exit.target
It's like Manager.PowerOff(), which does not start poweroff.target.
Instead, the dbus methods are used for `systemctl --force exit`
or `systemctl --force poweroff`. They shut down the system without
processing individual unit's ExecStop or TimeoutStopSec.
Harald Hoyer [Thu, 31 Aug 2017 13:33:33 +0000 (15:33 +0200)]
Load virtio_rng early in the game (#6710)
If true randomness is needed before udev is triggered, which would load
virtio_rng, reading /dev/random takes forever and the boot stalls for a
long time.
Alan Jenkins [Fri, 18 Aug 2017 12:18:09 +0000 (13:18 +0100)]
systemctl: improve readability of start_unit()
start_unit() is a little tangled. There's an easy part we can untangle,
then readers can concentrate on the more necessary complexity.
* Derive (method, action, mode) more clearly, as disjoint cases based on
the command. Don't rely on action_table[_ACTION_INVALID].target being
implicitly initialized to NULL.
verb_to_method() is now only used on one case, but not because I strongly
object to the implicit "StartUnit" cases. It's more a syntax problem.
I think the old code takes me longer to understand, because the call
comes just above a similar-looking call to verb_to_action(), but the
results of the two functions are used in different ways. It also helps
that the new code ends up having a more regular form, for the 4 different
cases.
These changes cost 6 extra lines.
* Add an assertion to confirm that we do not pass mode=NULL.
Michal Sekletar [Thu, 31 Aug 2017 10:45:25 +0000 (12:45 +0200)]
tmpfiles: with "e" don't attempt to set permissions when file doesn't exist (#6682)
tmpfiles.d option "e" when run through systemd-tmpfiles --create should
apply configured permissions (uid,gid) only to already existing
files. When file doesn't exist we bail out with error. Instead we should
silently ignore non-existing files.
$ useradd test
$ cat /etc/tmpfiles.d/foobar.conf
e /tmp/test - test test 1d
$ ls -l /tmp/test
ls: cannot access '/tmp/test': No such file or directory
Before:
$ systemd-tmpfiles --create /etc/tmpfiles.d/foobar.conf
Adjusting owner and mode for /tmp/test failed: No such file or directory
$ echo $?
1
Michal Sekletar [Thu, 31 Aug 2017 09:20:14 +0000 (11:20 +0200)]
units: introduce getty-pre.target (#6667)
This new target is a passive unit, hence it is supposed to be pulled in
to the transaction by the service that wants to block login on the
console (e.g. text version of initial-setup). Now both getty and
serial-getty are ordered after this target.
Andrew Jeddeloh [Thu, 31 Aug 2017 08:58:39 +0000 (01:58 -0700)]
networkd: dont crash when mtu changes (#6594)
Prevent networkd from crashing when UseMTU is used. Many drivers will
bring the link down and then back up to configure a new MTU. Networkd
will also asynchonously send rtnl messages to configure the link and may
receive responses after the link has gone down and come back up (which
networkd will handle and set the lease and network to NULL.
This changes the behavior to instead return if this is the case instead
of crashing via assert.
Alan Jenkins [Thu, 31 Aug 2017 08:54:12 +0000 (09:54 +0100)]
systemctl: clarify code - some actions never appear in arg_action (#6638)
ACTION_EMERGENCY and ACTION_DEFAULT would be handled correctly by
start_with_fallback(). However there is no fallback available for
them, and they would never be set in `arg_action` in the first
place. Remove the unused cases from the switch statement.
@poettering suggested this makes a good place to clarify the point,
explicitly listing all the `arg_action` values which would never be
set.
sd-bus: use -- when passing arguments to ssh (#6706)
This prevents `systemctl` from runnning /bin/touch when the following
command is used:
```
systemctl -H '-oProxyCommand=/bin/touch i-shouldnt-be-here' show-environment
```
Andreas Rammhold [Wed, 30 Aug 2017 23:14:05 +0000 (01:14 +0200)]
networkd: Renamed `table_id` field to `table`
Other parts of the code do just use `table` as identifier for the actual
routing table id. This change should make it easier to read through the
code since the meaning or rather the name stays the same.
Andreas Rammhold [Wed, 30 Aug 2017 23:11:16 +0000 (01:11 +0200)]
networkd: Add `VRF.Table` to support parsing of table names
Previously there was only `VRF.TableId` which only supported numeric
identifiers for routing table. With the additiona of
`config_parse_route_table` also names can be used as identifiers.
Ivan Shapovalov [Wed, 30 Aug 2017 16:49:07 +0000 (19:49 +0300)]
cryptsetup-generator: do not bind to the decrypted device unit (#6538)
This breaks things when the decrypted device is not immediately
`SYSTEMD_READY=1` (e. g. when a multi-device btrfs system is placed on
multiple cryptsetup devices).
systemd-shutdown is run after the network is stopped,
so remounting a network filesystem read-only can hang.
A simple umount is the most useful thing that can
be done for a network filesystem once the network is down.
Alan Jenkins [Wed, 30 Aug 2017 16:47:40 +0000 (17:47 +0100)]
man: fix note for `systemctl enable --global` (#6592)
The last sentence in the paragraph described the behaviour of `--global`. But "the last case" we listed was "only this boot", which does not match... This was the fifth case described, but there are only _four_ different option names. Fix it.
Alan Jenkins [Wed, 30 Aug 2017 16:20:23 +0000 (17:20 +0100)]
units: starting suspend.target should not fail when suspend is successful (#6678)
and the same for hibernate.target and hybrid-sleep.target.
Tested with both sucessful and unsuccessful suspends. The result of the
start job was correct in both cases. Closes #6419 (a regression in v233
and v234).
> suspend is unsual for a target, because it has to stop itself once it's
> started. Otherwise you couldn't start it again, so you could only suspend
> once! Currently that's implemented using BindsTo=systemd-sleep.service.
> Meaning it pulls in systemd-sleep.service to do the actual suspend, and
> then de-activates afterwards. But the behaviour of BindsTo was changed
> recently (not without some issues during development) - maybe this bug
> is caused by poettering/systemd@631b676 which I think was added in
> release v233.
>
> sleep.target (see man systemd.special) has the same need, but it
> implements it differently. It simply has StopWhenUnneeded=yes.
This commit switches suspend.target etc. to the approach used by
sleep.target.
Alan Jenkins [Wed, 30 Aug 2017 16:11:31 +0000 (17:11 +0100)]
sulogin-shell: remove ineffective job mode option from `systemctl isolate` (#6627)
`systemctl default` uses job mode `isolate` (see `action_table`).
The job mode option is ignored.
Note that exiting the emergency shell service by using e.g.
`systemctl isolate multi-user` or `systemctl start multi-user.target`
already kills `emergency.service`. There's only a potential conflict
between your command and the command in systemd-sulogin-shell if you run
something like `systemctl start --no-block multi-user.target; exit`.
Which is nothing like what we told them to do :).
Franck Bui [Wed, 30 Aug 2017 15:16:16 +0000 (17:16 +0200)]
device: make sure to remove all device units sharing the same sysfs path (#6679)
When a device is unplugged all device units sharing the same sysfs path
pointing to that device are supposed to be removed.
However it didn't work since while iterating the device unit list containing
all the relevant units, each unit was removed during each iteration of
LIST_FOREACH. However LIST_FOREACH doesn't support this use case and
LIST_FOREACH_SAFE must be use instead.
Tom Gundersen [Wed, 30 Aug 2017 11:09:03 +0000 (13:09 +0200)]
sd-bus: socket - only transmit auxillary FDs once (#6603)
If a message is too large to fit into the output buffer, it will be
transmitted to the kernel in several chunks. However, the FDs must
only ever be transmitted once or they will bereceived by the remote
end repeatedly.
The D-Bus specification disallows several sets of FDs attached to
one message, however, the reference implementation of D-Bus will
not reject such a message, rather it will reassign the duplicate
FDs to subsequent FD-carrying messages.
This attaches the FD array only to the first byte of the message.
Michal Sekletar [Wed, 30 Aug 2017 11:07:43 +0000 (13:07 +0200)]
README: note that installing valgrind-devel maybe useful to developers (#6502)
Commit also mentions that when running under valgrind we actually don't
execve() systemd-shutdown. We have a comment about this in the code, but
being upfront about this change in behavior doesn't hurt.
Jon Ringle [Wed, 30 Aug 2017 09:38:00 +0000 (05:38 -0400)]
networkd: Honor configured DHCP ClientIdentifier on link_update (#6622)
We have an embedded board with a couple of ethernet ports. From the kernel
log, I can see that the ethernet drivers are obtaining their correct MAC
address, but for some reason, at first systemd-networkd doesn't see the
mac address for the ethernet port at the time that it looks at
dhcp_client_identifier configuration (it has 00:00:00:00:00:00 for mac).
Later on, systemd-networkd gets a link_update() call, and at this time, it
has the correct mac address for the ethernet port. However, in link_update()
the dhcp_client_identifier configuration is not being considered, and a call
to sd_dhcp_client_set_iaid_duid() is being done always
seccomp: default to something resembling the current personality when locking it
Let's lock the personality to the currently set one, if nothing is
specifically specified. But do so with a grain of salt, and never
default to any exotic personality here, but only PER_LINUX or
PER_LINUX32.
Add LockPersonality boolean to allow locking down personality(2)
system call so that the execution domain can't be changed.
This may be useful to improve security because odd emulations
may be poorly tested and source of vulnerabilities, while
system services shouldn't need any weird personalities.
Alan Jenkins [Tue, 29 Aug 2017 09:56:32 +0000 (10:56 +0100)]
fileio: rename function parameter to avoid masking global symbol
> glibc exports a function called sync(), we should probably avoid
> overloading that as a variable here locally (gcc even used to warn about
> that, not sure why it doesn't anymore), to avoid confusion around what
> "if (sync)" actually means
Felipe Sateler [Mon, 28 Aug 2017 16:49:03 +0000 (13:49 -0300)]
shared: Add a linker script so that all functions are tagget @SD_SHARED instead of @Base (#6669)
This helps prevent symbol collisions with other programs and libraries. In particular,
because PAM modules are loaded into the process that is creating the session, and
systemd creates PAM sessions, the potential for collisions is high.
Disambiguate all systemd calls by tagging a 'version' SD_SHARED.
Yu Watanabe [Sun, 27 Aug 2017 07:34:53 +0000 (16:34 +0900)]
journal-remote: show error message if output file name does not end with .journal
`journalctl -o export | systemd-journal-remote -o /tmp/dir -`
gives the following error messages.
```
Failed to open output journal /tmp/dir: Invalid argument
Failed to get writer for source stdin: Invalid argument
Failed to create source for fd:0 (stdin): Invalid argument
```
And these are hard to understand what is the problem.
This commit makes journal-remote check whether the output file name
ends with .journal suffix or not, and if not, output error message.
Michal Sekletar [Fri, 25 Aug 2017 13:36:10 +0000 (15:36 +0200)]
service: attempt to execute next main command only for oneshot services (#6619)
This commit fixes crash described in
https://github.com/systemd/systemd/issues/6533
Multiple ExecStart lines are allowed only for oneshot services
anyway so it doesn't make sense to call service_run_next_main() with
services of type other than SERVICE_ONESHOT.
Referring back to reproducer from the issue, previously we didn't observe
this problem because s->main_command was reset after daemon-reload hence
we never reached the assert statement in service_run_next_main().
Alan Jenkins [Thu, 24 Aug 2017 14:21:21 +0000 (15:21 +0100)]
logind: tighten assertion in execute_shutdown_or_sleep()
Following commit b498d6ea, I belated realized we should tighten the
assertions as well, to make sure that we're setting `m->action_what` to
represent an action in progress. (The check for an action in progress is
to compare `m->action_what` to zero)
Alan Jenkins [Thu, 24 Aug 2017 09:33:24 +0000 (10:33 +0100)]
logind: add missing resume signal when we fail to initiate sleep/shutdown
This fixed https://bugzilla.redhat.com/show_bug.cgi?id=1476313
as much as I was able to reproduce it in a VM, at least.
E.g. this signal might wake the screen back up, providing a more visible
indicator of suspend failure. In my VM testing, it was also required in
order to unblock keyboard input in gnome-shell after the failed suspend.
At the same time, fix the error handling for scheduled shutdowns. This now
mirrors the behaviour of when you use `shutdown -k` - it sends all the
scary messages about shutting down, "but you'll have to do it [shut down
the system] yourself". It also avoids the risk of locking out the admin
(nologin file), in case they logged out for some reason (and they use
`sudo` instead of root).
Not that I have any idea why you'd want to use `shutdown -k`, but the code
is easier to analyze if it rolls back on error (in the absence of any code
comment as to why that's not wanted).
Alan Jenkins [Mon, 21 Aug 2017 16:28:35 +0000 (17:28 +0100)]
logind: respect "delay" inhibitors in scheduled shutdowns
There is no justification not to wait an extra (default) 5 seconds, for
a more graceful shutdown of user programs. Again, you don't get to ignore
delay inhibitors for unscheduled shutdowns, short of
`systemctl poweroff -f`.
It is simplest if we move the test for `m->shutdown_dry_run` into
manager_scheduled_shutdown_handler().
However we need to not add such delays during a "dry run". Otherwise, we
would still have to be considered "in progress" for some seconds after our
admin has seen the final wall message. If they go to `poweroff`, we would
have blocked them with a misleading error message. Note this `poweroff`
will still process delay inhibitors as needed. If the admin planned to
use a more forceful method... eh. It's their responsibility to assess
whether that's safe.
There is an argument that the alternative behaviour could be used (racily!)
to kludge around them not being able to shutdown to "single user mode". If
we cared about that case, we would have easily preserved non-racy support
for it in `shutdown`.
Additionally, though I think this code does read more easily by reducing
inconsistencies, we didn't come up with any use case for delay inhibitors
v.s. shutdown.[1] The SIGTERM v.s. SIGKILL delay is more general, and we
allow a whole 90 seconds for it, not just 5. So I don't think keeping this
approach bears a risk of significant damage.
According to the above comment, if the conflicting operation is hung,
we don't want to force things when the admin has not passed a force option.
Similarly if you're not an admin, you probably shouldn't get to sneak
around this check by using a scheduled shutdown instead of an unscheduled
one. (And no-one so far thought it necessary to add such a permission in
PolKit).
Note that if the conflicting operation was _not_ hung, and we lost the
race with suspend, the system might not have shut down at the scheduled
time anyway. Which is no good if you were scheduling a power outage.
And scheduling a shutdown for an arbitrary time when the system is resumed,
does not seem a very useful semantic. More likely, scheduled shutdowns are
useful on systems which do not use suspend, such as multi-user servers.
(In which case even PolKit defaults likely don't let the users trigger
suspend).