For non-`seat0` seats, attaching a graphics card to a seat can
lead to it getting created. This is because the graphics device
is a "master device" which means that device is a seat-defining
device.
`seat0` may get created, even before the graphics driver is loaded,
though. This is because the graphics driver is loaded
asynchronously at startup, and `seat0` is the primary seat of
system, associated with the system VTs.
When a graphics card is attached to a seat the `CanGraphical`
property on that seat will flip to `true`.
For seats that haven't been created yet (non-`seat0` seats), this
leads to `seat_start` getting called which ultimately causes the
seat to get serialized to `/run/systemd/seats`.
For `seat0`, which is already created, `seat_start` will return
immediately, which means the updated `CanGraphical` state will
never get written to `/run/systemd/seats`.
The end result is that clients querying `sd_seat_can_graphical`
won't get the correct answer for `seat0` in cases where the
graphics device takes a long time to load until some other peice
of seat state is updated.
This commit fixes the problem by calling `seat_save` explicitly
for already running seats at the time a graphics device is
attached.
We are not the ones receiving an error here, but the ones generating it,
hence we shouldn't show it with %m, that's just confusing, as it
suggests we received an error from some other call.
Previously, together with kill_dots true, patch like
".", "./.", ".//.//" would all return an empty string.
That is wrong. There must be one "." left to reference
the current directory.
Also, the comment with examples was wrong.
The behaviour described *was* observed on Fedora 28
(systemd-238-9.git0e0aa59), with and without SELinux. I don't actually
know why though! It contradicts my understanding of the code, including an
explicit comment in the code.
Testing in a VM upgraded to v239-792-g1327f272d, this behaviour goes away.
Test case:
# /etc/systemd/system/mount-test.service
[Service]
MountFlags=shared
Type=oneshot
ExecStart=/usr/bin/ls -l /proc/1/ns/mnt /proc/self/ns/mnt
ExecStart=/usr/bin/grep ext4 /proc/self/mountinfo
Weird old behaviour: new mount namespace but / is fully shared.
lrwxrwxrwx. 1 root root 0 Sep 14 11:18 /proc/1/ns/mnt -> mnt:[4026531840]
lrwxrwxrwx. 1 root root 0 Sep 14 11:48 /proc/self/ns/mnt ->
mnt:[4026532851]
968 967 253:0 / / rw,relatime shared:1 - ext4 /dev/mapper/alan_dell_2016...
Current behaviour: / is not fully shared
lrwxrwxrwx. 1 root root 0 Sep 14 11:39 /proc/1/ns/mnt -> mnt:[4026531840]
lrwxrwxrwx. 1 root root 0 Sep 14 11:41 /proc/self/ns/mnt ->
mnt:[4026532329]
591 558 8:3 / / rw,relatime shared:313 master:1 - ext4 /dev/sda3 rw,secl...
When a link is configured, wait until there is a Router Advertisement before
attempting to start DHCPv6. The intended DHCPv6 mode will be evaluated in
ndisc_router_handler() in networkd-ndisc.c.
Arguably, libsystemd-network is (still) entirely internal API.
However there is the aim of maybe exposing it as public API.
For that reason, it cannot include internal headers from
"src/basic/".
Note how files "src/systemd/sd-*.h" don't include any systemd
headers which don't themself have an "sd-" prefix.
Fixes: d89a400ed6
It is very useful for distributions to be able to set a primary
documentation URL in a standard location so that users and
applications on the system can identify it. For example, many
headless systems these days use the "Cockpit" admin console. It
would be ideal if we could specify this location directly in the
os-release file so that any application or service could have a
well-known location for retrieving this and displaying it
appropriately. Users could likewise examine /etc/os-release to
learn this location.
Related: https://github.com/cockpit-project/cockpit/issues/10198
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
This removes $RENAME_NOREPLACE_DIR and uses a command-line argument instead.
Logging is added, and tests are skipped if we get -EPERM or friends
(which happens on FAT and other filesystems).
0 can be a valid index returned by the BIOS, so allow that by using the
parsing function safe_atolu() to check for errors without excluding the
valid value "0".
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Request prefix delegation for a new downstream link that is enabled
after any number of upstream DHCPv6 links. Submit the request after
the link has been configured with a link-local address.
If the upstream DHCPv6 client has already been configured to request
prefixes, attempt to re-assign any possible prefixes between the
already existing links and the new one. If no prefixes are yet
acquired, nothing will happen right away and any prefixes will be
distributed after a reply from the DHCPv6 server.
If none of the already existing downstream links have requested
DHCPv6 prefixes to be assigned, enable prefix delegation for each
client and restart them one by one if they are already running. This
causes the DHCPv6 clients to re-acquire addresses and prefixes and
to re-distribute them to all links when receiving an updated
response from their respective DHCPv6 servers. If the DHCPv6 client
in question was not already running, it is set to request prefixes
but not restarted.
When an error occurs while setting or restarting the DHCPv6 client,
log the incident and move over to the next link.
Fixes#9758.
Zbigniew Jędrzejewski-Szmek