Re: [systemd-devel] systemd prerelease 256-rc1

[Dan Nicholson]

On Fri, Apr 26, 2024 at 10:11 AM Adrian Vovk  wrote:
>
> Perhaps Fedora can be adjusted to follow the BLS's recommended mount points?

The problem with all of these type of "we've realized a better way and
the old way is obsolete" is that it's left as someone else's issue to
actually change existing users from the obsolete way. I've written
code to migrate away from some old setup several times at Endless and
it's always scary that you're going to screw a whole class of users
and the only way out of that will be manual intervention. That's
doubly so for something like this where it's touching critical boot
files. Doing something wrong there may make someone's system unusable.

So, while I do agree with the sentiment that /boot/efi is a bad idea
and should not be done anymore, I have a lot of sympathy for Fedora
continuing to use it.

--
Dan Nicholson  |  Endless OS Foundation

Re: [systemd-devel] (solved) Re: How to chain services driven by a timer?

[Dan Nicholson]

On Thu, Apr 18, 2024 at 8:12 AM Brian Reichert  wrote:
>
> On Wed, Apr 17, 2024 at 03:03:16PM -0600, Dan Nicholson wrote:
> > I assume that this is just a script that does some post-processing on
> > log files. In that case, I suggest that you use Type=oneshot with
> > RemainAfterExit=no (the default). Then the service will actually wait
> > until your script completes. Type=simple is expected to be used for a
> > service that doesn't exit under normal conditions.
>
> Thanks for the additional feedback; I don't see the harm in trying.
>
> How, forensically, would I see the difference between 'simple' and
> 'oneshot', in my use case here?

Since you likely don't have any units that depend on your service it
likely doesn't make a big difference. To demonstrate, here's a stupid
service I created:

# cat /etc/systemd/system/foo.service
[Service]
Type=oneshot
ExecStart=/bin/echo foo

With Type=oneshot, the journal output looks like this:

Apr 17 15:02:50 endless systemd[1]: Starting foo.service...
Apr 17 15:02:50 endless echo[5390]: foo
Apr 17 15:02:50 endless systemd[1]: foo.service: Deactivated successfully.
Apr 17 15:02:50 endless systemd[1]: Finished foo.service.

With Type=simple, the journal output looks like this:

Apr 17 14:55:23 endless systemd[1]: Started foo.service.
Apr 17 14:55:23 endless echo[4482]: foo
Apr 17 14:55:23 endless systemd[1]: foo.service: Deactivated successfully.

Notice that in the oneshot case it doesn't reach Finished until after
Deactivated. In the simple case, it immediately goes into Started. If
I had a unit with After=foo.service, it would be started before
foo.service actually did anything if it had Type=simple.

Of more interest to you is logrotate.service, which is Type=oneshot.
If it was Type=simple, your unit would be started before the logrotate
command completed, which is probably not what you want.

Re: [systemd-devel] (solved) Re: How to chain services driven by a timer?

[Dan Nicholson]

On Wed, Apr 17, 2024 at 2:49 PM Brian Reichert  wrote:
>
>   [Service]
>   Type=simple
>
>   ExecStart=/usr/local/sbin/post-logrotate

I assume that this is just a script that does some post-processing on
log files. In that case, I suggest that you use Type=oneshot with
RemainAfterExit=no (the default). Then the service will actually wait
until your script completes. Type=simple is expected to be used for a
service that doesn't exit under normal conditions.

--
Dan

Re: [systemd-devel] How to chain services driven by a timer?

[Dan Nicholson]

On Wed, Apr 10, 2024 at 1:32 PM Brian Reichert  wrote:
>
> On Wed, Apr 10, 2024 at 10:21:32PM +0300, Andrei Borzenkov wrote:
> > On 10.04.2024 22:04, Brian Reichert wrote:
> > >   [Install]
> > >   WantedBy=logrotate.service
> > >
> >
> > Links in [Install] section are created by "systemctl enable".
>
> I could have sworn I did this, but did so (again) just to be sure:
>
>   10-153-68-34:~ # systemctl enable post-logrotate.service
>   Created symlink from
>   /etc/systemd/system/logrotate.service.wants/post-logrotate.service to
>   /etc/systemd/system/post-logrotate.service.
>
>   10-153-68-34:~ # systemctl restart logrotate.timer
>
>   10-153-68-34:~ # systemctl status logrotate.service

Restarting the timer doesn't make the service run immediately. Are you
sure logrotate.service has run again since you made this change? Just
simulate the timer and start logrotate.service again. All the timer
does is activate the service. For testing you don't need to wait for
that to happen.

--
Dan

Re: [systemd-devel] How to chain services driven by a timer?

[Dan Nicholson]

On Wed, Apr 10, 2024 at 1:21 PM Andrei Borzenkov  wrote:
>
> On 10.04.2024 22:04, Brian Reichert wrote:
> > On Wed, Apr 10, 2024 at 09:06:09AM -0600, Dan Nicholson wrote:
> >> On Wed, Apr 10, 2024 at 8:50???AM Brian Reichert  
> >> wrote:
> >>>
> >>> My current service file:
> >>>
> >>>[Unit]
> >>>Description=Activities after logrotation
> >>>
> >>>Requires=logrotate.service
> >>>Wants=logrotate.service
> >>>After=logrotate.service
> >>>
> >>>[Service]
> >>>#Type=oneshot
> >>>Type=simple
> >>>
> >>>ExecStart=/usr/bin/logger 'XXX post log rotation'
> >>>
> >>>[Install]
> >>>WantedBy=timers.target
> >>
> >> The critical part is WantedBy=logrotate.service. In other words, when
> >> logrotate.service is activated, you want it to also activate your
> >> service. Then After=logrotate.service above will ensure your service
> >> starts after it completes. The Requires and Wants above are
> >> conflicting. You only want one or the other, but I'd probably put it
> >> as Requires=logrotate.service. That way your unit won't start if
> >> logrotate.service fails.
> >
> > Thanks to you and  for your advice. I think I've
> > correctly incorporated your suggestions, but I still can't seem to get
> > things to work.
> >
> > Perhaps my method of testing is flawed.
> >
> > My current service:
> >
> >[Unit]
> >Description=Activities after logrotation
> >
> >Requires=logrotate.service
> >
> >[Service]
> >Type=simple
> >
> >ExecStart=/usr/bin/logger 'XXX post log rotation'
> >
> >[Install]
> >WantedBy=logrotate.service
> >
>
> Links in [Install] section are created by "systemctl enable".

