IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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).
