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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The service has Type=oneshot, which means that the default value of SuccessExitStatus=0.
When multiple vtcon devices are detected, udev will restart the service after each
one. If this happens quickly enough, the old instance will get SIGTERM while it is
still running:
[ 5.357341] (udev-worker)[593]: vtcon1: /usr/lib/udev/rules.d/90-vconsole.rules:12 RUN '/usr/bin/systemctl --no-block restart systemd-vconsole-setup.service
[ 5.357439] (udev-worker)[593]: vtcon1: Running command "/usr/bin/systemctl --no-block restart systemd-vconsole-setup.service"
[ 5.357485] (udev-worker)[593]: vtcon1: Starting '/usr/bin/systemctl --no-block restart systemd-vconsole-setup.service'
[ 5.357537] (udev-worker)[609]: vtcon0: /usr/lib/udev/rules.d/90-vconsole.rules:12 RUN '/usr/bin/systemctl --no-block restart systemd-vconsole-setup.service
[ 5.357587] (udev-worker)[609]: vtcon0: Running command "/usr/bin/systemctl --no-block restart systemd-vconsole-setup.service"
[ 5.357634] (udev-worker)[609]: vtcon0: Starting '/usr/bin/systemctl --no-block restart systemd-vconsole-setup.service'
...
[ 5.680529] systemd[1]: systemd-vconsole-setup.service: Trying to enqueue job systemd-vconsole-setup.service/restart/replace
[ 5.680565] systemd[1]: systemd-vconsole-setup.service: Merged into running job, re-running: systemd-vconsole-setup.service/restart as 557
[ 5.680600] systemd[1]: systemd-vconsole-setup.service: Enqueued job systemd-vconsole-setup.service/restart as 557
...
[ 5.682334] systemd[1]: Received SIGCHLD from PID 744 ((le-setup)).
[ 5.682377] systemd[1]: Child 744 ((le-setup)) died (code=killed, status=15/TERM)
[ 5.682407] systemd[1]: systemd-vconsole-setup.service: Child 744 belongs to systemd-vconsole-setup.service.
[ 5.682436] systemd[1]: systemd-vconsole-setup.service: Main process exited, code=killed, status=15/TERM
[ 5.682471] systemd[1]: systemd-vconsole-setup.service: Failed with result 'signal'.
[ 5.682518] systemd[1]: systemd-vconsole-setup.service: Service will not restart (manual stop)
[ 5.682552] systemd[1]: systemd-vconsole-setup.service: Changed stop-sigterm -> failed
This is expected and not a problem. Let's treat SIGTERM as success so we don't
get this spurious "failure".
"Setup" is a noun, and the expected order is "<adjective> <noun>".
("Set up" is the verb. But we want a noun here, so that we can say
e.g. "Starting Virtual Console Setup".)
No functional change, just a cleanup to make the subsequent changes easier to
see. This is a continuation of 9810e41942
> The block is reordered and split to have:
> 1. description + documentation
> 2. (optionally) conditions
> 3. all the dependencies
The dependencies for shutdown.target are listed separately because they are the
other deps are for startup, and shutdown.target only matter much later.
Previous patch to add an implicit dependency effectively orders various getty
services after systemd-vconsole-setup.service. But I think it's cleaner to also
order the service before sysinit.target, like it was before
8125e8d38e. There might be units which don't do
use TTYVHangup= but would like to have the console fully initialized.
Also, add a manual ordering to debug-shell.service, because it has
ImplicitDependencies=no. This might delay debug-shell.service a bit, but
systemd-vconsole-setup.service has no dependencies and should be very quick, so
this should not be noticable in practice. Without the ordering, the terminal
might not have a key map loaded, making debug-shell.service hard to use.
We don't need two (and half) templating systems anymore, yay!
I'm keeping the changes minimal, to make the diff manageable. Some enhancements
due to a better templating system might be possible in the future.
For handling of '## ' — see the next commit.
This reverts the second part of 8125e8d38e.
The first part was reverted in 750e550eba.
The problem starts when s-v-s.s is pulled in by something that is then pulled
in by sysinit.target. Every time a unit is started, systemd recursively checks
all dependencies, and since sysinit.target is pull in by almost anything, we'll
start s-v-s.s over and over. In particular, plymouth-start.service currently
has Wants=s-v-s.s and After=s-v-s.s.
When the service is run in the initramfs, it is possible for it to get started
and not be fast enough to exit before the root switch happens. It is started
multiple times (depending on the consoles being detected), and runs
asynchronously, so this is quite likely. It'll then get killed by killall(),
and systemd will consider the service failed. To avoid all this, just wait
for the service to terminate on it's own.
Before=initrd-switch-root.target should be good for the initramfs, and
Before=shutdown.tuarget should be good for the real system, although it's
unlikely to make any difference there.
Udev rules cover all the necessary initializations.
As the service now is neither installed, nor installable - we can
remove explicit dependencies and RemainAfterExit=yes option.
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.
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.
DefaultStandardOutput is syslog anyway. There's no reason to assume that
the administrator would want these units to be excluded when he configures
a different DefaultStandardOutput.