Just to be complete, your unit won't be triggered until you see it in
"systemctl show -p Wants logrotate.service". With
WantedBy=logrotate.service, you'll also find a symlink to your service
in /etc/systemd/system/logrotate.service.wants/ once it's enabled.

Re: [systemd-devel] How to chain services driven by a timer?

[Dan Nicholson]

On Wed, Apr 10, 2024 at 8:50 AM Brian Reichert  wrote:
>
> My current service file:
>
>   [Unit]
>   Description=Activities after logrotation
>
>   Requires=logrotate.service
>   Wants=logrotate.service
>   After=logrotate.service
>
>   [Service]
>   #Type=oneshot
>   Type=simple
>
>   ExecStart=/usr/bin/logger 'XXX post log rotation'
>
>   [Install]
>   WantedBy=timers.target

The critical part is WantedBy=logrotate.service. In other words, when
logrotate.service is activated, you want it to also activate your
service. Then After=logrotate.service above will ensure your service
starts after it completes. The Requires and Wants above are
conflicting. You only want one or the other, but I'd probably put it
as Requires=logrotate.service. That way your unit won't start if
logrotate.service fails.

Re: Mask Unit files over DBus doesn't work?

[Dan Nicholson]

On Thu, Dec 14, 2023 at 8:35 AM Dan Nicholson  wrote:
>
> On Thu, Dec 14, 2023 at 3:57 AM Gyorgy Szekely  wrote:
> >
> > This is what happens when I use DBus: (with busctl for the sake of this 
> > discussion)
> >
> > $ busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 
> > org.freedesktop.systemd1.Manager MaskUnitFiles asbb 1 
> > serial-getty@ttymxc0.service false false
> > a(sss) 1 "symlink" "/etc/systemd/system/serial-getty@ttymxc0.service" 
> > "/dev/null"
> >
> > $ systemctl status serial-getty@ttymxc0.service
> > ● serial-getty@ttymxc0.service - Serial Getty on ttymxc0
> >  Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; 
> > enabled; vendor preset: disabled)
> >  Active: inactive (dead)
> >
> > The reported symlink is there in both cases, but while in the 1st case the 
> > service is indeed masked and cannot be started, in the 2nd case no such 
> > thing is reported and the service can be started.
>
> It seems like the daemon hasn't been told to reload state based on the
> filesystem state. I wonder if it starts working if you run
> daemon-reload (or the DBus equivalent) afterwards.

It would also be interesting to know if systemd thinks the unit needs
a daemon reload. I.e., systemctl show -p NeedDaemonReload
serial-getty@ttymxc0.service.

Re: Mask Unit files over DBus doesn't work?

[Dan Nicholson]

On Thu, Dec 14, 2023 at 3:57 AM Gyorgy Szekely  wrote:
>
> This is what happens when I use DBus: (with busctl for the sake of this 
> discussion)
>
> $ busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 
> org.freedesktop.systemd1.Manager MaskUnitFiles asbb 1 
> serial-getty@ttymxc0.service false false
> a(sss) 1 "symlink" "/etc/systemd/system/serial-getty@ttymxc0.service" 
> "/dev/null"
>
> $ systemctl status serial-getty@ttymxc0.service
> ● serial-getty@ttymxc0.service - Serial Getty on ttymxc0
>  Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; 
> enabled; vendor preset: disabled)
>  Active: inactive (dead)
>
> The reported symlink is there in both cases, but while in the 1st case the 
> service is indeed masked and cannot be started, in the 2nd case no such thing 
> is reported and the service can be started.

It seems like the daemon hasn't been told to reload state based on the
filesystem state. I wonder if it starts working if you run
daemon-reload (or the DBus equivalent) afterwards.

--
Dan

Re: [systemd-devel] idle home NFS gets unmounted although user is still logged in

[Dan Nicholson]

On Tue, May 16, 2023 at 5:54 AM Frank Steiner
 wrote:
>
> I changed the idle-time to 1 minute for debugging. What I can see
> 20 seconds before the umount happens:
>
> bioserver3 /etc/systemd# lsof /home/b
> COMMAND PIDUSER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
> jupyterhu 14150 biouser  cwdDIR  0,107 4096 134348997 /home/b/biouser 
> (:/b)
> jupyterhu 14150 biouser   10u   REG  0,10716384 151474490 
> /home/b/biouser/.local/share/jupyter/nbsignatures.db (:/b)
> python3.1 14195 biouser  cwdDIR  0,107 4096 134348997 /home/b/biouser 
> (:/b)
> python3.1 14195 biouser   45u   REG  0,10728672 134367744 
> /home/b/biouser/.ipython/profile_default/history.sqlite (:/b)
> python3.1 14195 biouser   47u   REG  0,10728672 134367744 
> /home/b/biouser/.ipython/profile_default/history.sqlite (:/b)
> R 14198 biouser  cwdDIR  0,107 4096 134348997 /home/b/biouser 
> (:/b)
> R 14198 biouser3u   REG  0,107   18 134945871 
> /home/b/biouser/tmp/.nfs080b1c4f00c2 (:/b)
>
> So, that's very far from the nfs mount being idle, but 20 seconds later
> the mount gets removed.
>
> When I chdir (as root) into /home/b, the mount stays and the user's
> jupyterhub session keeps running (tested for 30 minutes). When I chdir
> away from /home/b, the mount is removed a minute later.

I strongly suspect you're dealing with
https://bugzilla.redhat.com/show_bug.cgi?id=2056090. I.e., autofs
doesn't handle mount namespaces. Since systemd uses lots of mount
namespaces, the idle timeout essentially doesn't work. The only
workaround I'm aware of is to run something in the root namespace that
keeps the mount active. Having an active process with its current
directory in the mount would do it.

--
Dan

Re: [systemd-devel] systemd enables custom service units on firstboot

[Dan Nicholson]

We just run preset-all near the end of our image (really ostree) build
after all packages have been installed and nearly all customizations have
been applied. Then you're recording the state of the enabled and disabled
units in the image.

--
Dan Nicholson  |  Endless OS Foundation


On Mon, May 1, 2023 at 2:45 PM Martin Petzold 
wrote:

> Using the presets is a little tricky. Because during debootstrap Debian
> installation a machine-id is created and the 90-systemd.preset seems to be
> applied. After this initial Debian package installation there may be Debian
> packages installed via apt which enabled service units without using
> presets (e.g. sshd). Using a 99-disable.preset (disable *) can have
> unintended side-effects, especially if presets are applied again (by
> 'systemctl preset-all' or again during boot). In my setup it seems to be
> safer NOT to use the 99-disable.preset, rather disable all own and unused
> service units within own preset.
>
> However, removing the machine-id from my image does result in a new
> machine-id creation on next boot, BUT does not apply the presets again.
>
> Is it also possible to reset the boot preset status, so that it is applied
> again on next boot? Or do I need to run 'systemctl preset-all'?
>
> Thanks,
>
> Martin
> Am 29.04.23 um 18:20 schrieb Dan Nicholson:
>
> For Endless OS we went the opposite way under the idea that we don't want
> to have to go add an entry for every service that might get added when the
> packages change. Basically we work under the assumption that a package
> included in the OS that provides a service usually should be enabled. So,
> we disable selected units in our preset and let everything else get
> enabled.
>
> https://github.com/endlessm/eos-boot-helper/blob/master/50-eos.preset
>
> On Sat, Apr 29, 2023, 9:55 AM Daan De Meyer 
> wrote:
>
>> Disabling manually will still get overridden by preset on first boot.
>> Debian does not ship 99-disable.preset because deb-systemd-helper relies on
>> systemctl preset to enable services on install. Shipping that file would
>> break backwards compat because no services would be enabled anymore.
>>
>> If I were you I would ship 99-disable.preset and add 85-mydevice.preset
>> enabling only the services you want to be enabled.
>>
>> Cheers,
>>
>> Daan
>>
>> On Sat, 29 Apr 2023, 17:47 Martin Petzold, 
>> wrote:
>>
>>> Dear Daan,
>>> Am 29.04.23 um 17:43 schrieb Daan De Meyer:
>>>
>>> Systemd does a preset on first boot when there's no machine ID yet. If
>>> no preset from a preset file applies, the default is to enable it. Since
>>> debian does not ship a 99-disable.preset with disable * in it, all services
>>> are enabled on firstboot on Debian.
>>>
>>> What would you then suggest:
>>>
>>> a. Disable every single service unit after copy to the
>>> /lib/systemd/system location manually?
>>> b. Add a 99-disable.preset file with 'disable *'? (I wonder why Debian
>>> does not have it and if it then may brake something)
>>>
>>> Thanks,
>>>
>>> Martin
>>>
>>>
>>> On Sat, 29 Apr 2023, 17:27 Martin Petzold, 
>>> wrote:
>>>
>>>> Dear Paul,
>>>>
>>>> Am 29.04.23 um 17:13 schrieb Paul Menzel:
>>>> > Dear Martin,
>>>> >
>>>> >
>>>> > Am 29.04.23 um 16:12 schrieb Martin Petzold:
>>>> >
>>>> >> we are building our OS with debootstrap (Debian bullseye). Our image
>>>> >> shall be flashed on embedded devices. In order to get a unique
>>>> >> machine-id we removed '/etc/machine-id' as instructed in [1] and
>>>> also
>>>> >> removed '/var/lib/dbus/machine-id' as instructed in [2]) from the
>>>> >> golden image.
>>>> >>
>>>> >> After we flash the image and boot it, new machine-ids are created
>>>> and
>>>> >> identical.
>>>> >>
>>>> >> However, now we realized that some of our systemd service units
>>>> added
>>>> >> to '/lib/systemd/system' are enabled and starting on boot. We did
>>>> not
>>>> >> enable them, we just copied them to that location at the end of our
>>>> >> rootfs build. They are just there to be used in some special test
>>>> cases.
>>>> >>
>>>> >> We already checked '/lib/systemd/system-preset/*'. But there is only
>>>> >> a single file '90-systemd.preset

Re: [systemd-devel] systemd enables custom service units on firstboot

[Dan Nicholson]

For Endless OS we went the opposite way under the idea that we don't want
to have to go add an entry for every service that might get added when the
packages change. Basically we work under the assumption that a package
included in the OS that provides a service usually should be enabled. So,
we disable selected units in our preset and let everything else get enabled.

https://github.com/endlessm/eos-boot-helper/blob/master/50-eos.preset

On Sat, Apr 29, 2023, 9:55 AM Daan De Meyer 
wrote:

