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

2019-05-20 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 16.05.2019 um 10:29
in
Nachricht <20190516082910.GA24042@gardel-login>:
> On Do, 16.05.19 08:55, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> After having read the page again, it's not more clear than
>> before. Even I have some more questions:
>>
>> Why do generators receive three directory paths: Should the
>> generator decide where at those three paths to add a unit?
> 
> Yes.
> 
> This is explained in the documentation btw:
> https://www.freedesktop.org/software/systemd/man/systemd.generator.html 
> 
> Long story short: it's about unit file precedence.
> 
>> How should it know? Wouldn't it be easier to provide one path and
>> adjust that as necessary? (My generator just uses the first path)
> 
> It's up to the generator to decide whether it wants to override native
> unit files already in place, or whether it wants those to override
> whatever it generates.
> 
> Please read up on the documentation.
> 
>> Also: the only thing that might prevent using a generator for
>> dynamic configuration is that it is called early during boot.
> 
> Generators follow the reload cycle, and the reload cycle is how the
> reload cycle is.
> 
>> So I could have a generator that just saved the three paths
>> somewhere, and a unit that calls "another generator" that is not
>> detected as a systemd generator using the paths saved before to
>> generate the unit files and do a "systemctl reload‑daemon" (watching
>> out for possible indirect recursion). But why the dance?
> 
> Doing "systemctl daemon‑reload" in clean codepaths is possible but not
> good style. It's slow and problematic since Linux doesn't really have
> a transactional fs, and thus you never know in which precise state the
> fs is when systemd reloads things in case multiple programs make
> modifications to the unit files at the same time.
> 
>> What makes your generators special? That they have no explicitly
>> settable dependencies, or that they are called with three directory
>> arguments?
> 
> I am not sure how to parse that.
> 
> As I mentioned before: you appear to think that generators are
> something they are clearly not.
> 
>> And what about the "link stuff": Doesn't reload‑daemon create those
>> as needed from the unit files? Why should the generator have to mess
>> with those? It's all not clear from the manual page. The only thing
>> I can imagine is that those "link messing" is needed to provide
>> functionality the systemd actually lacks.
> 
> daemon‑reload just reloads configuation, it does not create or remove
> any symlinks.

The manual page says (contradicting IMHO): "This will rerun all generators
(see systemd.generator(7)), reload all unit files, and recreate the entire
dependency tree."

> 
> It's your generator's job to hook the units it might generate into
> the right places. systemctl can't guess that. I mean, if a service
> shall be started during regular boot, or if it shall be hooked into
> getty.target or when bluetooth hw is plugged in is nothing systemd can
> guess for you.

The manual page as I find it leaves a lot of guessing.

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



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

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

2019-05-16 Thread Lennart Poettering
On Do, 16.05.19 12:04, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > This is explained in the documentation btw:
> > https://www.freedesktop.org/software/systemd/man/systemd.generator.html
> >
> > Long story short: it's about unit file precedence.
>
> Sorry I don't get it: So the idea is to have different generators, depending
> on the precedence?

No. As explained in the documentation: sometimes you want to generate
dynamic unit files that override the regular unit files (think:
overriding the boot target the system shall boot into). Sometimes you
want that regular unit files override the dynamic ones (think: you
automaticlly convert sysv scripts to native unit files, but if a
regular unit file already exists for a service you want that to take
precedence, since native should be better than converted).

All generators are run at the same time btw, there's no ordering
between them.

> >> How should it know? Wouldn't it be easier to provide one path and
> >> adjust that as necessary? (My generator just uses the first path)
> >
> > It's up to the generator to decide whether it wants to override native
> > unit files already in place, or whether it wants those to override
> > whatever it generates.
>
> OK, so different generators.

Nope, please read the documentation. it's very clearly explained
there. It's about precendence relative to installed regular unit files.

> > Please read up on the documentation.
>
> Actually I have read it multiple times, but still is's not very
> helpful.

Sorry, but it doesn't appear like you did...

> Is calling the generators logged (and maybe finishing the last generator,
> too)? After boot I could not find a journal message regarding that.

Turn on debug logging, and it is. i.e. add systemd.log_level=debug to
the kernel command line.

> > Doing "systemctl daemon‑reload" in clean codepaths is possible but not
> > good style. It's slow and problematic since Linux doesn't really have
> > a transactional fs, and thus you never know in which precise state the
> > fs is when systemd reloads things in case multiple programs make
> > modifications to the unit files at the same time.
>
> So what is the preferred method when some package install adds new
> unit files?  systemctl daemon-reload?

