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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If true randomness is needed before udev is triggered, which would load
virtio_rng, reading /dev/random takes forever and the boot stalls for a
long time.
tmpfiles.d option "e" when run through systemd-tmpfiles --create should
apply configured permissions (uid,gid) only to already existing
files. When file doesn't exist we bail out with error. Instead we should
silently ignore non-existing files.
$ useradd test
$ cat /etc/tmpfiles.d/foobar.conf
e /tmp/test - test test 1d
$ ls -l /tmp/test
ls: cannot access '/tmp/test': No such file or directory
Before:
$ systemd-tmpfiles --create /etc/tmpfiles.d/foobar.conf
Adjusting owner and mode for /tmp/test failed: No such file or directory
$ echo $?
1
After:
$ systemd-tmpfiles --create /etc/tmpfiles.d/foobar.conf
$ echo $?
0
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
Prevent networkd from crashing when UseMTU is used. Many drivers will
bring the link down and then back up to configure a new MTU. Networkd
will also asynchonously send rtnl messages to configure the link and may
receive responses after the link has gone down and come back up (which
networkd will handle and set the lease and network to NULL.
This changes the behavior to instead return if this is the case instead
of crashing via assert.
ACTION_EMERGENCY and ACTION_DEFAULT would be handled correctly by
start_with_fallback(). However there is no fallback available for
them, and they would never be set in `arg_action` in the first
place. Remove the unused cases from the switch statement.
@poettering suggested this makes a good place to clarify the point,
explicitly listing all the `arg_action` values which would never be
set.
This prevents `systemctl` from runnning /bin/touch when the following
command is used:
```
systemctl -H '-oProxyCommand=/bin/touch i-shouldnt-be-here' show-environment
```
Other parts of the code do just use `table` as identifier for the actual
routing table id. This change should make it easier to read through the
code since the meaning or rather the name stays the same.
Previously there was only `VRF.TableId` which only supported numeric
identifiers for routing table. With the additiona of
`config_parse_route_table` also names can be used as identifiers.
This breaks things when the decrypted device is not immediately
`SYSTEMD_READY=1` (e. g. when a multi-device btrfs system is placed on
multiple cryptsetup devices).
Fixes#6537.
systemd-shutdown is run after the network is stopped,
so remounting a network filesystem read-only can hang.
A simple umount is the most useful thing that can
be done for a network filesystem once the network is down.
The last sentence in the paragraph described the behaviour of `--global`. But "the last case" we listed was "only this boot", which does not match... This was the fifth case described, but there are only _four_ different option names. Fix it.
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.
`systemctl default` uses job mode `isolate` (see `action_table`).
The job mode option is ignored.
Note that exiting the emergency shell service by using e.g.
`systemctl isolate multi-user` or `systemctl start multi-user.target`
already kills `emergency.service`. There's only a potential conflict
between your command and the command in systemd-sulogin-shell if you run
something like `systemctl start --no-block multi-user.target; exit`.
Which is nothing like what we told them to do :).
When a device is unplugged all device units sharing the same sysfs path
pointing to that device are supposed to be removed.
However it didn't work since while iterating the device unit list containing
all the relevant units, each unit was removed during each iteration of
LIST_FOREACH. However LIST_FOREACH doesn't support this use case and
LIST_FOREACH_SAFE must be use instead.
If a message is too large to fit into the output buffer, it will be
transmitted to the kernel in several chunks. However, the FDs must
only ever be transmitted once or they will bereceived by the remote
end repeatedly.
The D-Bus specification disallows several sets of FDs attached to
one message, however, the reference implementation of D-Bus will
not reject such a message, rather it will reassign the duplicate
FDs to subsequent FD-carrying messages.
This attaches the FD array only to the first byte of the message.
Commit also mentions that when running under valgrind we actually don't
execve() systemd-shutdown. We have a comment about this in the code, but
being upfront about this change in behavior doesn't hurt.
We have an embedded board with a couple of ethernet ports. From the kernel
log, I can see that the ethernet drivers are obtaining their correct MAC
address, but for some reason, at first systemd-networkd doesn't see the
mac address for the ethernet port at the time that it looks at
dhcp_client_identifier configuration (it has 00:00:00:00:00:00 for mac).
Later on, systemd-networkd gets a link_update() call, and at this time, it
has the correct mac address for the ethernet port. However, in link_update()
the dhcp_client_identifier configuration is not being considered, and a call
to sd_dhcp_client_set_iaid_duid() is being done always