> Disabling manually will still get overridden by preset on first boot.
> Debian does not ship 99-disable.preset because deb-systemd-helper relies on
> systemctl preset to enable services on install. Shipping that file would
> break backwards compat because no services would be enabled anymore.
>
> If I were you I would ship 99-disable.preset and add 85-mydevice.preset
> enabling only the services you want to be enabled.
>
> Cheers,
>
> Daan
>
> On Sat, 29 Apr 2023, 17:47 Martin Petzold, 
> wrote:
>
>> Dear Daan,
>> Am 29.04.23 um 17:43 schrieb Daan De Meyer:
>>
>> Systemd does a preset on first boot when there's no machine ID yet. If no
>> preset from a preset file applies, the default is to enable it. Since
>> debian does not ship a 99-disable.preset with disable * in it, all services
>> are enabled on firstboot on Debian.
>>
>> What would you then suggest:
>>
>> a. Disable every single service unit after copy to the
>> /lib/systemd/system location manually?
>> b. Add a 99-disable.preset file with 'disable *'? (I wonder why Debian
>> does not have it and if it then may brake something)
>>
>> Thanks,
>>
>> Martin
>>
>>
>> On Sat, 29 Apr 2023, 17:27 Martin Petzold, 
>> wrote:
>>
>>> Dear Paul,
>>>
>>> Am 29.04.23 um 17:13 schrieb Paul Menzel:
>>> > Dear Martin,
>>> >
>>> >
>>> > Am 29.04.23 um 16:12 schrieb Martin Petzold:
>>> >
>>> >> we are building our OS with debootstrap (Debian bullseye). Our image
>>> >> shall be flashed on embedded devices. In order to get a unique
>>> >> machine-id we removed '/etc/machine-id' as instructed in [1] and also
>>> >> removed '/var/lib/dbus/machine-id' as instructed in [2]) from the
>>> >> golden image.
>>> >>
>>> >> After we flash the image and boot it, new machine-ids are created and
>>> >> identical.
>>> >>
>>> >> However, now we realized that some of our systemd service units added
>>> >> to '/lib/systemd/system' are enabled and starting on boot. We did not
>>> >> enable them, we just copied them to that location at the end of our
>>> >> rootfs build. They are just there to be used in some special test
>>> cases.
>>> >>
>>> >> We already checked '/lib/systemd/system-preset/*'. But there is only
>>> >> a single file '90-systemd.preset' and there is no rule which matches
>>> >> our service units.
>>> >>
>>> >> 1. Why are our service units placed in '/lib/systemd/system' enabled?
>>> > Sorry, you provide not enough information.
>>> >
>>> > Please provide an example `systemctl status X` and `systemctl cat X`
>>> > for service X, that is started but does not. Does that happen with all
>>> > services you add?
>>> =
>>>
>>> tavla@tavla:~$ sudo systemctl status tavla-test
>>>
>>> × tavla-test.service - TAVLA Platform OS Tester Service
>>>   Loaded: loaded (/lib/systemd/system/tavla-test.service; enabled;
>>> preset: enabled)
>>>   Active: failed (Result: signal) since Sat 2023-04-29 15:52:12
>>> CEST; 17min ago
>>>  Process: 388 ExecStart=/opt/tavla/bin/test (code=killed, signal=HUP)
>>> Main PID: 388 (code=killed, signal=HUP)
>>>  CPU: 118ms
>>>
>>> Apr 29 15:52:12 tavla systemd[1]: Starting tavla-test.service - TAVLA
>>> Platform OS Tester Service...
>>> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Main process
>>> exited, code=killed, status=1/HUP
>>> Apr 29 15:52:12 tavla systemd[1]: tavla-test.service: Failed with result
>>> 'signal'.
>>> Apr 29 15:52:12 tavla systemd[1]: Failed to start tavla-test.service -
>>> TAVLA Platform OS Tester Service.
>>>
>>> =
>>>
>>> tavla-test.service is 'enabled' (and started), but I never enabled it.
>>> It was enabled after I removed machine-id and did a reboot. Before that,
>>> it was disabled. The service unit
>>> ('/lib/systemd/system/tavla-test.service') was copied to this location
>>> during image build after debootstrap and apt installation of systemd.
>>>
>>> Here is the only preset ('90-systemd.preset'):
>>>
>>> =
>>>
>>> enable remote-fs.target
>>> enable remote-cryptsetup.target
>>> enable machines.target
>>>
>>> enable getty@.service
>>> enable systemd-timesyncd.service
>>> enable systemd-networkd.service
>>> enable systemd-network-generator.service
>>> enable systemd-resolved.service
>>> enable systemd-homed.service
>>> enable systemd-userdbd.socket
>>> enable systemd-pstore.service
>>> enable systemd-boot-update.service
>>>
>>> disable console-getty.service
>>> disable 

Re: [systemd-devel] systemd-devel Digest, Vol 155, Issue 13

[Dan Nicholson]

On Mon, Mar 20, 2023 at 11:27 AM Lal, Arun  wrote:
>
> Hi,
>
> Can someone help me in finding the right way to use polkit.
> So that dbus method calls can be made by non-root user to an dbus-interface 
> of an application running in root.
>
> Right now method call fail in "check access" function.

See 
https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html#polkit-rules-examples.
However, if you're using Debian see
https://www.freedesktop.org/software/polkit/docs/0.105/pklocalauthority.8.html.

--
Dan

Re: [systemd-devel] Execute a script/program at the start of a graphical session

[Dan Nicholson]

On Thu, May 12, 2022 at 5:31 AM Gerion Entrup
 wrote:
>
> The broader question is: Is there a way to start a script at the
> beginning of a graphical session (but after X or the Wayland compositor
> have started) which is independent of the login manager or desktop
> environment?

You can use an XDG autostart desktop file with NoDisplay=true -
https://specifications.freedesktop.org/autostart-spec/0.5/ar01s02.html.
But with a systemd user session it's often just converted into a unit
anyways.

--
Dan

Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Dan Nicholson]

On Wed, Apr 27, 2022 at 9:10 AM Neal Gompa  wrote:
>
> Note that it means Fedora CI, pull requests from contributors, and
> releng auto-rebuilds will no longer work. Maintainers basically
> sign-on to do all of those things manually and have to be responsive
> for doing it. You will get FTBFS tickets every cycle because of it,
> for example.

