[systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

[Trent Piepho]

On Wed, 2019-05-15 at 10:03 +0000, systemd-devel-
request at lists.freedesktop.org wrote:
> 
> 
> If you are looking for a generic converter of foreign stuff into
> classic, persistent systemd unit files, then generators is not what
> you should be using. Generators are life-cycle bound to systemd
> release cycles, and their output ceases to exist on every reload
> boundary, and when the system is offline. If we'd allow generated
> units to be installed that clear life-cycle would be very much
> blurred, as suddenly you'd have configuration that hooks them into the
> system that is more persistant than the actual definitions of the
> units themselves, and that's just borked...
> 
> I mean, if you want to persistently enable a unit that is converted
> from something else, then please write your own converted, and write
> something to /etc/systemd/system, there's no need whatsoever to bother
> systemd itself with that, you shouldn't use generators for that.
> 

As an embedded Linux developer, I think there is an interesting idea
here.

There are no admins on an embedded system and everything must be done
through some automatic piece of software.  As soon I see, "edit a file
in /etc," I know there's a problem I'll need to find a solution for
because the normal way isn't going to work.

Embedded likes read-only root filesystems.  We also like it if software
image we create is immutable.  So copying /etc out of a read-only
filesystem into a writable one isn't really a solution to the problems
posed by a read-only rootfs, as it largely defeats the purpose of
making the rootfs read-only in the first place.

I want the device configuration to be transactional.  I want it to be
safe from power cycles as it's updated.  There should be roll-backs to
previous configs, exporting configuration, importing it, pushing
changes to a fleet of devices, automatic migration forward and backward
across software versions.

This is hard to do with a pile of text files in /etc all in different
formats and parsed by different software.

I think of all the ways one might configure services locally.  Edit
environment files read by units, edit the service files, etc.

What if I dynamically generated service files?  There's a lot that
could be done that way.

I can sort of dynamically enable units by starting them over dbus.  But
 that really only works after most of the boot is done.  What if I want
to dynamically alter the CapabilityBoundingSet based on what features
of a service are enabled?