Re: [systemd-devel] How can I set timeout limits on root device searching when booting?

[Tomasz Pala]

On Thu, Nov 16, 2023 at 17:51:35 +0800, cunshunxia wrote:

> With 'e' pressed at boot menu, I set the `root=UUID=[wrong UUID]` in boot 
> cmdline. Then I expect that I will run into emergency mode.However, boot log 
> stuck at `Job dev-disk-by\x2duuid--device/start running(5min 10s/ no 
> limit)`.
> I triedDefaultDeviceTimeoutSec=90s, but it doesn't work.

This is your initrd-generator issue, not systemd. E.g. for dracut
there are rd.retry= and rd.timeout= parameters (but there were
some bugs in handling them, I recall fixing this myself in my systems),
defaulting and overriding DefaultDeviceTimeoutSec= to infinity.

> In addition, if I set a wrong uuid of root device in fstab, the system will 
> boot up with read-only filesystem instead of running into emergency mode even 
> if I didn't set 'nofail'.

Again, if you use dracut, it _HEAVILY_ modifies the systemd flow
(including modifying some provided units), especially in regards of
handling initqueue and things like composed block devices activation.

With modified fstab but without regenerating initrd some weird things
are expected to happen, just because your initrd has different (proper?)
view of the system.

In short: your questions are way too general to be answered here.
Unless you use mkosi.

> Is there any way that I can set the timeoutsec or how can I run into 
> emergency mode if root device is set incorrectly?

If you do use dracut, then I warn you it is very peculiar and interferes
with documented expectations. I personally have dozens of changes to
it's scripts just to make it behave correctly.

And so you should ask these questions on your initrd maillist first.

-- 
Tomasz Pala 

Re: [systemd-devel] systemd: questions about dbus dependency service

[Lennart Poettering]

On Di, 28.11.23 22:48, Pintu Agarwal (pintu.p...@gmail.com) wrote:

> Hi,
>
> I need some clarification about systemd services that are dependent on dbus
> service.
>
> We have a service that depends on dbus.service, so our service has to be
> started after dbus.socket and dbus.service.

It's usually a good idea to not wait for dbus.sevice. Waiting for
dbus.socket is sufficient, it makes sure clients can connect to D-Bus
(even if dbus needs to finish starting up to respond to it). This will
increase parallelization during boot.

> But dbus.service comes after local-fs.target and sysinit.target.
> However, our service needs to be started very early on boot-up, maybe
> within local-fs target itself, otherwise it is causing regression in our
> boot KPI.

dbus is not a suitable IPC for early boot services, unless you speak
the dbus protocol directly between client and service, without
involving the broker. But that's messy.

systemd's PID 1 does this (i.e. dbus without a broker), because it
must be accessible early on, but I hate that code, and I'd rather kill
it. In new code that must run in early boot we usually use a different
IPC (varlink), that does not involve any broker, and thus always works.

Lennart

--
Lennart Poettering, Berlin

[systemd-devel] systemd: questions about dbus dependency service

[Pintu Agarwal]

Hi,

I need some clarification about systemd services that are dependent on dbus
service.

We have a service that depends on dbus.service, so our service has to be
started after dbus.socket and dbus.service.
But dbus.service comes after local-fs.target and sysinit.target.
However, our service needs to be started very early on boot-up, maybe
within local-fs target itself, otherwise it is causing regression in our
boot KPI.

How can we solve this issue in the most efficient way?

We are using Linux Kernel 5.15 with arm64 and a high speed quad-core
processor.
Also, the storage type is NAND with limited speed (12.5 MBPS).
The filesystem is UBI + squashfs volumes.

Thanks,
Pintu

[systemd-devel] Systemd-logind StopIdleSessionSec option ignored for multiplexed (control master) ssh sessions?

[Juergen Salk]

Hi,

not sure if this is the right place to ask. If it's not then just
ignore this post.

systemd-logind has recently introduced an option StopIdleSessionSec
which has become available in Rocky 8.7 and onward as well as in Rocky
9.

>From logind.conf(5):

StopIdleSessionSec=
Specifies a timeout in seconds, or a time span value after which
systemd-logind checks the idle state of all sessions. Every session
that is idle for longer then the timeout will be stopped. Defaults
to “infinity” (systemd-logind is not checking the idle state of
sessions). For details about the syntax of time spans, see
systemd.time(7).

This works as expected for regular ssh sessions. However, multiplexed
(control master) ssh sessions that exceed the configured timeout are
*not* being terminated.

Steps to reproduce:

On remote system (as root):
* Configure StopIdleSessionSec=300 in /etc/systemd/logind.conf
* Run systemctl restart systemd-logind.service

On local system: Open control master ssh session to remote system
(initial master connection)
* mkdir -p ~/.ssh/controlmasters
* ssh -M -S ~/.ssh/controlmasters/%r@%h:%p user@remote

On local system (from another terminal): Open subsequent slave ssh
connection to remote system via control socket of the master
connection established above

* ssh -S ~/.ssh/controlmasters/%r@%h:%p user@remote

On remote system (as root): Observe IDLE time of both user sessions
increasing beyond configured timeout of 300 seconds

* watch w

Note that both ssh sessions remain alive when their IDLE time exceeds
the configured timeout of 300 seconds.

I did expect that multiplexed control master ssh sessions that are
idle for longer than StopIdleSessionSec timeout would have been
terminated as well much like regular (non multiplexed) ssh sessions.
But that does not seem to be the case.