Yes. That's the command to invoke whenever you remove or drop in unit
files into the directories in /usr/lib/systemd/system or
/etc/systemd/system or similar.

> >> What makes your generators special? That they have no explicitly
> >> settable dependencies, or that they are called with three directory
> >> arguments?
> >
> > I am not sure how to parse that.
>
> You claim the generators are very special, but I don't get
> it. Sorry.

They run in an early boot environment outside of any service
management, snce they generate service definitions. That makes them
kinda special. See the long list of dos/donts in the documentation.

https://www.freedesktop.org/software/systemd/man/systemd.generator.html

> > As I mentioned before: you appear to think that generators are
> > something they are clearly not.
>
> And you seem unable to explain why they are not what I thing they
> are.

I am sorry, but this gets on my nerves. Yes, our documentation is not
perfect (which documentation is?) but you appear unable to read even
the most basic parts of it, since most of what you are asking is
actually documented in the various linked docs.

Please, when you are new to systemd, start with the simple things
first, and as you grokked them continue with the more complex
stuff. You are jumping to the advanced stuff from zero apparently,
without understanding the basic concepts the advanced stuff builds
on. Of course things are going to be frustrating if you do that, but
maybe the fix to that is starting to reading up on the basics first!

You receieved an awful lot of free help here even though when you came
onto the mailing list you started out with telling evreyone how awful
systemd is. You are using up all my patience slowly but surely, and if
you continue like that you'll notice the responses you get will be
fewer and fewer.

> And what creates those dependency links and when? It's OK to point me to the
> correct manual page.

For units installed via packages in /usr/lib/systemd/system or by the
user in /etc/systemd/system these links are created by "systemctl
enable". You can also create them maualy if you like, that's fine.

That maps 1:1: how tools such as update-rc.d or chkconfig did things
on the various distros back in sysvinit times.

If you write a generator then its the generator that creates the
symlinks. But again, generators are an advanced topic, and you
shouldn't use them unless you really really know what you are doing.

https://www.freedesktop.org/software/systemd/man/systemctl.html#enable%20UNIT%E2%80%A6

> > the right places. systemctl can't guess that. I mean, if a service
>
> So "link messing"; it's the ugly part of systemd.

What's so hard about using "systemctl enable"? I 

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

2019-05-16 Thread Zbigniew Jędrzejewski-Szmek
On Thu, May 16, 2019 at 12:04:28PM +0200, Ulrich Windl wrote:
> >>> Lennart Poettering  schrieb am 16.05.2019 um 10:29
> in
> Nachricht <20190516082910.GA24042@gardel-login>:
> > On Do, 16.05.19 08:55, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> > 
> >> Hi!
> >>
> >> After having read the page again, it's not more clear than
> >> before. Even I have some more questions:
> >>
> >> Why do generators receive three directory paths: Should the
> >> generator decide where at those three paths to add a unit?
> > 
> > Yes.
> > 
> > This is explained in the documentation btw:
> > https://www.freedesktop.org/software/systemd/man/systemd.generator.html 
> > 
> > Long story short: it's about unit file precedence.
> 
> Sorry I don't get it: So the idea is to have different generators, depending
> on the precedence?

Please, this is just wasting everyone's time. Take the advice that
Reindl gave you: generators are an advanced tool that you don't need
when staring with systemd.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-16 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 16.05.2019 um 10:29
in
Nachricht <20190516082910.GA24042@gardel-login>:
> On Do, 16.05.19 08:55, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> After having read the page again, it's not more clear than
>> before. Even I have some more questions:
>>
>> Why do generators receive three directory paths: Should the
>> generator decide where at those three paths to add a unit?
> 
> Yes.
> 
> This is explained in the documentation btw:
> https://www.freedesktop.org/software/systemd/man/systemd.generator.html 
> 
> Long story short: it's about unit file precedence.

Sorry I don't get it: So the idea is to have different generators, depending
on the precedence?

> 
>> How should it know? Wouldn't it be easier to provide one path and
>> adjust that as necessary? (My generator just uses the first path)
> 
> It's up to the generator to decide whether it wants to override native
> unit files already in place, or whether it wants those to override
> whatever it generates.

OK, so different generators.

> 
> Please read up on the documentation.

Actually I have read it multiple times, but still is's not very helpful.

