Re: [OE-core] should recipes not come with their own systemd/user/group info?

["Khem Raj" <raj.khem@gmail.com>]

On Thu, Aug 5, 2021 at 4:01 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>
>   style question here, but i'm perusing an OE/YP (actually wind river,
> but effectively the same thing) layer that was handed to me, and i'm
> puzzled by how the internally-written systemd-controlled services are
> implemented.
>
>   on the one hand, there are reasonable recipes that each represent
> some service to be managed by systemd, and they all install their
> executables in the right places and so on. however, rather than each
> recipe also providing its own service file, there is a totally
> separate recipe (call it "systemd-services.bb") which contains under
> its files/ directory dozens and dozens of service files for all of
> those recipes, and is responsible for installing all of them.
>
>   in short, someone decided that -- for whatever reason -- all of the
> systemd service files should be collected all in one place, and
> installed en masse. is this ... normal? i would have thought that it's
> the responsibility of each recipe to mannage all the content related
> to it, and that would of course include the systemd service file to be
> installed for it. i don't know the rationale for this, and it strikes
> me as a recipe for disaster in trying to keep all these things synced
> up. is there some rationale for doing it this way that i'm unaware
> of?

Usually its better to keep them with recipes/components that helps you
with managing multiple devices which may use different packages better
however in many places component owners are not interested in maintaining
the startup or life cycle management of component and its done by some
central platform team and they may create a single component to manage
the device because it fits there workflow because they don't have to go and
commit these scripts to multiple repos etc, I do not encourage such setup
although there could be some policies which could be implemented via
just systemd scripts and they may live together but if it becomes one place
for all unit files perhaps not ideal.

>
>   and closely related, the same trick was used when defining all the
> new users and groups that would own these services. rather than each
> service looking after itself, there is a recipe file (call it
> "new_users_and_groups.bb") which is hundreds of lines of USERADD_PARAM
> and GROUPADD_PARAM lines that define precisely (numerically) all the
> new user and group accounts to be associated with all sorts of
> services, whereupon i ask the same question -- isn't it more typical
> that each service look after its own user and group info?
>
>   in this second case, it *might* be that all of these values need to
> be hard-coded to be consistent with, i don't know, something else i'm
> unaware of, but it still looks strange.
>
>   thoughts? the above actually works for the time being, but it does
> seem a but unnatural.
>

same logic I would say

> rday
>
> 
>