[systemd-devel] Why does reboot invoke kexec command?
Hi, >From systemd code, if kexec kernel is loaded, executing 'reboot' will finally enter into reboot system call with KEXEC action. Wondering why it has to invoke kexec command. Asking this because in redhat CKI testing, one test case is 'kexec reboot'. Now it's always failed and the relevant log is as below: ~~ [ 1669.796863] dracut Warning: Killing all remaining processes dracut Warning: Killing all remaining processes [ 1670.134541] XFS (dm-0): Unmounting Filesystem [ 1670.145779] dracut Warning: Unmounted /oldroot. [ 1670.168229] dracut: Disassembling device-mapper devices kexec: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by kexec) [ 1670.197024] dracut Warning: kexec failed! dracut Warning: kexec failed! Rebooting. [ 1670.211839] kvm: exiting hardware virtualization [ 1671.457978] reboot: Restarting system [ 1671.461965] reboot: machine restart ~~~ What I have done is using 'kexec -l /boot/vmlinuz-xxx --initrd initramfs-xx.img --reuse-cmdline' to load kexec kernel, then execute 'reboot' command to trigger the kexec rebooting. After investigation, the reason is that the OS is fedora33 for CKI testing since in our beaker system, only fedora33 is available to provison. For testing upstream kernel and upstream kexec-tools functionality, QA upgrade kexec-tools/dracut/systemd to fedora34. So after 'reboot' executed, it stops running processes, unmounting. Then it will call kexec utility, and cause the failure of '/lib64/libc.so.6' being not fount. Since systemctl can identify kexec action and will enter into reboot system call, why kexec command need be executed or checked here? Can anyone help have a look at this? Really appreciate if any comment, suggestion, or thing I should try. Thanks Baoquan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions about systemd's "root storage daemon" concept
On Tue, 2021-01-26 at 11:33 +0100, Lennart Poettering wrote:
>
> >
> > [Unit]
> > Description=NVMe Event Monitor for Automatical Subsystem Connection
> > Documentation=man:nvme-monitor(1)
> > DefaultDependencies=false
> > Conflicts=shutdown.target
> > Requires=systemd-udevd-kernel.socket
> > After=systemd-udevd-kernel.socket
>
> Why do you require this?
>
Brain fart on my part. I need to connect to the kernel socket, but that
doesn't require the systemd unit.
> My guess: the socket unit gets shutdown, and since you have Requires=
> on it you thus go away too.
That was it, thanks a lot. So obvious in hindsight :-/
Meanwhile I've looked a bit deeper into the problems accessing "/dev"
that I talked about in my other post. scandir on "/" actually returns
an empty directory after switching root, and any path lookups for
absolute paths fail. I didn't expect that, because I thought systemd
removed the contents of the old root, and stopped on (bind) mounts.
Again, this is systemd-234.
If I chdir("/run") before switching root and chroot("..") afterwards
(*), I'm able to access everything just fine (**). However, if I do
this, I end up in the real root file system, which is what I wanted to
avoid in the first place.
So, I guess I'll have to create bind mounts for /dev, /sys etc. in the
old root, possibly after entering a private mount namespace?
The other option would be to save fd's for the file systems I need to
access and use opendirat() only. Right?
Regards,
Martin
(*) Michal suggested to simply do chroot(".") instead. That might as
well work, I haven't tried it yet.
(**) For notification about switching root, I used epoll(EPOLLPRI) on
/proc/self/mountinfo, because I read that inotify doesn't work on proc.
polling for EPOLLPRI works just fine.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev and btrfs multiple devices
Is it possible for a udev rule to have a timeout? For example: /usr/lib/udev/rules.d/64-btrfs.rules This udev rule will wait indefinitely for a missing device to appear. It'd be better if it gives up at some point and drops to a dracut shell. Is that possible? The only alternative right now is the user has to force power off, and boot with something like rd.break=pre-mount, although I'm not 100% certain that'll break soon enough to avoid the hang. Next, is it possible to enhance udev so that it can report the number of devices expected for a Btrfs file system? This information is currently in the Btrfs superblock found on each device in the num_devices field. https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627 Thanks, -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions about systemd's "root storage daemon" concept
On Mi, 27.01.21 21:51, Martin Wilck (mwi...@suse.com) wrote:
> Meanwhile I've looked a bit deeper into the problems accessing "/dev"
> that I talked about in my other post. scandir on "/" actually returns
> an empty directory after switching root, and any path lookups for
> absolute paths fail. I didn't expect that, because I thought systemd
> removed the contents of the old root, and stopped on (bind) mounts.
> Again, this is systemd-234.
Oh, right we actually use MS_MOVE to move the old /dev to the new
root. If you stay behind in the old you won't see anything anymore — it
got moved away.
Note that the switch root code also attempts to empty out the initrd
after the transition, or what's left of it. You might want to make the
initrd read-only if that is a problem to you.
> If I chdir("/run") before switching root and chroot("..") afterwards
> (*), I'm able to access everything just fine (**). However, if I do
> this, I end up in the real root file system, which is what I wanted to
> avoid in the first place.
Yes, this works the way it works, because /run is moved to the new
root, and thus if you chroot its parent you are in the new root.
> So, I guess I'll have to create bind mounts for /dev, /sys etc. in the
> old root, possibly after entering a private mount namespace?
if you want the initrd environment to fully continue to exist,
consider creating a new mount namespace, bind mount the initrd root
into it recursively to some new dir you created. Then afterwards mark
that mount MS_PRIVATE. then pivot_root()+chroot()+chdir() into your
new old world.
also, make the initrd superblock read-only, if you need its contents.
> The other option would be to save fd's for the file systems I need to
> access and use opendirat() only. Right?
That works too, if you can.
> (**) For notification about switching root, I used epoll(EPOLLPRI) on
> /proc/self/mountinfo, because I read that inotify doesn't work on proc.
> polling for EPOLLPRI works just fine.
Right, sorry. POLLPRI is the right API. inotify is used by cgroupfs
for similar notifications, and I mixed that up. for
/proc/self/mountinfo POLLPRI is the right choice.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved only returns v6 addresses
I was probably too hasty in saying it's the upstream resolver's fault -- it's still systemd-resolved which makes the two A and queries and aggregates their responses. The upstream just happens to choose different nameservers for both, but that's normal operation. Either way, I'd mostly blame O365 for doing weird things, but I don't have enough DNS knowledge to say whether resolved could or should be fixed to deal with it. (Then again it wouldn't be the first time when systemd-resolved is rejecting responses that are otherwise entirely valid...) On Wed, Jan 27, 2021 at 1:27 PM Stefan Tatschner wrote: > On Wed, 2021-01-27 at 13:10 +0200, Mantas Mikulėnas wrote: > > So it is entirely possible that when resolved makes two queries, one > > for A records and another for , it receives conflicting > > information about the target simultaneously being an alias and not > > being an alias (due to your upstream resolver choosing different NS > > each time), and I wouldn't be surprised if that causes resolved to > > reject (or just overlook) some of the returned DNS records. > > Thanks for the analysis! I am wondering what's the issue here: > Is > > * my upstream DNS resolver broken? > * Microsoft's DNS setup broken? > * has systemd-resolved a bug? > > For the first point I will see what I can do. > > Stefan > > -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved only returns v6 addresses
On Wed, 2021-01-27 at 13:10 +0200, Mantas Mikulėnas wrote: > So it is entirely possible that when resolved makes two queries, one > for A records and another for , it receives conflicting > information about the target simultaneously being an alias and not > being an alias (due to your upstream resolver choosing different NS > each time), and I wouldn't be surprised if that causes resolved to > reject (or just overlook) some of the returned DNS records. Thanks for the analysis! I am wondering what's the issue here: Is * my upstream DNS resolver broken? * Microsoft's DNS setup broken? * has systemd-resolved a bug? For the first point I will see what I can do. Stefan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved only returns v6 addresses
I would guess the *upstream *server used by resolved is reacting negatively
to weirdness in O365 authoritative DNS.
* outlook.office365.com is indeed an alias (CNAME) for
outlook.ha.office365.com.
* The domain ha.office365.com has two sets of nameservers: ns{1..4}-
ms-acdc.office.com and tm{1..2}.edgedns-tm.info, which don't seem to agree
with each other.
* According to the first set of nameservers, outlook.ha.office365.com is a
two-layer alias for outlook.ms-acdc.office.com and then
FRA-efz.ms-acdc.office.com.
* But according to the second set of nameservers, outlook.ha.office365.com
is *not* an alias -- those servers perform some sort of CNAME flattening
and directly return A/ records. (Though if you ask them very nicely for
CNAME records, they will actually admit that it's an alias for
fra-mvp.trafficmanager.net... which is different again.)
So it is entirely possible that when resolved makes two queries, one for A
records and another for , it receives conflicting information about the
target simultaneously being an alias and not being an alias (due to your
upstream resolver choosing different NS each time), and I wouldn't be
surprised if that causes resolved to reject (or just overlook) some of the
returned DNS records.
On Wed, Jan 27, 2021 at 12:11 PM Stefan Tatschner
wrote:
> Heya,
>
> I was confronted with a weird problem this morning. On my location
> there is only IPv4 available. My company uses the shiny new Office365
> service for email. This morning I was not able to connect to my email
> account. The reason was systemd-resolved returning only IPv6 addresses
> for the email host:
>
> $ resolvectl query outlook.office365.com
> outlook.office365.com: 2603:1026:c0a:855::2-- link: enp3s0
>2603:1026:c0a:857::2-- link: enp3s0
>2603:1026:c0a:8b7::2-- link: enp3s0
>2603:1026:c0a:850::2-- link: enp3s0
>2603:1026:c0a:852::2-- link: enp3s0
>2603:1026:c0a:851::2-- link: enp3s0
>2603:1026:101:1::2 -- link: enp3s0
>2603:1026:c0a:854::2-- link: enp3s0
>(outlook.ha.office365.com)
>
> -- Information acquired via protocol DNS in 820us.
> -- Data is authenticated: no
>
> The `host` utility instead reports this:
>
> $ host outlook.office365.com
> outlook.office365.com is an alias for outlook.ha.office365.com.
> outlook.ha.office365.com is an alias for outlook.ms-acdc.office.com.
> outlook.ms-acdc.office.com is an alias for AMS-efz.ms-acdc.office.com.
> AMS-efz.ms-acdc.office.com has address 40.101.12.66
> AMS-efz.ms-acdc.office.com has address 52.97.250.210
> AMS-efz.ms-acdc.office.com has address 40.101.121.34
> AMS-efz.ms-acdc.office.com has address 52.97.155.114
> AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:c03:581b::2
> AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:207:177::2
> AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:207:64::2
> AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:206:4::2
>
> The problem was that systemd-resolved only returned ipv6 addresses
> although I have no ipv6 connectivity. Why does this happen? Is there an
> artificial max. addresses limit with the sorting rule ipv6 first in
> systemd-resolved?
>
> I work-arounded it with an entry in /etc/hosts for now.
>
> Stefan
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-resolved only returns v6 addresses
Heya, I was confronted with a weird problem this morning. On my location there is only IPv4 available. My company uses the shiny new Office365 service for email. This morning I was not able to connect to my email account. The reason was systemd-resolved returning only IPv6 addresses for the email host: $ resolvectl query outlook.office365.com outlook.office365.com: 2603:1026:c0a:855::2-- link: enp3s0 2603:1026:c0a:857::2-- link: enp3s0 2603:1026:c0a:8b7::2-- link: enp3s0 2603:1026:c0a:850::2-- link: enp3s0 2603:1026:c0a:852::2-- link: enp3s0 2603:1026:c0a:851::2-- link: enp3s0 2603:1026:101:1::2 -- link: enp3s0 2603:1026:c0a:854::2-- link: enp3s0 (outlook.ha.office365.com) -- Information acquired via protocol DNS in 820us. -- Data is authenticated: no The `host` utility instead reports this: $ host outlook.office365.com outlook.office365.com is an alias for outlook.ha.office365.com. outlook.ha.office365.com is an alias for outlook.ms-acdc.office.com. outlook.ms-acdc.office.com is an alias for AMS-efz.ms-acdc.office.com. AMS-efz.ms-acdc.office.com has address 40.101.12.66 AMS-efz.ms-acdc.office.com has address 52.97.250.210 AMS-efz.ms-acdc.office.com has address 40.101.121.34 AMS-efz.ms-acdc.office.com has address 52.97.155.114 AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:c03:581b::2 AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:207:177::2 AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:207:64::2 AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:206:4::2 The problem was that systemd-resolved only returned ipv6 addresses although I have no ipv6 connectivity. Why does this happen? Is there an artificial max. addresses limit with the sorting rule ipv6 first in systemd-resolved? I work-arounded it with an entry in /etc/hosts for now. Stefan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What exactly is multi-seat? -- questions about logind
On Tue, 26 Jan 2021 11:40:31 -0800 Kian Kasad wrote: > On 21/01/26 02:06PM, Pekka Paalanen wrote: > > On Tue, 26 Jan 2021 01:43:43 -0800 > > Kian Kasad wrote: > > > > > Hi all, > > > > > > After reading the documentation on logind and multi-seat (specifically > > > sd-login(3) and "Multi-Seat on Linux"), I still have some questions. > > > > > > First of all, what exactly is multi-seat? Does it just mean allowing > > > multiple sessions to be running at once, like for multiple users to be > > > logged into the same desktop, even though only one will be in use at a > > > time? > > > > > > Second, why is logind needed for this? Is it not possible to do without > > > logind? I've run Xorg perfectly fine on systems without logind/systemd, > > > so is logind only needed for multiple sessions at once? Is it just to > > > handle the graphical device(s)? > > > > > > Third, is multi-seat possible at all without logind? > > > > > > Most of these questions arose because my main OS, Artix Linux, requires > > > logind (in the form of elogind) for Xorg, but I know that Xorg runs just > > > fine on Alpine Linux, which does not use logind at all. > > > > Hi, > > > > I've heard good words of https://sr.ht/~kennylevinsen/seatd/ although I > > haven't tried to use it myself. One more way to handle multiseat - to > > bind them all. > > I'll write this one down. I'm not looking for alternatives currently, I > was just confused about the purpose. > > > IOW, there are many ways to achieve coordination between multiple > > sessions and one or multiple physical seats, like the Linux virtual > > terminal system that requires root permissions, ioctl and signal magic > > to let things cooperate (and if things do not explicitly cooperate > > correctly, it fails horribly) and does not support multiseat. But if > > you want your program to not need root permissions, have a graceful > > failure if it crashes, not accidentally hijack the seat by mistake, or > > just support multiseat, you kind of need to have a system daemon > > orchestrating things. > > > > Logind is one of those possible system daemons. It tells your program > > when it is active. It grants access to graphics and input devices > > without your program needing root permissions. It also takes graphics > > and input devices away from your program when deactivated, so you can't > > e.g. spy on other programs' input. It takes care of the arcane magic of > > setting up the VT and tty and restoring them. And more. > > > > "Your program" here is Xorg, for instance. Or one of the Wayland > > compositors. > > Thank you! This is exactly the explanation I was looking for. I didn't > get why a daemon was needed if programs (like Xorg) can handle the > devices on their own, but now I see it's to allow multiple Xorg/Wayland > sessions to run, all without needing SUID. I would like to underline the crash handling too. Getting the VT switching dance right is really tricky and depends on *both* programs, the one switching out and the one switching in. If something goes wrong with the VT switching dance, or the program currently active on the default seat crashes, the chances are really high that the user is staring at a frozen screen with his keyboard doing seemingly nothing. The realistic end user options at that point are pressing the power button or logging in via ssh to reboot the machine. If all the tricky things are delegated to a system daemon that is shared by all VT using sessions, getting the VT magic right is both easier and needs to be implemented in just one place. The daemon can also restore the VT in case the program using the VT crashes, or it can switch to the graphical login manager *successfully*. The kernel does not automatically restore the VT so that the user could regain control of his machine. Thanks, pq pgp92sDOzqsXz.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
