>>> Trent Piepho schrieb am 15.05.2019 um 18:54 in
>>> Nachricht
<1557939250.4229.111.ca...@impinj.com>:
> On Wed, 2019-05-15 at 10:03 +, systemd-devel-
> requ...@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.
There's an important point you faul to understand:
The file in /etc is there not because of the _frequency_ of change, but for
_ease_ of configuration.
It's much easier to write one line of text than to create or adjust systemd
unit files, not to talk about the link mess.
>
> 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.
It's all a matter of taste. Different things belong to different files. And any
attempt to enforce one super process that does everything is simply wrong (and
against the spirit of UNIX).
>
> I think of all the ways one might configure services locally. Edit
> environment files read by units, edit the service files, etc.
Well, you can, but you need not.
>
> 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?
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
