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

Dan Nicholson dbn at endlessos.org
Mon May 1 22:12:59 UTC 2023 

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 <martin.petzold at tavla.de>
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 <daan.j.demeyer at gmail.com>
> 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, <martin.petzold at tavla.de>
>> 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, <martin.petzold at tavla.de>
>>> 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 at 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 at .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 debug-shell.service
>>>>
>>>> disable halt.target
>>>> disable kexec.target
>>>> disable poweroff.target
>>>> enable reboot.target
>>>> disable rescue.target
>>>> disable exit.target
>>>>
>>>> disable systemd-networkd-wait-online.service
>>>> disable systemd-time-wait-sync.service
>>>> disable systemd-boot-check-no-failures.service
>>>> disable proc-sys-fs-binfmt_misc.mount
>>>>
>>>> disable syslog.socket
>>>>
>>>> disable systemd-journal-gatewayd.*
>>>> disable systemd-journal-remote.*
>>>> disable systemd-journal-upload.*
>>>>
>>>> =========================================
>>>>
>>>> >
>>>> >> Platform:
>>>> >>
>>>> >> systemd 252.5-2~bpo11+1 (from bullseye-backports)
>>>> >> systemd-resolved and systemd-networkd with iwd (all from
>>>> >> bullseye-backports)
>>>> >> Custom Debian bullseye (with some packages from bullseye-backports)
>>>> >> Custom Kernel 5.10
>>>> >> U-Boot
>>>> >>
>>>> >> [1] https://systemd.io/BUILDING_IMAGES/
>>>> >> [2] https://wiki.debian.org/MachineId
>>>>
>>>> Best regards,
>>>>
>>>> Martin
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230501/f6d88665/attachment-0001.htm>

More information about the systemd-devel mailing list