| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
triggered (#6765)" (#6904)
This reverts commit f1e24a259ca182b6cd8a723a56da43435ce48aac. 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.
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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.]
|
| |
|
|
|
|
|
| |
Commit 5ed020d8d10fc100c68edddb519f085b7397a45c already fixed this issue for
getty@.service but forgot serial console.
Note that this is not needed for emergency target as the sysinit target
conflicts against this target already.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For pluggable ttys such as USB serial devices, the getty is restarted
and exits in a loop until the remove event reaches systemd. Under
certain circumstances the restart loop can overload the system in a
way that prevents the remove event from reaching systemd for a long
time (e.g. at least several minutes on a small embedded system).
Use the default RestartSec to prevent the restart loop from
overloading the system. Serial gettys are interactive units, so
waiting an extra 100ms really doesn't make a difference anyways
compared to the time it takes the user to log in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the first 3270 terminal device that is associated with the Linux preferred
console to the list of virtualization consoles. This is required to
automatically start a getty if the conmode=3270 kernel parameter is specified
for Linux on z/VM instances. Note that a queued upstream patch also enable
the 3270 terminal device if it is associated with the Linux preferred console.
How
To successfully start agetty on a 3270 terminal, a change in the agetty
parameter order is required. Previously, agetty would started like this:
/sbin/agetty --keep-baud 3270/tty1 115200,38400,9600 TERM
The agetty program interprets the "3270/tty1" as baud rate and fails to start
with the "bad speed: 3270/tty1" error message. Fixing this in agetty is more
complex rather than reordering the command line parameters like this:
/sbin/agetty --keep-baud 115200,38400,9600 3270/tty1 TERM
According to agetty sources and "agetty --help", agetty accepts the "tty",
"baudrate tty", and "tty baudrate" specifications.
P.S. The "tty: Set correct tty name in 'active' sysfs attribute" introduces
a change to display the terminal device which is associated with the
Linux preferred console. This change helps to let systemd handle this
particular case only. Without the changes of this commit, no additional
3270 terminal device can be managed by systemd.
https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git/commit/?id=723abd87f6e536f1353c8f64f621520bc29523a3
|
| |
|
|
|
|
|
| |
This makes it easier to manually enable and disable
specific gettys, and also mirrors getty@.service.
http://lists.freedesktop.org/archives/systemd-devel/2014-February/017329.html
|
| |
|
|
|
| |
This way we can make use of our logic to automatically determine an
appropriate TERM for a specific tty.
|
| |
|
|
| |
This is useful to fake session ends for processes like shells.
|
| |
|
|
|
|
|
|
|
| |
* baud rate is optional and unnecessary for virtual terminals
* term type is optional (default is 'linux' for virtual terminals
and 'vt102' for serial lines)
* long options are more user-friendly
... all this is supported since util-linux v2.20 (Aug 2011).
|
| |
|
|
|
| |
Since rc-local is now enabled via the SysV compatibility we should only refer
to it based on that too.
|
| | |
|
| |
|
|
|
|
|
|
| |
Environment=TERM=... has no effect on agetty who sets it by itself. To
really set TERM to a specified value, it has to be given on the command
line.
https://bugzilla.redhat.com/show_bug.cgi?id=870622
|
| |
|
|
|
| |
This makes the behaviour wrt. to rc[-.]local consistent between
various distributions supporting it.
|
| |
|
|
|
|
|
|
| |
all other dependencies are in 3rd person. Change BindTo= accordingly to
BindsTo=.
Of course, the dependency is widely used, hence we parse the old name
too for compatibility.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This should help making the boot process a bit easier to explore and
understand for the administrator. The simple idea is that "systemctl
status" now shows a link to documentation alongside the other status and
decriptionary information of a service.
This patch adds the necessary fields to all our shipped units if we have
proper documentation for them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Type=idle is much like Type=simple, however between the fork() and the
exec() in the child we wait until PID 1 informs us that no jobs are
left.
This is mostly a cosmetic fix to make gettys appear only after all boot
output is finished and complete.
Note that this does not impact the normal job logic as we do not delay
the completion of any jobs. We just delay the invocation of the actual
binary, and only for services that otherwise would be of Type=simple.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We finally got the OK from all contributors with non-trivial commits to
relicense systemd from GPL2+ to LGPL2.1+.
Some udev bits continue to be GPL2+ for now, but we are looking into
relicensing them too, to allow free copy/paste of all code within
systemd.
The bits that used to be MIT continue to be MIT.
The big benefit of the relicensing is that closed source code may now
link against libsystemd-login.so and friends.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gettys are nowadays mostly autospawned and hence usually subject to
being shut down on isolate requests, since they are no dependency of any
other unit. This is a bad idea if the user isolates between
multi-user.graphical and graphical.target, hence exclude them from the
isolation.
This has the effect that gettys no longer cleaned up when
emergency.target is isolated, which might actualy be considered a
feature, even though it is a change from previous behaviour...
Note that the one getty that really matters (the one on tty1) is still
removed when isolating to emergency.target since it conflicts with
emergency.service.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for the Mageia Linux distribution:
http://www.mageia.org/
Mageia is a fork of Mandriva although some divergence has already occured
and thus inclusion of these changes upstream allow us to (hopefully)
migrate more rapidly to the new standard approaches systemd offers.
Indeed, we already use the preferred mechanism of OS identification via
the /etc/os-release file rather than a distro specific variation.
This patch mostly mirrors the patch added previously for Mandriva
support. In addition to those original authors, this patch was mostly
written by Dexter Morgan with help from Colin Guthrie and Eugeni Dodonov.
|
| |
|
|
|
|
|
|
|
| |
Explicitly disconnect all clients from a VT when a getty starts/finishes
(requires TIOCVHANGUP, available in 2.6.29).
Explicitly deallocate getty VTs in order to flush scrollback buffer.
Explicitly reset terminals to a defined state before spawning getty.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This merges several separate patches that I carry as part of
Mandriva systemd RPM. They touch those parts that are very
unlikely to be changed in near future and do not impose any
functionality change for systemd core. I also think it is
useful for troubleshooting to have real distribution name in
system logs, espicially when someone reports problem upstream.
The patch looks bigger than sum of replaced patches because
- previous patches were applied on top of distro=fedora, now
I need to add all those bits for distro=mandriva as well
- part of patch was done as spec file magic, but it seems more
logical to ship all these bits together
|
| |
|
|
| |
Please apply patch for update ALTLinux support.
|
| | |
|
| |
|
|
| |
we never know which ttys plymouth still controls
|
| |
|
|
| |
pam_securetty can now look for console= in /proc/cmdline
|
| |
|
|
|
|
|
|
|
|
|
|
| |
TERM=vt100-nav was necessary for compat with some ppc hvc devices, a
long time ago. Unfortunately vt100-nav terminfo is not installed by
default on most distros, hence change the default to v100 which is
available universally and still should be a relatively safe and
conservative default.
Should it turn out that vt100 is not really the best choice we can
revert this change again and then ask distros to move vt100-nav into
their default install.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The property StopRetroactively= needs to be per-dependency, not
per-unit, in order to properly express dependencies between .mount units
and its .device and fsck .service units. If the .device unit is
unplugged the mount should go away, but if the fsck process terminates
the .mount should stay.
|
| | |
|
| |
|
|
| |
similar
|
| |
|
