So far I avoided adding license headers to meson files, but they are pretty
big and important and should carry license headers like everything else.
I added my own copyright, even though other people modified those files too.
But this is mostly symbolic, so I hope that's OK.
There should be a way to turn this logic of, and DefaultDependencies=
appears to be the right option for that, hence let's downgrade this
dependency type from "implicit" to "default, and thus honour
DefaultDependencies=.
This also drops mount_get_fstype() as we only have a single user needing
this now.
A follow-up for #7076.
remote-cryptsetup-pre.target was designed as an active unit (that pulls in
network-online.target), the opposite of remote-fs-pre.target (a passive unit,
with individual provider services ordering itself before it and pulling it in,
for example iscsi.service and nfs-client.target).
To make remote-cryptsetup-pre.target really work, those services should be
ordered before it too. But this would require updates to all those services,
not just changes from systemd side.
But the requirements for remote-fs-pre.target and remote-cryptset-pre.target
are fairly similar (e.g. iscsi devices can certainly be used for both), so
let's reuse remote-fs-pre.target also for remote cryptsetup units. This loses
a bit of flexibility, but does away with the requirement for various provider
services to know about remote-cryptsetup-pre.target.
In the past we introduced this property just for tmp.mount. However on
todays systems usually there are many more tmpfs mounts. Most notably
mounts backing XDG_RUNTIME_DIR for each user.
Let's generalize what we already have for tmp.mount and implement the
ordering After=swap.target for all tmpfs based mounts.
This makes this target the same as remote-fs.target in this regard. In practice
it probably doesn't make that much difference, because all encrypted devices
that are part of remote-fs.target (marked with _netdev) will be used for mount
points, so they will be pulled in anyway individually, but with this change any
such device will be configured, even if it is not pulled by any other unit.
After the discussions around #7003 I think we should restore the
User=systemd-journal-gateway line for systemd-journal-gatewayd.service,
too, so that we continue to use the state user if it exists, and create
it as dynamic user only when it does not.
Note that undoes part of a change made after 234, i.e. a never released
change.
The configuration option was called -Dresolve, but the internal define
was …RESOLVED. This options governs more than just resolved itself, so
let's settle on the version without "d".
The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
1. If we exited emergency mode immediately, we don't want to have an
irreversible stop job still running for syslog.socket. I _suspect_ that
can't happen, but let's not waste effort working out exactly why it's
impossible and not just very improbable.
2. Similarly, it seems undesirable to have rescue.service and
emergency.service both running with an open FD of /dev/console, for
however short a period.
Note this commit only changes how the code is expressed; it does not change
the existence of any dependency.
The `Conflicts=` was added in 3136ec90, "Stop syslog.socket when entering
emergency mode". The discussion in the issue #266 raised concerns that
this might be needed for other units, but failed to point out why
syslog.socket is special. The reason is that syslog.socket has
DefaultDepedencies=no, so it does not get Requires=sysinit.target like
other socket units do. But syslog.service does require sysinit.target,
among other things.
We don't have many socket, path, or timer units with
DefaultDependencies=no, and I don't think any of the triggered services
have such additional hard dependencies as syslog.service does.
It is much less confusing if we keep this `Conflicts=` in the same file as
the `DefaultDependencies=no` which made it necessary.
The original aim of this commit is that starting machines.target from the
rescue shell would not kill the rescue shell and lock you out of the
system.
This is similar to commit 6579a622, for the conflict between
sysinit.target and the _emergency_ shell. That particular commit
introduced an ordering cycle and will need to be reverted and/or
fixed. This one does not, because it does not need to introduce any new
dependencies.
The reason why this commit is allowable also has it's own merit:
machines.target was not marked as AllowIsolate. Also, the point of
containers is to not escape them... I don't think we want to promote
machines.target as a default target or similar; you would generally want
some system service to allow you to shut down the machine, for example. I
don't see this approach used in CoreOS, nor in Fedora Atomic Host; we are
missing any positive examples of its utility.
Requires=basic.target / After=basic.target can be removed for the same
reason.
This reverts commit f1e24a259c. Oops.
# systemctl emergency
Failed to start emergency.target: Transaction order is cyclic. See syste...
See system logs and 'systemctl status emergency.target' for details.
# systemctl status emergency.target
● emergency.target - Emergency Mode
Loaded: loaded (/usr/lib/systemd/system/emergency.target; static; vendor preset: disabled)
Active: inactive (dead) since Mon 2017-09-25 10:43:02 BST; 2h 42min ago
Docs: man:systemd.special(7)
systemd[1]: sysinit.target: Found dependency on sysinit.target/stop
sysinit.target: Unable to break cycle starting with sysinit.target/stop
network.target: Found ordering cycle on wpa_supplicant.service/stop
network.target: Found dependency on sysinit.target/stop
network.target: Found dependency on emergency.target/start
network.target: Found dependency on emergency.service/start
network.target: Found dependency on serial-getty@ttyS0.service/stop
network.target: Found dependency on systemd-user-sessions.service/stop
network.target: Found dependency on network.target/stop
network.target: Unable to break cycle starting with network.target/stop
IMO #6509 is ugly enough that we should aim to answer it. But it could
take some time to investigate, so let's re-open the issue as a first step.
Why
---
The advantage of this is that starting sysinit.target from the emergency
shell will no longer kill the emergency shell and lock you out of the
system. Our docs already claimed that emergency.target was useful for
"starting individual units in order to continue the boot process in steps".
This resolves#6509 for my purposes.
Remaining limitation
--------------------
Starting getty.target will still kill the shell, and if you don't have a
root password you will then be locked out at that point. This is relevant
to distributions which patch the sulogin system to permit logins when the
root password is locked. Both Debian and RedHat used to follow this
behaviour! Debian have been discussing what they could replace it with at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806852
So this doesn't quite achieve perfection, but I think it's a worthwhile
change. It should be easier to understand the logic now it doesn't have
such a big hole in it. Repairing the sysinit stage of the boot is the main
reason we have emergency.target. And as discussed in the issue,
sysinit.target gets pulled in implicitly as soon as any DefaultDependencies
service is activated.
How
---
sysinit.target only needs to conflict with emergency.target. It didn't
need to conflict with emergency.service as well. In theory the conflicts
are pointless, we could just change the dependency of sysinit.target on
local-fs.target from Wants to Requires. However, doing so would mean that
when local-fs fails, the screen is flooded with yellow [DEPEND] failures.
That would hinder the poor unfortunate admin, so let's not do that.
There is no additional ordering requirement against emergency. If the
failure happens, the job for sysinit will be cancelled instantly. We don't
need to worry about when sysinit.target and its dependents would be
stopped, because sysinit waits for local-fs before it starts.
emergency.target is still necessarily stopped once we reach sysinit
(you can't express a one-way conflict in pure unit directives).
This is largely cosmetic... though perhaps it symbolizes that you're no
longer in Emergency Mode if System Initialization is successful ;-).
As a secondary advantage, the getty's which conflict on rescue.service now
need to conflict on emergency.service as well. This makes the system more
uniform and simpler to understand.
The only other effect this should have is that
`systemctl start emergency.target` is now practically the same as
`systemctl start rescue.target`. The only units this command will stop are
the conflicting getty units. Neither of those commands should ever be
used. E.g. they will not stop the gdm.service unit on Fedora 26.
The pair is similar to remote-fs.target and remote-fs-pre.target. Any
cryptsetup devices which require network shall be ordered after
remote-cryptsetup-pre.target and before remote-cryptsetup.target.
Normally this happens automatically, but if it happened that both targets were
pulled in, even though there were no cryptsetup units, they could be started
in reverse order, which would be somewhat confusing. Add an explicit ordering
to avoid this potential issue.
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.
https://lists.freedesktop.org/archives/systemd-devel/2015-July/033754.html
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.
Since hotplugs happen as soon as udevd is started, there is not much sense
in giving udev-trigger an After= dependency on any service. The device
could be hotplugged before coldplug starts.
This is intended to avoid the race window where we create the hwdb with
the wrong selinux context (then fix it up afterwards).
https://github.com/systemd/systemd/issues/3458#issuecomment-322444107
> Note that console-getty.service as more uses than just containers. The
> idea is that it may be used as alternative to the whole VC/logind stuff,
> if all you need is a console on /dev/console, even on physical devices.
This means we want to remove RestartSec=0, for serial systems.
See 4bf0432 "units/serial-getty@.service: use the default RestartSec".
The traditional runlevel 1 is "single user mode", and shuts down all but
the main console. In systemd, rescue.target provides runlevel1.target.
But it did not shut down logins on secondary consoles... if systemd was
running in a container.
I don't think we strictly need to change this. But when you look at both
container-getty@.service and getty@.service, you see that both have
IgnoreOnIsolate, but only the latter has Conflicts=rescue.service.
This also makes rescue.target in a container consistent with
emergency.target. In the latter case, the gettys were already stopped,
because they have a Requires dependency on sysinit.target.
Currently we have 4 getty services. 1 has a BindsTo dependency on a
device unit. 3 have ConditionPathExists, but the reason is different in
every single one.
* Add comment to console-getty@.service (see commit 1b41981d)
* getty@.service is already commented
* container-getty.service is not strictly correct, as I realized while
trying to compose a comment. Reported as #6584.
* Containers don't use serial-getty@console.service,
they use console-getty.service instead, and suppress
scanning for kernel or virtualizer consoles.
* Nowadays gettys are started on *all* configured kernel consoles.
* except for the line printer console, because that's not a tty.
(Seriously. Search CONFIG_LP_CONSOLE).
* Revert "modprobe.d: ship drop-in to set bonding max_bonds to 0 (#6448)"
This reverts commit 582faeb461.
* Revert "units: set ConditionVirtualization=!private-users on journald audit socket (#6508)"
This reverts commit d2a1ba103b.
Some kdbus_flag and memfd related parts are left behind, because they
are entangled with the "legacy" dbus support.
test-bus-benchmark is switched to "manual". It was already broken before
(in the non-kdbus mode) but apparently nobody noticed. Hopefully it can
be fixed later.
Since busname units are only useful with kdbus, they weren't actively
used. This was dead code, only compile-tested. If busname units are
ever added back, it'll be cleaner to start from scratch (possibly reverting
parts of this patch).
Currently we set 4096 as maximum for number of stream connections that
we accept. However maximum number of file descriptors that systemd is
willing to accept from us is just 1024. This means we can't retain all
stream connections that we accepted. Hence bump the limit of fds in a
unit file so that systemd holds open all stream fds while we are
restarted.
New limit is set to 4224 (4096 + 128).
Make agetty started by *getty* units pass '-p' option to "login", so it
doesn't clear the environment and passes whatever was setup by systemd
to shells. This is needed especially for programs which are specified as
user shells, but won't read locale settings from anywhere but
environment.
[zj: cherry-pick just the second patch from the series, see discussion
on the pull request.]
In the initial design, foobar-wait-online.service would have
Requisite=foobar.service, so that foobar-wait-online.service could be enabled
unconditionally, irrespective of whether foobar.service itself is enabled.
Unfortunately this doesn't work too well:
1. the message about foobar-wait-online.service being skipped because of a
"missing dependency" *looks* like an is problem. This is mostly cosmetic,
but it also quite confusing. We generally don't want any messages of this
type during default boot.
2. it is impossible to start and wait for the network in an
implementation-agnostic way: systemctl start network-online.target, or
Wants/After=network-online.target in a unit don't work because pulling in
network-online.target pulls in foobar-wait-online.service, but it in turn
does not pull in foobar.service. During startup, foobar.service is pulled in
by multi-user.target, but not in a smaller transaction which does not
include multi-user.target.
This change means that *-wait-online.service should be installed through
presets, so that it can be enabled/disabled at will by the administrator.
Our own systemd-networkd-wait-online.service does this already, and
similar change has been requested for NetworkManager-wait-online.service
(https://bugzilla.redhat.com/show_bug.cgi?id=1455704).
This change should by mostly backwards-compatible, unless somebody has some
wait-online.service enabled, without having the corresponding network
implementation enabled, and they are relying on it not being started. I think
that's relatively unlikely because of issue 1. above, and I'm not aware of this
being the default in any distro. And being able to start the network in an
implementation-agnostic way is pretty important, see
https://bugzilla.redhat.com/show_bug.cgi?id=1452866.
/var can be on a remote filesystem, thus hooking it to local-fs.target is not correct.
Also, only install the mount unit when machined is enabled, because
machined is the one managing the underlying device, and thus makes no
sense without machined.
Fixes#1175
This patch ensures that session devices are saved for each session.
In order to make the revokation logic work when logind is restarted, the
session devices are now saved in the session state files and their respective
file descriptors sent to PID1's fdstore in order to keep them open accross
restart.
This is mandatory in order to keep the revokation logic working. Indeed in case
of input-devices, the same file descriptors must be shared by logind and a
given session controller in order EVIOCREVOKE to work otherwise multiple
sessions can have device access in parallel.
This should be the only remaining and missing piece for making logind fully
restartable.
Fixes: #1163
Using conf.set() with a boolean argument does the right thing:
either #ifdef or #undef. This means that conf.set can be used unconditionally.
Previously I used '1' as the placeholder value, and that needs to be changed to
'true' for consistency (under meson 1 cannot be used in boolean context). All
checks need to be adjusted.
Shell scripts should be executable so that meson reports their
invocation succinctly (does not print 'sh' '-e').
Python scripts should not be executable so that meson does the
detection of the right python binary itself.
Add -u everywhere to catch potential errors.
The indentation for emacs'es meson-mode is added .dir-locals.
All files are reindented automatically, using the lasest meson-mode from git.
Indentation should now be fairly consistent.
Ideally, we would chain the m4 processing, .in substitutions, and file
installation so that the commands don't have to be repeated. Unfortunately
this does not seem currently possible, because custom_target() output cannot
be fed into install_data(), so it's necessary to use the 'install',
'install_dir' arguments to control installation. Nevertheless, rework the
rules to repeat less stuff and unify handling of conditions between the
different file types.
This is the equivalent of $(INSTALL_DIRS) and install-touch-usr-hook.
I did not bother to create the directories into which we install files,
since they will be created anyway.
v2:
- remove bashism
This is the equivalent of $(SYSTEM_UNIT_ALIASES) and $(GENERAL_ALIASES)
in Makefile.am.
ninja-build uninstall does not remove the symlinks, see
https://github.com/mesonbuild/meson/issues/1602.
I don't consider this a blocker: after all either one installs into $DESTDIR,
where uninstallation doesn't make much sense, or into a real system, where a
successfull uninstallation would likely destroy the system.
v2:
- remove bashisms
- add various forgotten symlinks and fix service/timer/target confusions
It's crucial that we can build systemd using VS2010!
... er, wait, no, that's not the official reason. We need to shed old systems
by requring python 3! Oh, no, it's something else. Maybe we need to throw out
345 years of knowlege accumulated in autotools? Whatever, this new thing is
cool and shiny, let's use it.
This is not complete, I'm throwing it out here for your amusement and critique.
- rules for sd-boot are missing. Those might be quite complicated.
- rules for tests are missing too. Those are probably quite simple and
repetitive, but there's lots of them.
- it's likely that I didn't get all the conditions right, I only tested "full"
compilation where most deps are provided and nothing is disabled.
- busname.target and all .busname units are skipped on purpose.
Otherwise, installation into $DESTDIR has the same list of files and the
autoconf install, except for .la files.
It'd be great if people had a careful look at all the library linking options.
I added stuff until things compiled, and in the end there's much less linking
then in the old system. But it seems that there's still a lot of unnecessary
deps.
meson has a `shared_module` statement, which sounds like something appropriate
for our nss and pam modules. Unfortunately, I couldn't get it to work. For the
nss modules, we need an .so version of '2', but `shared_module` disallows the
version argument. For the pam module, it also didn't work, I forgot the reason.
The handling of .m4 and .in and .m4.in files is rather awkward. It's likely
that this could be simplified. If make support is ever dropped, I think it'd
make sense to switch to a different templating system so that two different
languages and not required, which would make everything simpler yet.
v2:
- use get_pkgconfig_variable
- use sh not bash
- use add_project_arguments
v3:
- drop required:true and fix progs/prog typo
v4:
- use find_library('bz2')
- add TTY_GID definition
- define __SANE_USERSPACE_TYPES__
- use join_paths(prefix, ...) is used on all paths to make them all absolute
v5:
- replace all declare_dependency's with []
- add more conf.get guards around optional components
v6:
- drop -pipe, -Wall which are the default in meson
- use compiler.has_function() and compiler.has_header_symbol instead of the
hand-rolled checks.
- fix duplication in 'liblibsystemd' library name
- use the right .sym file for pam_systemd
- rename 'compiler' to 'cc': shorter, and more idiomatic.
v7:
- use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D
- rename prefix to prefixdir, rootprefix to rootprefixdir
("prefix" is too common of a name and too easy to overwrite by mistake)
- wrap more stuff with conf.get('ENABLE...') == 1
- use rootprefix=='/' and rootbindir as install_dir, to fix paths under
split-usr==true.
v8:
- use .split() also for src/coredump. Now everything is consistent ;)
- add rootlibdir option and use it on the libraries that require it
v9:
- indentation
v10:
- fix check for qrencode and libaudit
v11:
- unify handling of executable paths, provide options for all progs
This makes the meson build behave slightly differently than the
autoconf-based one, because we always first try to find the executable in the
filesystem, and fall back to the default. I think different handling of
loadkeys, setfont, and telinit was just a historical accident.
In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs.
In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin),
but in Debian, those directories are not included in the path.
C.f. https://github.com/mesonbuild/meson/issues/1576.
- call all the options 'xxx-path' for clarity.
- sort man/rules/meson.build properly so it's stable
systemd-resolved provides
1. local API via NSS and D-Bus
2. kind of a local "DNS proxy" through its stub listener
The 1st item should be started before nss-lookup.target.
The 2nd item should be started before network-online.target,
because if the networking works in general, then DNS (and DNS proxy) should too.
Fixes#5650
This makes dbus-org.freedesktop.network1.service like dbus-org.freedesktop.resolve1.service.
When systemd-networkd.service is disabled, the alias is also removed.
The commit c7fb922d62 prohibits
journal-upload to save its state in /var/lib/systemd/journal-upload/state,
thus the daemon fails and outputs the following error message even if
the directory is not read-only file system
```Cannot save state to /var/lib/systemd/journal-upload/state: Read-only file system```
This commit adds the permission the daemon to write the state file.