> 
>> Also: the only thing that might prevent using a generator for
>> dynamic configuration is that it is called early during boot.
> 
> Generators follow the reload cycle, and the reload cycle is how the
> reload cycle is.

Is calling the generators logged (and maybe finishing the last generator,
too)? After boot I could not find a journal message regarding that.

> 
>> So I could have a generator that just saved the three paths
>> somewhere, and a unit that calls "another generator" that is not
>> detected as a systemd generator using the paths saved before to
>> generate the unit files and do a "systemctl reload‑daemon" (watching
>> out for possible indirect recursion). But why the dance?
> 
> Doing "systemctl daemon‑reload" in clean codepaths is possible but not
> good style. It's slow and problematic since Linux doesn't really have
> a transactional fs, and thus you never know in which precise state the
> fs is when systemd reloads things in case multiple programs make
> modifications to the unit files at the same time.

So what is the preferred method when some package install adds new unit files?
systemctl daemon-reload?

> 
>> What makes your generators special? That they have no explicitly
>> settable dependencies, or that they are called with three directory
>> arguments?
> 
> I am not sure how to parse that.

You claim the generators are very special, but I don't get it. Sorry.

> 
> As I mentioned before: you appear to think that generators are
> something they are clearly not.

And you seem unable to explain why they are not what I thing they are.

> 
>> And what about the "link stuff": Doesn't reload‑daemon create those
>> as needed from the unit files? Why should the generator have to mess
>> with those? It's all not clear from the manual page. The only thing
>> I can imagine is that those "link messing" is needed to provide
>> functionality the systemd actually lacks.
> 
> daemon‑reload just reloads configuation, it does not create or remove
> any symlinks.

And what creates those dependency links and when? It's OK to point me to the
correct manual page.

> 
> It's your generator's job to hook the units it might generate into
> the right places. systemctl can't guess that. I mean, if a service

So "link messing"; it's the ugly part of systemd.

> shall be started during regular boot, or if it shall be hooked into
> getty.target or when bluetooth hw is plugged in is nothing systemd can
> guess for you.

Isn't it sufficient when a generated unit contains "Wants=" or similar? If I
have to mess with links, why does "Wants=" exist at all? Maybe its all
historical, I don't know.

Regards,
Ulrich Windl

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

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

2019-05-16 Thread Lennart Poettering
On Do, 16.05.19 08:55, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> Hi!
>
> After having read the page again, it's not more clear than
> before. Even I have some more questions:
>
> Why do generators receive three directory paths: Should the
> generator decide where at those three paths to add a unit?

Yes.

This is explained in the documentation btw:
https://www.freedesktop.org/software/systemd/man/systemd.generator.html

Long story short: it's about unit file precedence.

> How should it know? Wouldn't it be easier to provide one path and
> adjust that as necessary? (My generator just uses the first path)

It's up to the generator to decide whether it wants to override native
unit files already in place, or whether it wants those to override
whatever it generates.

Please read up on the documentation.

> Also: the only thing that might prevent using a generator for
> dynamic configuration is that it is called early during boot.

Generators follow the reload cycle, and the reload cycle is how the
reload cycle is.

> So I could have a generator that just saved the three paths
> somewhere, and a unit that calls "another generator" that is not
> detected as a systemd generator using the paths saved before to
> generate the unit files and do a "systemctl reload-daemon" (watching
> out for possible indirect recursion). But why the dance?

Doing "systemctl daemon-reload" in clean codepaths is possible but not
good style. It's slow and problematic since Linux doesn't really have
a transactional fs, and thus you never know in which precise state the
fs is when systemd reloads things in case multiple programs make
modifications to the unit files at the same time.

> What makes your generators special? That they have no explicitly
> settable dependencies, or that they are called with three directory
> arguments?

I am not sure how to parse that.

As I mentioned before: you appear to think that generators are
something they are clearly not.

> And what about the "link stuff": Doesn't reload-daemon create those
> as needed from the unit files? Why should the generator have to mess
> with those? It's all not clear from the manual page. The only thing
> I can imagine is that those "link messing" is needed to provide
> functionality the systemd actually lacks.

daemon-reload just reloads configuation, it does not create or remove
any symlinks.

It's your generator's job to hook the units it might generate into
the right places. systemctl can't guess that. I mean, if a service
shall be started during regular boot, or if it shall be hooked into
getty.target or when bluetooth hw is plugged in is nothing systemd can
guess for you.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-16 Thread Ulrich Windl
Hi!