Asking systemd folks to change their development process because of
limitations in Fedora/Koji seems like a big ask, don't you think?
Having implemented UEFI secure boot signing for Endless, I can concur
it is a PITA. However, there are certainly ways to make it work that
have no effect on upstream. Our Endless system is pretty hacky, but
Debian's is pretty well thought out. What both have in common is that
the signer generates a separate package so that the normal build flow
isn't affected. In the case of systemd, there would be both an
unsigned and signed version of the sd-boot EFI program in separate
packages.

I'm sure it would require work to fix, but this seems like more of a
Koji problem than a systemd problem. I also feel like Lennart's
suggestion that sd-boot get split out as a separate source package but
using the same tarball is completely reasonable if your signing system
is too onerous to use.

--
Dan

Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Dan Nicholson]

On Wed, Apr 27, 2022 at 9:01 AM Michael Biebl  wrote:
>
> Slightly related
> https://salsa.debian.org/systemd-team/systemd/-/merge_requests/138
> [sd-boot split]
> https://salsa.debian.org/systemd-team/systemd/-/merge_requests/132
> [Draft: Prepare for EFI signing]

Oh, nice. We've been signing sd-boot in Endless for a couple years now
with our systemd package based on Debian's. Currently the entire
systemd package is sent through the signing flow just for sd-boot.
When sd-boot is a separate package that can be much simpler with the
normal non-sd-boot targets unaffected.

--
Dan

Re: [systemd-devel] Waiting for (transient) hostname configuration

[Dan Nicholson]

On Wed, Apr 20, 2022 at 2:10 PM Alessio Igor Bogani
 wrote:
>
> Hi Lennart,
>
> On Wed, 20 Apr 2022 at 16:47, Lennart Poettering  
> wrote:
> [...]
> > > I use systemd-networkd and systemd-networkd-wait-online is enabled but
> > > unfortunately it doesn't work anyway.
>
> If you don't mind I show you one of my Unit files:
>
> [Unit]
> Description=Tango Starter service
> Requires=network-online.target nss-lookup.target
> Wants=tangorc.service
> After=network-online.target tangorc.service nss-lookup.target
> Conflicts=shutdown.target
> RequiresMountsFor=/runtime
>
> [Service]
> User=controls
> Group=controls
> # ExecStart=/usr/bin/Starter %H
> ExecStart=/bin/sh -c 'sleep 1; exec /usr/bin/Starter `hostname`'
> KillMode=process
> RestartSec=5s
> Restart=on-failure
>
> [Install]
> WantedBy=multi-user.target

I think the part you may have missed is you need something to run
systemctl daemon-reload after networking is available but before your
units are started. There are a couple ways to do that. One is to add
your own unit that has After=network-online.target and simply has
ExecStart=/bin/systemctl daemon-reload. Then you're other real units
like the one above would have Requires and After on the unit that runs
daemon-reload.

Another way suggested by Sietse would be to add a drop-in for
systemd-networkd-wait-online.service that adds
ExecStartPost=/bin/systemctl daemon-reload. Since that's already going
to run before network-online.target, none of your other units have to
change.

Re: [systemd-devel] sd_bus_process() + sd_bus_wait() is it not suitable for application?

[Dan Nicholson]

Aren't your leaking reply there? You don't seem to be unreffing it and it's
not being returned to someone else to do it either.

On Sat, Jan 22, 2022, 3:12 AM www  wrote:

> +Add the implementation code of the method.
>
> *static int method_load_info(sd_bus_message *message, void *userdata,
> sd_bus_err *error)*
> *{*
> *sd_bus_message *reply = NULL;*
> *..*
> *r = sd_bus_message_read(message. "r", );*
> *..*
> *r= sd_bus_message_new_return(message, ); //*
> *..*
> *r = sd_bus_message_open_container(reply, 'a', "()");*
> **
> *r = sd_bus_message_append(reply, "()", xx, xx ,xx ,xx);*
> *..*
> *r = sd_bus_message_close_container(reply);*
> *...*
>
> *return sd_bus_send(NULL, reply, NULL);*
> *}*
>
>
> Thanks,
> Byron
>
> At 2022-01-22 14:16:13, "www"  wrote:
>
> Dear all,
>
> When using *sd_bus_process() + sd_bus_wait() * to implement the
> application(Service), call the methods function on the service can obtain
> the correct information.  Run a certain number of times will lead to
> insufficient memory and memleak does occur.
>
> It should not be a problem with the DBUS method, because a single call
> does not increase memory, it needs to call the method *65 ~ 70 *times,
> and you will see the memory increase. After stopping the call, the memory
> will not decrease. It seems that it has nothing to do with the time
> interval when the method is called.
>
> code implementation：
> *int main()*
> *{*
> *..*
> *r = sd_bus_open_system();*
> *...*
> *r = sd_bus_add_object_vtable(bus, ..);*
> *..*
> *r= sd_bus_request_name(bus, "xxx.xx.xx.xxx");*
> *..*
>
> *for( ; ; )*
> *{*
> *r = sd_bus_process(bus, NULL);*
> *...*
> *r = sd_bus_wait(bus, -1);*
> *..*
> *}*
> *sd_bus_slot_unref(slot);*
> *sd_bus_unref(bus);*
> *}*
>
> thanks,
> Byron
>
>
>
>
>
>

Re: [systemd-devel] Mobile broadband modems support in systemd-networkd

[Dan Nicholson]

On Mon, Aug 23, 2021 at 2:41 PM Bruce A. Johnson
 wrote:
> I suspect that ModemManager needs to be changed to inform systemd-networkd.

Nothing needs to change in ModemManager. networkd would need to be
changed to integrate with ModemManager over D-Bus. The communication
would go in 2 directions - networkd telling ModemManager to change
states and networkd listening for state changes from ModemManager.
FWIW, the NetworkManager code to integrate with ModemManager is in
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/tree/main/src/core/devices/wwan.
It uses libmm-glib, but that's really just a convenience wrapper
around the D-Bus interfaces.

Dan

Re: [systemd-devel] syscvall-filters killing CGI after update to Fedora 33

[Dan Nicholson]

On Mon, Apr 19, 2021 at 10:24 AM Reindl Harald  wrote:
>
> after a long time using this SystemCallFilter perl-cgi with Fedora 33
> get killed - anyone an idea what changed that's obviously covered by the
> second line
>
> SystemCallFilter=@system-service @network-io @privileged
> SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount
> @obsolete @raw-io @reboot @resources @swap
>
> either the blacklist of the new systemd version convers more than before
> or something changed in the perl stack
>
> -
>
> Process 7723 (mailgraph.cgi) of user 48 dumped core.#012#012Stack trace
> of thread 7723:#012#0  0x7f14be8e955d syscall (libc.so.6 +
> 0xfc55d)#012#1  0x7f14be2959d2 g_thread_pool_new (libglib-2.0.so.0 +
> 0x839d2)#012#2  0x7f14bde5ae5c g_task_get_type_once (libgio-2.0.so.0
> + 0xabe5c)#012#3  0x7f14bde5af85 g_task_get_type (libgio-2.0.so.0 +
> 0xabf85)#012#4  0x7f14bde5b09d g_task_new (libgio-2.0.so.0 +
> 0xac09d)#012#5  0x7f14bdfd2c4e pango_fc_font_map_init
> (libpangoft2-1.0.so.0 + 0xac4e)#012#6  0x7f14be37db97

I think the following change in pango is now making it spawn a thread
where it didn't before.

https://gitlab.gnome.org/GNOME/pango/-/commit/e4e7a76a173620394a4bff9738d9b156c40e8c45

--
Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Minimize systemd for kdump's initramfs

[Dan Nicholson]

On Wed, Jan 1, 2020 at 9:21 AM Kairui Song  wrote:
>
> Hi all,
>
> I noticed there is a Fedora minimization project which seems could be
> a bit related to the thing I'm trying to do, and this could be a
> generic topic.
>
> What I'm trying to do is reduce the initramfs size used for kdump.
> Kdump loads a crash kernel and kdump initramfs image in a prereseved
> memory region, which get booted when current kernel crashed and
> perform crash dump. The prereserved memory is limited, so initramfs
> shouldn't go too big.
>
> Kdump in Fedora use Dracut to create bootable initramfs, just hook the
> final step to do kdump things instead of switch root. And to reduce
> the size only the binaries and drivers required to boot and perform
> kdump on current machine is installed. So long it have been working
> very well.
>
> But problem is Dracut works by reusing binaries and libraries from the
> currently running system, and many userspace binaries and libraries is
> keep growing and using more space. So the initramfs is also growing.

Can you arrange to run a different dracut command line for generating
the kdump initramfs? If so, then you can just leave out systemd (and
anything else you want) and add a dracut module that does the kdump
loading. Assuming you have a dracut module named kdump, this would
work:

dracut -o systemd -a kdump kdump.img

Or, if you know specifically which modules you want, you can specify them:

dracut -m "kdump some-other-required-module" kdump.img

Or, you could even supply a custom config file and/or directory on disk:

dracut -c /etc/dracut-kdump.conf --confdir /etc/dracut-kdump.conf.d kdump.img

See dracut(8) for many other options. Considering how narrow the use
case for this initramfs is intended to be, I really doubt you want to
take the generic initramfs and just tack on kdump. I think it would be
better to invoke dracut in a way to produce a specialized initramfs
for this purpose. I don't know how that would work in the fedora
packaging and booting land, but IMO that's what the focus should be -
figure out how to invoke dracut to make a minimal initramfs for
running kdump and then figure out how to support that in fedora.

--
Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Thoughts about storing unit/job statistics

[Dan Nicholson]

On Thu, Nov 28, 2019 at 1:32 AM Lennart Poettering
 wrote:
>
> Ideally we wouldn't even come up with our own file format for these
> ring buffers, and just use what is already established, but afaiu
> there's no established standard for time series ring buffer files so
> far, hence I figure we need to come up with our own. I mean, after all
> the intention is not to process this data ourselves but have other
> tools do that.

A classic and still widely used format for this is an RRD file as
popularized by RRDtool. You can see some description at
https://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html and
https://en.wikipedia.org/wiki/RRDtool.

Another one we came across at Endless was a whisper database used by
Graphite. It's a text format similar to RRD. See
https://graphite.readthedocs.io/en/latest/whisper.html.

A more recent and popular tool is prometheus. See
https://prometheus.io/docs/prometheus/latest/storage/ for how it
stores data on disk. It appears that the actual on disk format is
documented at 
https://github.com/prometheus/prometheus/blob/master/tsdb/docs/format/README.md.
Alternatively, you could potentially setup systemd as a prometheus
exporter (https://prometheus.io/docs/instrumenting/exporters/) that
prometheus pulls from. That obviously makes systemd metrics not as
usable out of the box and more suited to server usage than desktop
usage.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using systemd.offline-updates from an ostree based system

[Dan Nicholson]

On Fri, Apr 26, 2019 at 3:54 AM Lennart Poettering
 wrote:
>
> On Do, 25.04.19 17:10, Richard Hughes (hughsi...@gmail.com) wrote:
>
> >  Hi all,
> >
> > I use the offline updates feature
> > https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html
> > in fwupd to install some kinds of firmware. I've just found out this
> > doesn't work on Fedora SilverBlue as / is immutable and of course
> > creating the /system-update symlink fails.
>
> Hmm, the assumption was always that / was mutable if offline updates
> are used to update /...
>
> I have the suspicion the ostree folks might have some specific ideas
> on how to do this in their environment?

In a bootable ostree you're never updating /. You're updating a new
deployment in /ostree/deploy//deploy/. In a standard
update path you'd make modifications in there, but this is different
since you're not updating the OS.

> > I'm using the offline update mode rather than updating "live" as I'm
> > updating the keyboard controller itself, which means the keyboard (and
> > power button!) is disabled and various things like ACPI battery
> > reporting also get upset for the 30 seconds of flashing. I'm stuck for
> > ideas. I suppose I could write a new boot entry (BLS?) that has a new
> > kernel command line argument set to go into system-update.target (and
> > patch src/system-update-generator/system-update-generator.c) although
> > I don't think BLS has the concept of a "oneshot" entry that would
> > delete after running it once.
>
> What precisely is writable on those systems? Is /etc? You need
> something that is accessible during early boot (i.e. right after the
> transition from the initrd to the host OS). This excludes /var in the
> general case, but includes /etc, / or /usr...

/etc and /var are the typical places to put writable data (/usr is
also mounted RO). Early in boot a writable /etc is available.
Basically, there are 2 parts to the ostree boot process.

In the initrd, ostree-prepare-root runs late to take the deployment in
/sysroot/ostree//deploy/ and remounts things so that
it sits at /sysroot instead. It does most of the mounting to prepare
the system including making /usr a read only mount. It will mount
/sysroot/ostree//var (a /var shared between deployments of the
same OS) at /var in some scenarios but not all. It also handles bind
mounting /boot to the correct location if it's on the same filesystem
as the deployments. See the following:

https://github.com/ostreedev/ostree/blob/master/src/switchroot/ostree-prepare-root.c
https://github.com/ostreedev/ostree/blob/master/src/boot/ostree-prepare-root.service

Note that ostree makes a separate reference to "/sysroot". At runtime,
the actual root of the filesystem is mounted at /sysroot and there are
a couple symlinks into it to make things work. For instance, /ostree
is a symlink to /sysroot/ostree. Creating new deployments on the live
system wouldn't work if /ostree was actually a directory inside the
currently running deployment.

After pivoting to the new root, there's a generator that runs that
ensures /var is mounted as described above. It's in 2 pieces at:

https://github.com/ostreedev/ostree/blob/master/src/switchroot/ostree-system-generator.c
https://github.com/ostreedev/ostree/blob/master/src/libostree/ostree-impl-system-generator.c

> Note that the boot loader spec is not universally adopted. Fedora uses
> something they call the boot loader spec, but it#s very different from
> what bootctl, logind, systemd's shutdown code and sd-boot understand
> and not compatible. They really should stop using the name in its
> current state, it's just confusing.
>
> The boot loader interface systemd undestands actually has support for
> oneshot boots, see:
>
> https://systemd.io/BOOT_LOADER_INTERFACE.html, see the
> LoaderEntryOneShot EFI variable.
>
> Given that GRUB doesn't support that and maybe you don't want to bind
> yourself to EFI variables it's not the best approach anyway?
>
> I mean, you could store the flag at the following places at least:
>
>1. EFI variables
>2. ESP
>3. /boot if different from ESP
>4. /
>5. /etc

I think /etc is the only guaranteed to be writable location that's
generic to all ostree systems. If possible, I'd get systemd to honor
/etc/system-update.

--
Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] exim4 only queues mails sent by systemd service

[Dan Nicholson]

On Mon, Sep 24, 2018 at 1:38 PM Lennart Poettering
 wrote:
>
> On Mo, 24.09.18 20:34, Kamil Jońca (kjo...@o2.pl) wrote:
> > > This didn't work well enough IIRC, but if it did, then it'd provide 
> > > almost postfix-like architecture.
> > >
> > > Or just making 'sendmail' send a SIGALRM to the main daemon would do the 
> > > job perfectly well, I suspect...
> >
> > But I still does not know, where is the problem, why exim doest not play
> > well with systemd ...
>
> Here's an educated guess: your script terminates, so that that systemd
> decides your service has ended. In such a case it kills any left-over
> processes of the service, and this will include the exim process
> forked off into the bg, because it is attributed to your script's
> context.
>
> Thus the exim queue runner might be forked off, but it wil be
> immediately terminated by systemd again...

This is exactly what exim does when run via sendmail (which mail and
mutt likely use behind the scenes). I had a very similar setup to the
OP using exim on one of our servers and was perplexed why the queue
wasn't being flushed immediately. Here's what I wrote our git history:

I had naively thought that sendmail used SMTP to send a mail to the
local MTA. That's actually not the case for either exim or postfix,
which use internal procedures to queue and send the mail. Normally
that's not a problem except when sendmail is run by a systemd service.
Then the way that processes are spawned to queue and send the mail have
to match the service type. In the case of exim, the sending process
actually forks from sendmail, which systemd kills before it can run if
the service type is set to oneshot.

I ended up just writing python script to send the mail via SMTP to the
localhost.

--
Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timezone aware timers

[Dan Nicholson]

On Tue, Feb 20, 2018 at 11:04 AM, Lennart Poettering
 wrote:
> On Di, 20.02.18 11:14, Iain Lane (i...@orangesquash.org.uk) wrote:
>
>> I also don't know how we'd get notified of the timezone changing.
>> inotify on /etc/timezone?
>
> /etc/timezone is usually a symlink, and iirc we can't install inotify
> on a symlink (only in the containing dir, but that means a lot more
> wakeups).

Drive-by comment: the file you want to watch is /etc/localtime. That's
what glibc reads to get the default timezone in preference to the $TZ
environment variable -
http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html.
/etc/timezone is just a Debian thing to keep the name of the timezone.
I'm not sure what uses that file.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering (apt) timer services to not run at the same time

[Dan Nicholson]

On Apr 27, 2017 4:31 PM, "Julian Andres Klode"  wrote:

Hi systemd folks,

(service and timer files being discussed at the bottom)

we are currently reworking the way automatic updates and upgrades work
on Ubuntu and Debian systems. We basically have two persistent timers
with associated services:

1. apt-daily - Downloads new lists and packages
2. apt-daily-upgrade - Performs upgrades

The first job should run spread out through the day (we run it twice
due to some other reasons), the latter in the morning between 6 and 7,
and at boot, daily-upgrade should be resumed after daily (so we added
After ordering relations to apt-daily-upgrade timer and service).

Now, we seem to be missing one bit: If daily-upgrade is already
running, and daily is about to start, daily should wait for
daily-upgrade to finish. I had hoped that maybe that works
automatically given that there is some ordering relation between the
two, but that did not work out. I tried adding Conflicts, but systemd
then said "loop to fast" and became unresponsive (not sure if caused
by this, but maybe).


It seems to me that this could be easily around by adding
Wants=apt-daily.service to the upgrade unit. That will guarantee that
systemd puts the update job in the queue before the upgrade job. I think
this is what you want, anyways. You want to make sure that you have the
latest lists before starting the upgrade. If you get the timers lined up,
then maybe you won't even get any additional update jobs run.

Dan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Preset/enable issues

[Dan Nicholson]

On Wed, 2016-03-23 at 06:21 -0700, Dan Nicholson wrote:
> At Endless, we compose a system from debian packages which enable
> services based on package policy. However, when we compose our whole
> system, we run systemctl preset-all (in a chroot) with our preset file
> to get the services setup exactly as we want for images.
> 
> After upgrading from 215 to 229, we're seeing some issues.
> 
> 1. preset-all fails with ELOOP if there are any symlinks in
> /etc/systemd/system pointing to /usr/lib/systemd/system. However,
> systemd itself has created these symlinks when units define an Alias
> and have already been enabled. This seems like broken behavior as even
> if I forcefully clean things up, running preset-all again returns the
> same issue.
> 
> # find /etc/systemd/system -maxdepth 1 -type l -delete
> # systemctl preset-all
> Created symlink /etc/systemd/system/display-manager.service, pointing
> to /usr/lib/systemd/system/gdm.service.
> Created symlink /etc/systemd/system/ctrl-alt-del.target, pointing to
> /usr/lib/systemd/system/exit.target.
> Created symlink
> /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service,
> pointing to /usr/lib/systemd/system/ModemManager.service.
> Created symlink /etc/systemd/system/eos-updater.service, pointing to
> /usr/lib/systemd/system/eos-autoupdater.service.
> Created symlink
> /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service,
> pointing to /usr/lib/systemd/system/NetworkManager-dispatcher.service.
> Created symlink /etc/systemd/system/kbrequest.target, pointing to
> /usr/lib/systemd/system/rescue.target.
> Created symlink /etc/systemd/system/dbus-org.bluez.service, pointing
> to /usr/lib/systemd/system/bluetooth.service.
> Created symlink /etc/systemd/system/eos-updater.timer, pointing to
> /usr/lib/systemd/system/eos-autoupdater.timer.
> Created symlink
> /etc/systemd/system/dbus-org.freedesktop.Avahi.service, pointing to
> /usr/lib/systemd/system/avahi-daemon.service.
> # systemctl preset-all
> Operation failed: Too many levels of symbolic links
> 
> Weirdly, using a preset with one of the above real names sometimes
> works even though it would have the exact same issue, and sometimes it
> returns EEXIST for reasons I don't understand.
> 
> I guess this all comes back to commit 0ec0deaa, which tries to
> consider syminks in /etc as user configuration. But then why are alias
> symlinks, which are not user configuration, created in /etc?
> 
> https://github.com/systemd/systemd/issues/2298 has been open for a
> while with no comments.
> 2. Enable does not seem to be escaping the names of the wants
> directories correctly.
> 
> # systemctl enable "dev-disk-by\x2dlabel-eos\x2dswap.swap"
> Created symlink
> /etc/systemd/system/dev-disk-byx2dlabel-eosx2dswap.device.wants/dev-
> disk-by\x2dlabel-eos\x2dswap.swap,
> pointing to /usr/lib/systemd/system/dev-disk-by\x2dlabel-
> eos\x2dswap.swap.
> 
> The directory is created as
> dev-disk-byx2dlabel-eosx2dswap.device.wants, but I'm pretty sure the
> x's should be escaped with \. At least, that's what the unit names do,
> and that's how the directories used to be named by enable.
> 
> Any ideas on these issues?

Seems to be fixed with the following 2 patches. Not sure if they have
wider impact, but they seem right to me.From 55ae8b362f45d4869cafe876be8455996af3e520 Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Wed, 23 Mar 2016 10:44:24 -0700
Subject: [PATCH 1/2] install: Allow existing /etc symlinks for preset

When running systemctl preset or preset-all, there may be existing symlinks in
/etc due to previously enabled units. Allow these rather than returning ELOOP.
---
 src/shared/install.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/shared/install.c b/src/shared/install.c
index ef8f485..0e1c85c 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -2193,7 +2193,7 @@ static int execute_preset(
 int q;
 
 /* Returns number of symlinks that where supposed to be installed. */
-q = install_context_apply(scope, plus, paths, config_path, root_dir, force, SEARCH_LOAD, changes, n_changes);
+q = install_context_apply(scope, plus, paths, config_path, root_dir, force, SEARCH_LOAD|SEARCH_FOLLOW_CONFIG_SYMLINKS, changes, n_changes);
 if (r >= 0) {
 if (q < 0)
 r = q;
-- 
2.1.4

From e61b9ad8171165f8b1919967853c6430b2bfbaad Mon Sep 17 00:00:00 2001
From: Dan Nicholson <nichol...@endlessm.com>
Date: Wed, 23 Mar 2016 11:08:41 -0700
Subject: [PATCH 2/2] conf-parser: Set EXTRACT_RETAIN_ESCAPE when extracting
 words

If you reference another unit with an escaped name, the escaped characters
shoul