Alan Jenkins [Tue, 19 Dec 2017 20:22:05 +0000 (20:22 +0000)]
man: User=, Group= *never* work for mount units (#7602)
Old text:
> Note that the User= and
> Group= options are not particularly useful for mount units specifying a
> "Type=" option or using configuration not specified in /etc/fstab;
> mount(8) will refuse options that are not listed in /etc/fstab if it is
> not run as UID 0.
However I recently learnt the following:
> The mount program does not read the /etc/fstab file if both device
> and dir are specified.
Therefore, if both device and dir are specified, the `user` or `users`
options in `fstab` will not have any effect. Run as a normal user,
you will always see
mount: only root can do that
Fix the explanation in the man page.
Also make sure to markup User= and Group= with <varname>.
John Paul Herold [Tue, 19 Dec 2017 10:22:36 +0000 (04:22 -0600)]
Add T430 series to list of supported trackpoint (#7699)
Confirmed via `udevadm test /sys/class/input/eventX` that
POINTINGSTICK_* properties were not being set for my T430s trackpoint.
After adding a local entry file (as advised in this file), the same
`udevadm test` command showed properties.
More importantly, the movement of mouse using trackpoint felt much
better. Hard to describe its previous state, but following come to mind:
slippery, hard to control, awkward. Now it feels more consistent and predictable.
A little on the sensitive side with the defaults, but didn't think it warranted
dedicated properties just for this series though as the X230 is same generation
and uses the defaults.
Jörg Thalheim [Tue, 19 Dec 2017 10:13:34 +0000 (10:13 +0000)]
more portable perl shebangs (#7701)
same motivation as in #5816:
- distributions have scripts to rewrite shebangs on installation and
they know what locations to rely on.
- For tests/compilation we should rather rely on the user to have setup
there PATH correctly.
analyze: use normal bus connection for "plot" verb (#7685)
We need to connect to hostnamed, so a private bus connection is no good.
It'd be simpler to use the normal bus connection unconditionally, but
that'd mean that e.g. systemd-analyze set-log-level might not work in
emergency mode. So let's keep trying to use the private connection except
for "plot".
cryptsetup-generator: Don't mistake NULL input as OOM (#7688)
Since systemd v236, several Arch users complained that
systemd-cryptsetup-generator exits with an OOM error and that it
prevents the boot from continuing.
Investigating the diff of cryptsetup-generator between v235 and v236 I
noticed that create_disk allowed for the `password` and `filtered`
variables to be NULL (they're handled with `strempty()`) but not their
`*_escaped` versions, and returned OOM errors in those cases.
Fix this by checking that the input string is non-NULL before deciding
that `specifier_escape` had an OOM error.
I could not test this fix myself, but some users have reported success.
Up until now, the behaviour in systemd has (mostly) been to silently
ignore failures to action unit directives that refer to an unavailble
controller. The addition of AssertControlGroupController and its
conditional counterpart allow explicit specification of the desired
behaviour when such a situation occurs.
As for how this can happen, it is possible that a particular controller
is not available in the cgroup hierarchy. One possible reason for this
is that, in the running kernel, the controller simply doesn't exist --
for example, the CPU controller in cgroup v2 has only recently been
merged and was out of tree until then. Another possibility is that the
controller exists, but has been forcibly disabled by `cgroup_disable=`
on the kernel command line.
In future this will also support whatever comes out of issue #7624,
`DefaultXAccounting=never`, or similar.
Alan Jenkins [Sat, 16 Dec 2017 10:48:12 +0000 (10:48 +0000)]
man: generalize "binary" to "program" (#7668)
Systemd services are permitted to be scripts, as well as binary
executables.
The same also applies to the underlying /sbin/mount and /sbin/swapon.
It is not necessary for the user to consider what type of program file
these are. Nor is it necessary with systemd-nspawn, to distinguish between
init as a "binary" v.s. a user-specified "program".
Also fix a couple of grammar nits in the modified sentences.
This code is executed before we parse command line/configuration
parameters, hence let's not use arg_system to figure our how to clean up
things, but instead PID == 1. Let's move that check inside of the
function, to make things a bit more robust abstract from the outside.
Also, let's add a log message about this, that was so far missing.
main: move install_crash_handler() and mount_cgroup_controllers() invocations
Let's place them in initialize_runtime(), where they appear to fit best.
Effectively this is just a move a little bit down, swapping places with
log_execution_mode(), which should require neither call to be done
first.
Note that changes the conditionalization a bit for these calls, from
(PID == 1) to (arg_system && arg_action == ACTION_RUN). At this point this is pretty much the same
however, as we don't allow PID 1 without ACTION_RUN and without
arg_system set, safety_checks() ensures that.
core: move arg_show_status fix-up into load_configuration()
It's part of finalizing our runtime parameters, hence let's move this
into load_configuration() after we loaded everything else. This is safe,
since we don't use it between the location where it was and where we
place it now yet.
We need to specify a full path to the "ip" binary and busybox "ip" has a
slightly different output than the normal ip, and won't show "DOWN".
hence instead ensure that at lest not "UP" is in there.
The kernel needs two numbers, but for the user it's most convenient to provide the
user name and have that resolved to uid and gid.
Right now the primary group of the specified user is always used. That's the most
common case anyway. In the future we can extend the --owner option to allow a group
after a colon.
[I added this before realizing that this will not be enough to be used for user
runtime directory. But this seems useful on its own, so I'm keeping this commit.]
tree-wide: add DEBUG_LOGGING macro that checks whether debug logging is on (#7645)
This makes things a bit easier to read I think, and also makes sure we
always use the _unlikely_ wrapper around it, which so far we used
sometimes and other times we didn't. Let's clean that up.
Make taint message structured and add catalog entry
Dec 14 14:10:54 krowka systemd[1]: System is tainted: overflowgid-not-65534
-- Subject: The system is configured in a way that might cause problems
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- The following "tags" are possible:
-- - "split-usr" — /usr is a separate file system and was not mounted when systemd
-- was booted
-- - "cgroups-missing" — the kernel was compiled without cgroup support or access
-- to expected interface files is resticted
-- - "var-run-bad" — /var/run is not a symlink to /run
-- - "overflowuid-not-65534" — the kernel user ID used for "unknown" users (with
-- NFS or user namespaces) is not 65534
-- - "overflowgid-not-65534" — the kernel group ID used for "unknown" users (with
-- NFS or user namespaces) is not 65534
-- Current system is tagged as overflowgid-not-65534.
We have a check and warning at compile time. The user cannot do anything about
this at runtime, and all other taints are about checks that happen at runtime
and are specific to that system (and at least potentially correctable).
(The logic in the compilation-time check was updated to treat "nogroup" as OK,
but not the runtime check. But I think it's better to remove the runtime check
for this altogether, so this becomes moot.)
Colin Walters [Thu, 14 Dec 2017 20:23:02 +0000 (15:23 -0500)]
verbs: Rename VERB_OFFLINE to VERB_ONLINE_ONLY, expand MUSTBEROOT
Followup to previous commit. Suggested by @poettering.
Reindented the `verbs[]` tables to match the apparent previous
whitespace rules (indent to one flag, allow multiple flags to overflow?).
A lot of code references the `running_in_chroot()` function; while
I didn't dig I'm pretty certain this arose to deal with situations
like RPM package builds in `mock` - there we don't want the `%post`s
to `systemctl start` for example.
And actually this exact same use case arises for
[rpm-ostree](https://github.com/projectatomic/rpm-ostree/)
where we implement offline upgrades by default; the `%post`s are
always run in a new chroot using [bwrap](https://github.com/projectatomic/bubblewrap).
And here's the problem: bwrap creates proper mount roots, so it
passes `running_in_chroot()`, and then if a script tries to do
`systemctl start` we get:
`System has not been booted with systemd as init system (PID 1)`
but that's an *error*, unlike the `running_in_chroot()` case where we ignore.
Further complicating things is there are real world RPM packages
like `glusterfs` which end up invoking `systemctl start`.
A while ago, the `SYSTEMD_IGNORE_CHROOT` environment variable was
added for the inverse case of running in a chroot, but still wanting
to use systemd as PID 1 (presumably some broken initramfs setups?).
Let's introduce a `SYSTEMD_OFFLINE` environment variable for cases like
mock/rpm-ostree so we can force on the "ignore everything except preset" logic.
This way we'll still not start services even if mock switches to use nspawn or
bwrap or something else that isn't a chroot.
We also cleanly supercede the `SYSTEMD_IGNORE_CHROOT=1` which is now spelled
`SYSTEMD_OFFLINE=0`. (Suggested by @poettering)
Also I made things slightly nicer here and we now print the ignored operation.
resolve: extend systemd-resolve so that it can push per-interface DNS configuration into systemd-resolved (#7576)
This is useful to debug things, but also to hook up external post-up
scripts with resolved.
Eventually this code might be useful to implement a
resolvconf(8)-compatible interface for compatibility purposes. Since the
semantics don't map entirely cleanly as first step we add a native
interface for pushing DNS configuration into resolved, that exposes the
correct semantics, before adding any compatibility interface.
memset() is weird anyway, since it expects an "int" as second parameter,
which it then uses as a byte, i.e. as uint8_t or something like that.
But by passing -1 to it, things get particularly weird, as that relies
on sign expansion to do the right thing.
Kyle Walker [Thu, 14 Dec 2017 16:46:03 +0000 (11:46 -0500)]
core: Implement sync_with_progress()
In similar fashion to the previous change, sync() operations can stall
endlessly if cache is unable to be written out. In order to avoid an
unbounded hang, the sync takes place within a child process. Every 10
seconds (SYNC_TIMEOUT_USEC), the value of /proc/meminfo "Dirty" is checked
to verify it is smaller than the last iteration. If the sync is not making
progress for 3 successive iterations (SYNC_PROGRESS_ATTEMPTS), a SIGKILL is
sent to the sync process and the shutdown continues.
The changes in pci.ids, usb.ids, and the .hwdb files are almost always
additions. 20-OUI.hwdb drops a few names and replaces them by
"IEEE Registration Authority". I'm not sure what to do about this.
Many other removals do not seem to be removals of real entries, but
rather placeholder or generic names.