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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This doesn't really matter, since in non-/usr-merged systems plymouth
needs to be in /bin and on merged ones it doesn't matter, but it is
still prettier to insert the right path, and avoid /bin on merged
systems, since it's just a compat symlink.
Replaces: #15351
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 emergency.service and rescue.service units have become rather
convoluted. We spawn multiple shells and the help text spans multiple lines
which makes the units hard to read.
Move the logic into a single shell script and call that via ExecStart.
Ideally, plymouth should only be referenced via dependencies,
not ExecStartPre's. This at least avoids the confusing error message
on minimal installations that do not carry plymouth.
Quoting @cgwalters:
Just uploading this as an RFC. Now I know reading the code that systemd says
`Welcome to $OS` as a generic thing, but my initial impression on seeing this
was that it was almost sarcastic =)
Let's say "You are in emergency mode" as a more neutral/less excited phrase.
This patch is based on #3556, but makes the same change for rescue mode.
When enabling ForwardToSyslog=yes, the syslog.socket is active when entering
emergency mode. Any log message then triggers the start of rsyslog.service (or
other implementation) along with its dependencies such as local-fs.target and
sysinit.target. As these might fail themselves (e. g. faulty /etc/fstab), this
breaks the emergency mode.
This causes syslog.socket to fail with "Failed to queue service startup job:
Transition is destructive".
Add Conflicts=syslog.socket to emergency.service to make sure the socket is
stopped when emergency.service is started.
Fixes#266
Merely calling "plymouth quit" isn't sufficient, as plymouth needs some time to
shut down. This needs plymouth --wait (which is a no-op when it's not running).
Fixes invisible emergency shell with plymouth running endlessly.
https://launchpad.net/bugs/1471258
Currently after exiting rescue shell we isolate default target. User
might want to isolate to some other target than default one. However
issuing systemctl isolate command to desired target would bring system
to default target as a consequence of running ExecStopPost action.
Having common ancestor for rescue shell and possible followup systemctl
default command should fix this. If user exits rescue shell we will
proceed with isolating default target, otherwise, on manual isolate,
parent shell process is terminated and we don't isolate default target,
but target chosen by user.
Suggested-by: Michal Schmidt <mschmidt@redhat.com>
Do not suggest to the user that commands can be issued before
logging in.
sulogin prints it own message, which mentions ^D, so there's no need
to repeat it here.
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.
Especially in the case of --enable-split-usr, several units will point
to the wrong location for systemctl. Use @SYSTEMCTL@ which will always
contain the proper path.