Is that expected/intended behaviour? Or a bug? Or am I missing something?

Best regards
Jürgen

Re: [systemd-devel] Does coredumpctl info support minidebuginfo / gnu_debugdata ?

[Etienne Cordonnier]

I found the issue in the yocto based distribution: elfutils / libdw was
compiled without xz support, and was thus unable to extract the
minidebuginfo symbol names.
On Ubuntu / Fedora, I don't know exactly what the issue is.

Etienne

On Tue, Nov 21, 2023 at 11:53 PM Etienne Cordonnier 
wrote:

> Thanks for your reply. I have tested with Fedora 39 and indeed coredumpctl
> info shows function names when a binary provided by a Fedora package
> crashes. However, when I compile a test binary on Fedora, even with debug
> symbols enabled (I tried -g and -ggdb), and I then send kill -SEGV my
> binary, coredumpctl info shows "n/a" instead of the function names of my
> test binary. I also tried to inject minidebuginfo into my binary file with
> the same result.
>
> Do you know what I should do so that coredumpctl info also works with
> binary files I compile? (I added full reproduction steps including the code
> of this test binary to
> https://unix.stackexchange.com/questions/761966/how-to-get-symbolized-call-stacks-with-coredumpctl-info
> ).
>
> Etienne
>
> On Fri, Nov 17, 2023 at 10:03 AM Lennart Poettering <
> lenn...@poettering.net> wrote:
>
>> On Do, 16.11.23 18:37, Etienne Cordonnier (ecordonn...@snap.com) wrote:
>>
>> > Hello,
>> > I am testing a yocto based system, where it seems that "coredumpctl
>> info"
>> > isn't able to use minidebuginfo / gnu_debugdata to extract a symbolized
>> > call-stack. I saw in the code that coredumpctl uses elfutils / libdwfl
>> in
>> > order to extract a call-stack, and as far as I understand libdwfl
>> supports
>> > minidebuginfo since this commit (
>> >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceware.org_git_-3Fp-3Delfutils.git-3Ba-3Dcommit-3Bh-3D5083a70d3b64946fa47ea5766943a15a3ecc6891=DwIBAg=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw=AhkbNonVuMIGRfPx_Qj9TsRih1DULJTKUkSGa66m67E=HRBTXvbd-s9li256Vbbs9zIn33TULJrpWyLD4WV4rEtaedXG1zYgtpXt1vN3eolJ=WjU-C5bJAjCxwlzGD-CwjTBUFN_ZEr7Z1pFNC54_HU0=
>> > ).
>> >
>> > Is there a configuration / build-option / etc. to enable support for
>> > minidebuginfo in coredumpctl? If no is it on the roadmap? The advantage
>> of
>> > minidebuginfo is that it is much smaller than full debug symbols.
>>
>> Fedora has been using minidebuginfo since ~10y or so, and
>> coredumctl/libdwfl has been working fine with it. So it certainly
>> works, it's how this all works on my local machine since forever.
>>
>> Maybe ask your distro for help, it's generally an integration issue of
>> distributions i this doesn't work.
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Berlin
>>
>

Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub

[Luca Boccassi]

On Tue, 28 Nov 2023 at 10:30, VENKAT Nagaraj THOGARU (QUIC)
 wrote:
>
> Hi @systemd-devel@lists.freedesktop.org,
>
>
>
> We have a query on Fixup-support for kernel command line provided from UKI in 
> system-stub.
>
>
>
> Just like we have the Fixup support for DTB provided from UKI in 
> systemd-stub[via EFI_DT_FIXUP_PROTOCOL], do we have any similar fixup support 
> for Kernel command line provided from UKI ? If not, is there any ongoing 
> effort to support this?
>
>
>
> Our requirement is to dynamically append the additional command line 
> parameters to the command line provided from UKI.

Check the addons section:

https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html#Companion%20Files

Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub

[Aleksandar Kostadinov]

How do you create the UKI?

What I do is adding `--cmdline=@/etc/kernel/cmdline` to the ukify command line.

On Tue, Nov 28, 2023 at 11:30 AM VENKAT Nagaraj THOGARU (QUIC)
 wrote:
>
> Hi @systemd-devel@lists.freedesktop.org,
>
>
>
> We have a query on Fixup-support for kernel command line provided from UKI in 
> system-stub.
>
>
>
> Just like we have the Fixup support for DTB provided from UKI in 
> systemd-stub[via EFI_DT_FIXUP_PROTOCOL], do we have any similar fixup support 
> for Kernel command line provided from UKI ? If not, is there any ongoing 
> effort to support this?
>
>
>
> Our requirement is to dynamically append the additional command line 
> parameters to the command line provided from UKI.
>
>
>
> Thanks & Regards,
>
> Venkat Thogaru

[systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub

[VENKAT Nagaraj THOGARU (QUIC)]

Hi 
@systemd-devel@lists.freedesktop.org,

We have a query on Fixup-support for kernel command line provided from UKI in 
system-stub.

Just like we have the Fixup support for DTB provided from UKI in 
systemd-stub[via EFI_DT_FIXUP_PROTOCOL], do we have any similar fixup support 
for Kernel command line provided from UKI ? If not, is there any ongoing effort 
to support this?

Our requirement is to dynamically append the additional command line parameters 
to the command line provided from UKI.

Thanks & Regards,
Venkat Thogaru