[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice
Bartosz Bilas
b.bilas at grinn-global.com
Mon Feb 3 18:37:30 UTC 2020
Hi everyone,
I had finally a couple of time to double-check that and I agree with
Jeremy that I was wrong therefore let's reject this patch as it turned
out as an unthought idea.
Best
Bartek
On 25.11.2019 18:02, Jérémy ROSEN wrote:
> That's very weird... I'm absolutely certain that generators are
> (supposed to) run on config reload and every reboot.
> The files they create are stored under /run, so they are destroyed on
> every reboot.
>
> Either you have some bug somewhere or you misdiagnosed something...
>
> Do not that generators are run *very early* in the boot (before the
> unit files are even loaded) so stuff like journald are not around yet.
> The best way to check if they are run might be to create a tiny
> generator that saves the current date and time in /run or something
> like that...
>
> Jeremy
>
>
> Le lun. 25 nov. 2019 à 17:55, Bartosz Bilas <b.bilas at grinn-global.com
> <mailto:b.bilas at grinn-global.com>> a écrit :
>
> Hello,
>
> On 25.11.2019 17:48, Jérémy ROSEN wrote:
>> I don't understand that remark...
>>
>> generators are run at every boot and also when "systemctl
>> daemon-reload" is called
>> They have nothing to do with the machine-id or the firstboot logic...
>
> that's weird because when I was testing I noticed the generators
> were executing only once during the first new system instance
> boots up. I'll double-check that then.
>
> Best
> Bartek
>>
>> Le lun. 25 nov. 2019 à 17:44, Bartosz Bilas
>> <b.bilas at grinn-global.com <mailto:b.bilas at grinn-global.com>> a
>> écrit :
>>
>> Hello guys,
>>
>> On 17.11.2019 16:06, Jérémy ROSEN wrote:
>>> overall I'm not very keen on adding options for the various
>>> generators...
>>>
>>> there are special case where you want to get rid of a
>>> specific generator, but it's really special and probably
>>> better done in a post-image script
>>>
>>> detailed answers below
>>>
>>> Le dim. 17 nov. 2019 à 15:12, Arnout Vandecappelle
>>> <arnout at mind.be <mailto:arnout at mind.be>> a écrit :
>>>
>>>
>>>
>>> On 17/11/2019 12:33, Bartosz Bilas wrote:
>>> > Allow the user to choose which systemd generator
>>> should be installed
>>> > on the target instead of installing all of them by
>>> default.
>>> > That's usefull in case of when someone is using
>>> firstboot condition
>>> useful
>>>
>>> > and doesn't want to have e.g getty services created
>>> automatically during
>>> > system boot by systemd-getty-generator. Set them
>>> enabled by default to
>>> > keep compatibility with old builds.
>>> >
>>> > Signed-off-by: Bartosz Bilas <b.bilas at grinn-global.com
>>> <mailto:b.bilas at grinn-global.com>>
>>> > ---
>>> > package/systemd/Config.in | 94
>>> ++++++++++++++++++++++++++++++++++++++
>>> > package/systemd/systemd.mk <http://systemd.mk> | 56
>>> +++++++++++++++++++++++
>>> > 2 files changed, 150 insertions(+)
>>> >
>>> > diff --git a/package/systemd/Config.in
>>> b/package/systemd/Config.in
>>> > index fadc1a32c8..052b69f4de 100644
>>> > --- a/package/systemd/Config.in
>>> > +++ b/package/systemd/Config.in
>>> > @@ -112,6 +112,100 @@ config
>>> BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
>>> > default "x64" if BR2_x86_64
>>> > depends on BR2_PACKAGE_SYSTEMD_BOOT
>>> >
>>> > +menu systemd-generators
>>>
>>> I don't like adding submenus. Instead, I'd just do it
>>> with a comment.
>>>
>>> However, doesn't all this depend on
>>> BR2_PACKAGE_SYSTEMD_FIRSTBOOT? In that
>>> case, it could be done with a condition just under that
>>> option and the
>>> generators would be indented. Although, maybe they don't
>>> only get executed on
>>> firstboot...
>>>
>>>
>>> No... generators are a core feature of systemd, it's not
>>> related to first-boot in any way that I know
>>>
>>> So, then I'd move this section to the end of Config.in,
>>> and use a comment
>>> instead of a menu.
>>>
>>> > +config BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR
>>> > + bool "systemd debug generator"
>>> > + default y
>>>
>>> Although this one should default y for backward
>>> compatibility, I'm of a mind to
>>> change the default here. It doesn't sound like something
>>> you want to have on by
>>> default.
>>>
>>>
>>> Despite its name, this is not a debug tool, but more of a
>>> rescue tool. It allows you to get a shell back on a
>>> very broken system, or to prevent a unit from starting from
>>> the kernel-command-line
>>>
>>> This should really be here all the time except on very
>>> specific use-cases, I don't think making it optional
>>> is a good idea
>>>
>>> > + help
>>> > + systemd-debug-generator is for enabling a
>>> runtime debug
>>> > + shell and masking specific units at boot.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html
>>> > +
>>> > +config BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR
>>> > + bool "systemd fstab generator"
>>> > + default y
>>> > + help
>>> > + systemd-fstab-generator is a generator that
>>> translates
>>> > + /etc/fstab into native systemd units early at boot
>>> > + and when configuration of the system manager
>>> is reloaded.
>>> > + This will instantiate mount and swap units as
>>> necessary.
>>>
>>> Makes me realize that we probably shouldn't have an
>>> fstab in
>>> skeleton-init-systemd...
>>>
>>> fstab is supported in systemd and it is not a deprecated
>>> feature.
>>> It is the recommended way to automatically mount filesystems
>>> at boot.
>>>
>>> this one is really fundamental, and should really not be
>>> removed. lots of things might break.
>>>
>>> there are a couple of reasons to use .mount units instead
>>> (and the fstab-generator simply
>>> creates .mount units from /etc/fstab) but in the common case
>>> you are supposed to use /etc/fstab
>>>
>>> so again, I don't think this is a good idea.
>>>
>>>
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
>>> > +
>>> > +config BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR
>>> > + bool "systemd getty generator"
>>> > + default y
>>> > + help
>>> > + systemd-getty-generator is a generator that
>>> automatically
>>> > + instantiates serial-getty at .service
>>> <mailto:serial-getty at .service> on the kernel
>>> > + console(s), if they can function as ttys and
>>> are not
>>> > + provided by the virtual console subsystem. It
>>> will also
>>> > + instantiate serial-getty at .service
>>> <mailto:serial-getty at .service> instances for
>>> > + virtualizer consoles, if execution in a
>>> virtualized
>>> > + environment is detected.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html
>>> > +
>>>
>>>
>>> That one could be made optional, since it's about
>>> runtime-detection of the right way to start a getty
>>> (i.e figure out if the console is a serial tty, a normal
>>> tty, or a vconsole) and in the embedded case
>>> we usually know what we have
>>>
>>> note that it means manually enabling a service instead...
>>> which is probably harder
>>>
>>> but otoh, it's typically very small and it does "the right
>>> thing" most of the time. So again, probably a
>>> better fit for a post-image script
>>>
>>> > +config BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR
>>> > + bool "systemd gpt auto generator"
>>> > + default y
>>>
>>> For this one, I also doubt that we want to have this
>>> default on.
>>>
>>>
>>> That one can probably be made optional, yes... it saves 34k
>>> approximately
>>>
>>> > + help
>>> > + systemd-gpt-auto-generator is a unit generator
>>> that
>>> > + automatically discovers root, /home/, /srv/,
>>> the EFI
>>> > + System Partition, the Extended Boot Loader
>>> Partition and
>>> > + swap partitions and creates mount and swap
>>> units for them,
>>> > + based on the partition type GUIDs of GUID
>>> partition tables
>>> > + (GPT). It implements the Discoverable Partitions
>>> > + Specification.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
>>> > +
>>> > +config BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR
>>> > + bool "systemd rc local generator"
>>> > + default y
>>>
>>> Same here. It's pretty useless in Buildroot context.
>>>
>>>
>>> this one is already conditional to compiling sysV backward
>>> compatibility support...
>>> which i think is always on in buildroot (neet to
>>> double-check that)
>>>
>>> I think having an option to enable/disable sysV support
>>> would be more generic and more useful
>>>
>>> > + help
>>> > + systemd-rc-local-generator is a generator that
>>> checks
>>> > + whether /etc/rc.local exists and is executable,
>>> > + and if it is pulls the rc-local.service unit
>>> into the
>>> > + boot process.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-rc-local-generator.html
>>> > +
>>> > +config BR2_PACKAGE_SYSTEMD_RUN_GENERATOR
>>> > + bool "systemd run generator"
>>> > + default y
>>> > + help
>>> > + systemd-run-generator is for invoking commands
>>> specified
>>> > + on the kernel command line as system service.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html
>>> > +
>>>
>>>
>>> This one could be optional... it's very usefull for
>>> containers, less for full-blown systems
>>>
>>> > +config BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
>>> > + bool "systemd system update generator"
>>> > + default y
>>> > + help
>>> > + systemd-system-update-generator is a generator
>>> that
>>> > + automatically redirects the boot process to
>>> > + system-update.target, if /system-update exists.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>>> > +
>>>
>>>
>>> this one could be optional
>>>
>>> > +config BR2_PACKAGE_SYSTEMD_SYSV_GENERATOR
>>> > + bool "systemd sysv generator"
>>> > + default y
>>> > + help
>>> > + systemd-sysv-generator is a generator that
>>> creates wrapper
>>> > + .service units for SysV init scripts in
>>> /etc/init.d/* at
>>> > + boot and when configuration of the system
>>> manager is
>>> > + reloaded. This will allow systemd(1) to
>>> support them
>>> > + similarly to native units/
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>>> > +
>>> > +endmenu
>>> > +
>>>
>>>
>>> Again, i'd rather have a generic way to disable the sysV
>>> support at compile time...
>>>
>>>
>>>
>>> Ok so overall, I think most generators should stay in and
>>> only one or two should be made optional...
>>> Sorry for the negative feedback, but I don't like adding
>>> complex compilation options that are not supported
>>> upstream, especially when all generators together wait 272k
>>> on my debian
>> Until we don't decide about the installation machine-id file
>> that patch doesn't make any sense due to the impossibility to
>> run those generators at all.
>>
>> Best
>> Bartek
>>>
>>> The few that could legitimately be made optional are easy
>>> enough to remove in a post-image that I'm not sure
>>> it's worth the trouble
>>>
>>> i'd be ok for a patch doing that, though, but only for the
>>> few ones that are worth it...
>>>
>>> Cheers
>>> Jeremy
>>>
>>> --
>>> SMILE <http://www.smile.eu/>
>>>
>>> 20 rue des Jardins
>>> 92600 Asnières-sur-Seine
>>>
>>>
>>> *Jérémy ROSEN*
>>> Architecte technique
>>>
>>> email jeremy.rosen at smile.fr <mailto:jeremy.rosen at smile.fr>
>>> phone +33 6 88 25 87 42
>>> url http://www.smile.eu <http://www.smile.eu/>
>>>
>>> Twitter <https://twitter.com/GroupeSmile> Facebook
>>> <https://www.facebook.com/smileopensource> LinkedIn
>>> <https://www.linkedin.com/company/smile> Github
>>> <https://github.com/Smile-SA>
>>>
>>>
>>> Découvrez l’univers Smile, rendez-vous sur smile.eu
>>> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>>
>>
>>
>> --
>> SMILE <http://www.smile.eu/>
>>
>> 20 rue des Jardins
>> 92600 Asnières-sur-Seine
>>
>>
>> *Jérémy ROSEN*
>> Architecte technique
>>
>> email jeremy.rosen at smile.fr <mailto:jeremy.rosen at smile.fr>
>> phone +33 6 88 25 87 42
>> url http://www.smile.eu <http://www.smile.eu/>
>>
>> Twitter <https://twitter.com/GroupeSmile> Facebook
>> <https://www.facebook.com/smileopensource> LinkedIn
>> <https://www.linkedin.com/company/smile> Github
>> <https://github.com/Smile-SA>
>>
>>
>> Découvrez l’univers Smile, rendez-vous sur smile.eu
>> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net <mailto:buildroot at busybox.net>
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
>
> --
> SMILE <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
>
>
> *Jérémy ROSEN*
> Architecte technique
>
> email jeremy.rosen at smile.fr <mailto:jeremy.rosen at smile.fr>
> phone +33 6 88 25 87 42
> url http://www.smile.eu <http://www.smile.eu/>
>
> Twitter <https://twitter.com/GroupeSmile> Facebook
> <https://www.facebook.com/smileopensource> LinkedIn
> <https://www.linkedin.com/company/smile> Github
> <https://github.com/Smile-SA>
>
>
> Découvrez l’univers Smile, rendez-vous sur smile.eu
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200203/b959925e/attachment.html>
More information about the buildroot
mailing list