After having read the page again, it's not more clear than before. Even I have 
some more questions:

Why do generators receive three directory paths: Should the generator decide 
where at those three paths to add a unit? How should it know? Wouldn't it be 
easier to provide one path and adjust that as necessary? (My generator just 
uses the first path)
Also: the only thing that might prevent using a generator for dynamic 
configuration is that it is called early during boot.

So I could have a generator that just saved the three paths somewhere, and a 
unit that calls "another generator" that is not detected as a systemd generator 
using the paths saved before to generate the unit files and do a "systemctl 
reload-daemon" (watching out for possible indirect recursion). But why the 
dance?

What makes your generators special? That they have no explicitly settable 
dependencies, or that they are called with three directory arguments?
And what about the "link stuff": Doesn't reload-daemon create those as needed 
from the unit files? Why should the generator have to mess with those? It's all 
not clear from the manual page. The only thing I can imagine is that those 
"link messing" is needed to provide functionality the systemd actually lacks.

Regards,
Ulrich

>>> Lennart Poettering 05/15/2019, 12:22 PM >>>
On Mi, 15.05.19 12:08, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> > 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.
>
> Sorry, I still don't get it: The only(?) difference is the path where they
> (units files) are found, and that the /run directory is volatile. Aren't the
> other differences not just "artificial"?
Please see:
https://www.freedesktop.org/software/systemd/man/systemd.generator.html
i.e. generators are invoked whenever a reload cycle begins, and output
their units into a specific directories that are flushed our when the
reload cycle ends. i.e. everytime "systemctl daemon-reload" is invoked
the files generated on the current cycles are removed, and the
generators started again to generate a new set of files. Whateever
they generate has very clear, very volatile semantics: issue
"systemctl daemon-reload" and its all gone.
Lennart
--
Lennart Poettering, Berlin

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

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

2019-05-15 Thread Trent Piepho
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.

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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-15 Thread Reindl Harald


Am 15.05.19 um 13:12 schrieb Ulrich Windl:
>> Well, there can always be more examples, but "generators" are
>> inherently an advanced concept: if you are writing a generator, then
>> you already should be pro enough to be able to consult the sources of
>> the various generators shipped with systemd.
>>
>> i.e. it's not a beginners topic, it's a very low-level, technicallly
>> advanced one.
> 
> But you can assume that someone reading the manual page about generators wants
> to ...well... read about generators.
> Otherwise you could shorten the manual page to "Go away! You are not supposed
> to read this."

don't get me wrong but as you are a beginner to systemd stuff why don't
you just start with ordinary unit files in /etc/systemd/system as
erevrybody else does so you can get warm with systemd, systemctl and so on?

i use systemd now for 7 years on all sort of setups from firewalls over
workstations to production servers and wrote a ton of systemd units and
targs but never had any need to even consider generators at all
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-15 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.05.2019 um 12:20
in
Nachricht <20190515102024.GB23038@gardel-login>:
> On Mi, 15.05.19 12:12, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) 
> wrote:
> 
>> >>> Lennart Poettering  schrieb am 15.05.2019 um
12:04
>> in
>> Nachricht <20190515100400.GB22945@gardel-login>:
>> > On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
>> wrote:
>> >
>> >> > Writing a generator is not a typical user would do. It's what a
>> >> > developer of a package would do, and yes, in that case, when you
write
>> >> > code you need a bit more understanding of the underpinnings and need
>> >> > to do more work.
>> >>
>> >> systemd.generator(7) could really need some (better/realistic)
examples.
>> >
>> > I think you assume generators are something they inherently are not.
>>
>> Even if so, a better example might clarify things. Just referring to a 
> binary
>> generator like systemd-fstab-generator is not really helpful to teach how
to
>> write a generator. You don't like scripts as generators, but I think still

> they
>> would make a good example what a generator is supposed to do and what not.
> 
> Well, there can always be more examples, but "generators" are
> inherently an advanced concept: if you are writing a generator, then
> you already should be pro enough to be able to consult the sources of
> the various generators shipped with systemd.
> 
> i.e. it's not a beginners topic, it's a very low-level, technicallly
> advanced one.

But you can assume that someone reading the manual page about generators wants
to ...well... read about generators.
Otherwise you could shorten the manual page to "Go away! You are not supposed
to read this."

