Antw: Re: Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Trent Piepho <tpiepho@xxxxxxxxxx> schrieb am 15.05.2019 um 18:54 in Nachricht
<1557939250.4229.111.camel@xxxxxxxxxx>:
> On Wed, 2019-05-15 at 10:03 +0000, systemd-devel-
> request@xxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 




_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel