[systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
tpiepho at impinj.com
Wed May 15 16:54:11 UTC 2019
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
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?
More information about the systemd-devel