Rehgards,
Ulrich

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

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

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 12:12, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >>> Lennart Poettering  schrieb am 15.05.2019 um 12:04
> in
> Nachricht <20190515100400.GB22945@gardel-login>:
> > On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> >
> >> > Writing a generator is not a typical user would do. It's what a
> >> > developer of a package would do, and yes, in that case, when you write
> >> > code you need a bit more understanding of the underpinnings and need
> >> > to do more work.
> >>
> >> systemd.generator(7) could really need some (better/realistic) examples.
> >
> > I think you assume generators are something they inherently are not.
>
> Even if so, a better example might clarify things. Just referring to a binary
> generator like systemd-fstab-generator is not really helpful to teach how to
> write a generator. You don't like scripts as generators, but I think still 
> they
> would make a good example what a generator is supposed to do and what not.

Well, there can always be more examples, but "generators" are
inherently an advanced concept: if you are writing a generator, then
you already should be pro enough to be able to consult the sources of
the various generators shipped with systemd.

i.e. it's not a beginners topic, it's a very low-level, technicallly
advanced one.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 12:08, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > 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.
>
> Sorry, I still don't get it: The only(?) difference is the path where they
> (units files) are found, and that the /run directory is volatile. Aren't the
> other differences not just "artificial"?

Please see:

https://www.freedesktop.org/software/systemd/man/systemd.generator.html

i.e. generators are invoked whenever a reload cycle begins, and output
their units into a specific directories that are flushed our when the
reload cycle ends. i.e. everytime "systemctl daemon-reload" is invoked
the files generated on the current cycles are removed, and the
generators started again to generate a new set of files. Whateever
they generate has very clear, very volatile semantics: issue
"systemctl daemon-reload" and its all gone.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-15 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.05.2019 um 12:04
in
Nachricht <20190515100400.GB22945@gardel-login>:
> On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> > Writing a generator is not a typical user would do. It's what a
>> > developer of a package would do, and yes, in that case, when you write
>> > code you need a bit more understanding of the underpinnings and need
>> > to do more work.
>>
>> systemd.generator(7) could really need some (better/realistic) examples.
> 
> I think you assume generators are something they inherently are not.

Even if so, a better example might clarify things. Just referring to a binary
generator like systemd-fstab-generator is not really helpful to teach how to
write a generator. You don't like scripts as generators, but I think still they
would make a good example what a generator is supposed to do and what not.

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



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

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

2019-05-15 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.05.2019 um 12:03
in
Nachricht <20190515100311.GA22945@gardel-login>:
> On Mi, 15.05.19 11:57, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> >> could call "systemctl add‑wants ‑‑transient" to do the job,
>> >> but at that point, that's more pedantic than practical. If you write a
>> >> generator, your systemd‑fu should be high enough to know and
>> >> understand systemd's symlink mechanisms...
>> >
>> > Precisely. if you write your own generator, then you need to know what
>> > you do, and need to know how to place your symlinks. You are
>> > essentially writing your own unit file installer that way and are
>> > expected to create your own symlinks then.
>>
>> I didn't see it that way: Generated units are just as units installed by 
> some
>> package manager, but specific to the local configuration. So why to make
>> differences?: A unit is a file that is found by systemd (after the 
> generators
>> finished)...
> 
> Nope, that's simply not how they are designed. They are a mechanism
> how to extend the systemd dependency tree and install additional
> nodes in that tree.
> 
> 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.

Sorry, I still don't get it: The only(?) difference is the path where they
(units files) are found, and that the /run directory is volatile. Aren't the
other differences not just "artificial"?

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



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

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

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > Writing a generator is not a typical user would do. It's what a
> > developer of a package would do, and yes, in that case, when you write
> > code you need a bit more understanding of the underpinnings and need
> > to do more work.
>
> systemd.generator(7) could really need some (better/realistic) examples.

I think you assume generators are something they inherently are not.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 11:57, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >> could call "systemctl add-wants --transient" to do the job,
> >> but at that point, that's more pedantic than practical. If you write a
> >> generator, your systemd-fu should be high enough to know and
> >> understand systemd's symlink mechanisms...
> >
> > Precisely. if you write your own generator, then you need to know what
> > you do, and need to know how to place your symlinks. You are
> > essentially writing your own unit file installer that way and are
> > expected to create your own symlinks then.
>
> I didn't see it that way: Generated units are just as units installed by some
> package manager, but specific to the local configuration. So why to make
> differences?: A unit is a file that is found by systemd (after the generators
> finished)...

Nope, that's simply not how they are designed. They are a mechanism
how to extend the systemd dependency tree and install additional
nodes in that tree.

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.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel