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

[Daan De Meyer]

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/20230429/e82d1714/attachment.htm>