Re: [systemd-devel] systemctl start second.service first.service

[Michal Koutný]

Thanks for your exhaustive reply, Jonathon.

On Tue, Jan 08, 2019 at 04:02:47AM +0530, Jonathon Kowalski 
 wrote:
> [...]
> I think systemctl should do something similar to that, internally
> create a transient target unit through manager's bus API, add Wants=
> (which gives it implicit After=) on all unit names passed, and then
> invoke the startup of this target, so that it gets treated as anchor
> job and generates a transaction where all dependencies are ordered
> properly. Hence, I vote for the first option.
I agree, this recycles most of the existing transaction engine logic and
does not bring too many corner cases needing resolution.

> [...] So I vote for both 2 and 1, 2 implemented using the 1st
> approach.
Problem with 2 is that it touches DBus API and hence it should be a well
considered change. I don't think it's good to create such "macro"
functions that would emulate something that could be done by other DBus
methods (create the transient target, add deps for it, start it).

> That said, I do think in practice if units are declared properly dependency
> wise, they should already pull one another in a transaction, which would
> then also take care of ordering deps, and anything that actually needs such
> semantics from systemctl (or through the bus) is already broken.
This is an argument I did not contemplate enough but once you pointed it
out, I cannot agree more :)

Units themselves should specify what they Wants= or Requires= in the
transaction. This may be distributed in another unit, e.g.
- U wants A and B,
- B after A,
- intended usecase is starting U.

The manual invocation of `systemctl start B A` could be then understood
rather as debugging operation.

In this light, it makes a nice sense to me to introduce a new option to
systemctl, that'd make sure a transient target is created and it
aggregates the requested operations.

Management of that unit then can be no special from others because by
passing that unit, user should be expecting such a unit is created.

You've concinced me about variant 1 with the behavior being triggered by
explicit user request.

Michal


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

Re: [systemd-devel] systemctl start second.service first.service

[Jonathon Kowalski]

So I have a comment on the issue, but it's been quite a lot of time since
then (and I happen to know more about systemd than I did back then). I
think this feature is just working around problems in units, and
introducing more complexity for little gain, in particular, while
StartUnits vectorized call is probably the most obvious, it is perhaps the
most complex solution of all three (now introducing the idea of more than
one anchor job for generating a transaction and job sets).

The example given in the report is about smb and nfsd, in that ordering
only matters as long as both are part of a transaction. I presume this was
put in the unit keeping in mind that a target will pull both (which then
causes ordering to be maintained in the generated transaction). I think
systemctl should do something similar to that, internally create a
transient target unit through manager's bus API, add Wants= (which gives it
implicit After=) on all unit names passed, and then invoke the startup of
this target, so that it gets treated as anchor job and generates a
transaction where all dependencies are ordered properly. Hence, I vote for
the first option.

You point out two issues, unclear management of unit, and lack of a
equivalent D-Bus operation to do this, so I guess then PID1 could perhaps
do this itself, when a StartUnits method is invoked, takes the array of all
units, generates a target, adds dependencies, and then generates a
transaction for it as anchor job. It would perhaps need new
RestartUnits/StopUnits/ReloadUnits operations to complement the vectorized
start, and reload-or-restart or try-reload-or-restart equivalents, and I
think all of these can already be expressed through propagative deps in the
target unit, except two key things:

* For {Stop/Restart}Units, systemd would need to gain ConsistsOf=
dependency to be specified in a unit, so that modifying properties of other
units is not needed on fly, which would then propagate the job as it does
today. This also means the current internal fallback to TRY_RESTART on
propagation of restart jobs to not wake up dependencies also needs to be
changed.

* Getting reload-or-restart or try-reload-or-restart to work through
propagation will be tricky, so either their vectorized types need to be
dropped from consideration, or some work has to done to get them in shape.

 So currently, reload-or-restart calls the method ReloadOrRestart, which
will resolve to either JOB_RELOAD_OR_START if target unit has propagation
of reload defined, otherwise JOB_RESTART.

 Now, in transaction, if target supports reload the resolved
JOB_RELOAD_OR_START is collapsed to start job for inactive/deactivating
units and reload job for other units, this means when targets enable reload
propagation, reload-or-restart despite use of PartOf= in target unit does
not propagate restart to units it can. This needs fixing, perhaps through a
new JOB_RELOAD_OR_RESTART which collapses to one of the two, or some other
way of solving it (pointed out by Andrei Borzenkov here:
https://github.com/systemd/systemd/issues/10638). Note that this tuning
happens at call time, as the intent is to decide at method call time, in
functions that are mapped to bus methods, which one of these operations
should be triggered (as user is triggering them after inspecting state from
their perspective), and I think JOB_RELOAD_OR_START will also never appear
in a transaction as it is collapsed to a simpler type before, so same
should hold for JOB_RELOAD_OR_RESTART (TRY variants do, for reload and
restart, as they are intended to be less strict to hold assumptions made
about unit state client side).

 Same holds for try-reload-or-restart, except the function that builds the
logic before collapsing happens could take a bool to resolve these to
either TRY_RESTART or TRY_RELOAD, for each unit.

So for now I guess the stateful types can be dropped that do collapsing
because that is a lot of work, and perhaps some work towards a simple
patchset covering start/stop/restart/reload. So I vote for both 2 and 1, 2
implemented using the 1st approach.

That said, I do think in practice if units are declared properly dependency
wise, they should already pull one another in a transaction, which would
then also take care of ordering deps, and anything that actually needs such
semantics from systemctl (or through the bus) is already broken.

On Monday, January 7, 2019, Michal Koutný  wrote:

> (Bringing up an older one.)
>
> On 1/15/18 2:20 AM, 林自均  wrote:
> > I've filed https://github.com/systemd/systemd/issues/7877 for this.
> There's also accompanying RFE at [1]. I've looked into that and arrived
> at design/implementation crossroads. I'd be happy for any ideas/feedback
> on that GH issue.
>
> Thanks,
> Michal
>
> [1] https://github.com/systemd/systemd/issues/8102
>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Michal Koutný]

(Bringing up an older one.)

On 1/15/18 2:20 AM, 林自均  wrote:
> I've filed https://github.com/systemd/systemd/issues/7877 for this.
There's also accompanying RFE at [1]. I've looked into that and arrived
at design/implementation crossroads. I'd be happy for any ideas/feedback
on that GH issue.

Thanks,
Michal

[1] https://github.com/systemd/systemd/issues/8102




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[林自均]

Hi Lennart,

I've filed https://github.com/systemd/systemd/issues/7877 for this. Thanks
for explain the reason of not document this in the first place.

John Lin

2018-01-13 0:41 GMT+08:00 Lennart Poettering :

> On Do, 11.01.18 17:52, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
>
> > At boot, both would be started as part of the same transaction (same
> > would happen here if you started a third.service that depended on both
> > first.service and second.service, then second.service would always
> > wait). Here second.service is just started individually, and systemd
> > has no idea at that time that first.service is going to be running at
> > all. Given that, it really can't behave any differently (it can't delay
> > the start of second.service to wait for first.service, when as far as
> > it knows first.service may well never get started at all!). It's only
> > after second.service is already running that it sees that first.service
> > will be started, and at that point it's too late to make second.service
> > wait. There really is nothing the init portion could do differently
> > given the semantics of bare "After" (the behavior could be changed in
> > the systemctl binary).
>
> Yupp, this is exactly what happens.
>
> That said, we should probably make the
> multiple-operations-in-a-single-transaction thing happen.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> 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

Re: [systemd-devel] systemctl start second.service first.service

[Lennart Poettering]

On Fr, 12.01.18 00:47, 林自均 (johnl...@gmail.com) wrote:

> How about adding an "--order" option to systemctl? With this option,
> systemctl will sort those units by ordering dependencies before submitting
> them. Although I personally wanted this to be the default behavior, I can
> understand comparability matters.

I figure "--combine" would be a better name, as that's what would
happen then: multiple operations would be combined in one transaction...

But yeah, this would be great to have, it's just a matter of doing it.

Lennart

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

Re: [systemd-devel] systemctl start second.service first.service

[Reindl Harald]

Am 12.01.2018 um 17:49 schrieb Lennart Poettering:

On Fr, 12.01.18 10:13, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 12.01.2018 um 08:12 schrieb Andrei Borzenkov:

On Thu, Jan 11, 2018 at 11:41 PM, Reindl Harald  wrote:


come on - nobody cares about this bullshit bingo about what are jobs, units
and services



I naively believe that understanding software design and how software
works is helpful when discussing said software. May be you are right
and it is not needed anymore, in which case I sincerely apologize -
old habits die hard ...


as long as you strip the relevant parts of a message and are not capable to
operate a mail-coent (just resposnd to the list) please refrain from
additional answers especially since nobody asked *you* at all

until now you did not have any logical argument, you are not the one who
would implement something anything and you don't understand the topic
because you are unwilling to do so - so please go away


Reindl, one more mail like this and you are back on moderation. Your
way of communication may be OK on other mailing lists but it is not
here.


sorry, i was somehow angry that my repsonses don't arrive at all


Moreover, attacking Andrei for not implementing things is very much
mislead, as Andrei contributed a ton of good patches over the years,
and you did no such thing


how can he then recommend that the way to go is Require instead After 
which won't solve any of the mentioned problems and completly ignore how 
irrational the current behavior and especially the way of his repsones 
in this thread are?

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

Re: [systemd-devel] systemctl start second.service first.service

[Lennart Poettering]

On Do, 11.01.18 17:24, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> Ordering dependencies are between jobs. To have any effect here
> systemd must have both start jobs queued concurrently. What is
> unexpected is that multiple services are apparently submitted as
> individual independent jobs, not as single "transaction". I am not
> sure even if there is method to start multiple units concurrently.
> 
> > Is this behavior documented somewhere?
> 
> The systemctl behavior? Not to my best knowledge, at least explicitly.

Yeah, we should document this behaviour. Anyone cares to file a bug?
or even prep a PR?

I figure the original plan was to keep our options open by not
documenting the precise effect, in order that we can change behaviour
here and make it a single transaction, but since we still didn't do
that I figure we should document behaviour here, and when we add this
later do so in an opt-in way via some switch, since such a change of
behaviour would be pretty much a compat breakage at this point.

Lennart

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

Re: [systemd-devel] systemctl start second.service first.service

[Lennart Poettering]

On Do, 11.01.18 21:41, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> Am 11.01.2018 um 20:27 schrieb Andrei Borzenkov:
> > 11.01.2018 21:56, Reindl Harald пишет:
> > > 
> > > it complete unexpected nonsense when i have two services which have a
> > > clear start ordering
> > 
> > "services start ordering" is fundamental misconception. Ordering exists
> > between jobs, not units. Unfortunately, systemd documentation does very
> > little to explain it
> 
> come on - nobody cares about this bullshit bingo about what are jobs, units
> and services

Reindl, please be civil. We put you on moderation before and we will
do it again. Please stop this, this is not helpful.

Lennart

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

Re: [systemd-devel] systemctl start second.service first.service

[Lennart Poettering]

On Do, 11.01.18 17:52, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:

> At boot, both would be started as part of the same transaction (same
> would happen here if you started a third.service that depended on both
> first.service and second.service, then second.service would always
> wait). Here second.service is just started individually, and systemd
> has no idea at that time that first.service is going to be running at
> all. Given that, it really can't behave any differently (it can't delay
> the start of second.service to wait for first.service, when as far as
> it knows first.service may well never get started at all!). It's only
> after second.service is already running that it sees that first.service
> will be started, and at that point it's too late to make second.service
> wait. There really is nothing the init portion could do differently
> given the semantics of bare "After" (the behavior could be changed in
> the systemctl binary).

Yupp, this is exactly what happens.

That said, we should probably make the
multiple-operations-in-a-single-transaction thing happen.

Lennart

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

Re: [systemd-devel] systemctl start second.service first.service

[Lennart Poettering]

eOn Do, 11.01.18 22:30, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 11.01.2018 22:04, Mantas Mikulėnas пишет:
> > 
> > It could, if there was an API call to start multiple jobs at once.
> > (Actually, isn't there one already?...)
> > 
> 
> None I can find in sources.

There is none. There was work on adding one, but it never was completed.

Lennart

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

Re: [systemd-devel] systemctl start second.service first.service

[Lennart Poettering]

On Fr, 12.01.18 10:13, Reindl Harald (h.rei...@thelounge.net) wrote:

> Am 12.01.2018 um 08:12 schrieb Andrei Borzenkov:
> > On Thu, Jan 11, 2018 at 11:41 PM, Reindl Harald  
> > wrote:
> > > 
> > > come on - nobody cares about this bullshit bingo about what are jobs, 
> > > units
> > > and services
> > > 
> > 
> > I naively believe that understanding software design and how software
> > works is helpful when discussing said software. May be you are right
> > and it is not needed anymore, in which case I sincerely apologize -
> > old habits die hard ...
> 
> as long as you strip the relevant parts of a message and are not capable to
> operate a mail-coent (just resposnd to the list) please refrain from
> additional answers especially since nobody asked *you* at all
> 
> until now you did not have any logical argument, you are not the one who
> would implement something anything and you don't understand the topic
> because you are unwilling to do so - so please go away

Reindl, one more mail like this and you are back on moderation. Your
way of communication may be OK on other mailing lists but it is not
here.

Moreover, attacking Andrei for not implementing things is very much
mislead, as Andrei contributed a ton of good patches over the years,
and you did no such thing.

Lennart

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

Re: [systemd-devel] systemctl start second.service first.service

[Reindl Harald]

Am 12.01.2018 um 09:55 schrieb Michael Chapman:

On Fri, 12 Jan 2018, Andrei Borzenkov wrote:

And why does it matter? If unit A can be started without unit B, why
does it matter in which order they are started? If unit A can *not* be
started without unit B, it must tell so using Requires or Requisite.


I actually do think there is merit having this _always_ done with a 
single transaction.


Just because you want ordering doesn't necessarily you care about 
requirements. You may have a set of Type=oneshot units, for instance, 
and you don't particularly care whether any of them fail, but they must 
be run in a particular order


it's simple: Require is just plain wrong in many cases, oneshot or not

* dbmail needs a database
* that can either be postgresql or mysql
* so any unit which Require one of them would be wrong
* systemctl restart mysqld dbmail-imapd
  problem: database goes down while imap still accepts clients
* systemctl restart dbmail-imapd mysqld
  problem: straight after start you take down the database

at boot it would be start mysqld -> start dbmail-imapd
at shutdown it would be stop dbmail-imapd -> stop mysqld

just because "dbmail-imapd" has "After=postgresql mysqld"
only "systemctl restart" can never do the correct thing

you can't Require mysql because it's wrong when postgresql is used
you can't Require postgresql because it's wrong when mysql is used

frankly it makes me tired - i have not enough colored pencils to explain 
it so that people which decide to even not try to understand something 
gasp it

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

Re: [systemd-devel] systemctl start second.service first.service

[Andrei Borzenkov]

On Thu, Jan 11, 2018 at 11:41 PM, Reindl Harald  wrote:
>
> come on - nobody cares about this bullshit bingo about what are jobs, units
> and services
>

I naively believe that understanding software design and how software
works is helpful when discussing said software. May be you are right
and it is not needed anymore, in which case I sincerely apologize -
old habits die hard ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Andrei Borzenkov]

On Fri, Jan 12, 2018 at 7:51 AM, 林自均  wrote:
> Hi Andrei,
>
>> If unit A can be started without unit B, why does it matter in which order
>> they are started?
>
> Are you suggesting that After=/Before= must come with Requires= or similar?

What I say is - After/Before is only used when units are activated
concurrently. If activation of unit A requires that unit B is already
active, using Requires is the most straightforward way to achieve it.
If activation of unit A does not require active unit B - why do you
bother with ordering in the first place?

> I think this breaks the design of making ordering dependencies and
> requirement dependencies orthogonal.
>

How do you come to this conclusion?

The way systemd works is

1. it gets request to activate unit
2. it computes additional units that need to be (de-)activated
following chain of Requires/Wants/Conflicts/...
3. it submits internally additional requests to (de-)activate units
collected at previous step
4. it is using After/Before to decide when to actually execute each request

This looks pretty much orthogonal to me (and notice how I avoided
usage of "job" anywhere) :) Requires et al determine *what* to start
and After/Before determine *when* to start.

> Take smbd.service and nmbd.service for example. smbd.service specifies
> After=nmbd.service, but no requirement dependencies on nmbd.service. It
> means that the 2 services can live without each other, but when the two
> services are starting together, ordering matters.
>

If smbd *needs* nmbd it must also ensure that nmbd is always started
when smbd is started. There could be other ways to ensure it, but most
often people think in terms of boot and shutdown, where this
assumption is true (all "enabled" services are added to initial
transaction). As soon as you allow each service to be managed
individually, you are responsible for expressing proper dependencies;
simple "WantedBy=default.target" is no more enough.

Otherwise either After is redundant or unit definition is incomplete (buggy).

> John Lin
>
> Andrei Borzenkov  於 2018年1月12日 週五 上午11:59寫道：
>>
>> 12.01.2018 03:47, 林自均 пишет:
>> > How about adding an "--order" option to systemctl? With this option,
>> > systemctl will sort those units by ordering dependencies before
>> > submitting
>> > them.
>>
>> And why does it matter? If unit A can be started without unit B, why
>> does it matter in which order they are started? If unit A can *not* be
>> started without unit B, it must tell so using Requires or Requisite.
>>
>> What are you trying to achieve?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Michael Chapman]

On Fri, 12 Jan 2018, Andrei Borzenkov wrote:

12.01.2018 03:47, 林自均 пишет:

How about adding an "--order" option to systemctl? With this option,
systemctl will sort those units by ordering dependencies before submitting
them.


And why does it matter? If unit A can be started without unit B, why
does it matter in which order they are started? If unit A can *not* be
started without unit B, it must tell so using Requires or Requisite.


I actually do think there is merit having this _always_ done with a single 
transaction.


Just because you want ordering doesn't necessarily you care about 
requirements. You may have a set of Type=oneshot units, for instance, and 
you don't particularly care whether any of them fail, but they must be run 
in a particular order. Currently, you need to make sure that order is 
reflected in the systemctl arguments. It would be nice for the order to be 
derived correctly from their ordering dependencies.


With all jobs in a single transaction, you could use systemctl's 
--job-mode=fail option to determine whether the _entire_ transaction is 
safe to be applied. This would honor Conflicts= in units without requiring 
the user to list units in the correct order.


Thinking somewhat further ahead, I can imagine their might even be a 
use-case for having transactions represented in the DBus API. That way a 
client could build a transaction (start this unit, stop that unit, etc.), 
and apply it all at once.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Lennart Poettering]

On Do, 11.01.18 10:59, 林自均 (johnl...@gmail.com) wrote:

> Hi folks,
> 
> I have 2 service unist: first.service and second.service. I configured
> "After=first.service" in second.service. Both services are "Type=oneshot".
> 
> If I execute:
> 
> # systemctl start first.service second.service
> 
> The ordering dependency will work, i.e. second.service will start after
> first.service.
> 
> However, if I execute:
> 
> # systemctl start second.service first.service
> 
> first.service and second.service will start at the same time.
> 
> Is this behavior documented somewhere? Thanks!

Currently, "systemctl start foo bar baz" is equivalent to "systemctl
start foo && systemctl start bar && systemctl start baz" in respect to
ordering.

And yeah, we should handle this differently, and make one transaction
of such an expression, so that the defined ordering between the jobs
is honoured here. There has been some work to make this happen a while
back, but it never got anywhere.

Lennart

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

Re: [systemd-devel] systemctl start second.service first.service

[Jérémy Rosen]

I had a quick look at the systemd dbus API (which I assume is close to 
what systemctl uses) and there are no easy way to queue multiple 
"starts" into one job


There is a single StartUnit (+varient) method which can only take a 
single unit. no queuing mechanism, way to create ajob without triggering 
it or other workaround


So yes, to get this to work as expected a new API probably needs to be 
added.


Alternatively, systemctl could create an Transient, temporary unit with 
the correct relationship (Wants, Conflicts, ReloadPropagatedFrom) and 
start that unit, pulling in the ones on the command line. Not sure if 
that's a good approch. Just stating that it's possible...


On 12/01/2018 14:11, Simon McVittie wrote:

On Thu, 11 Jan 2018 at 21:41:54 +0100, Reindl Harald wrote:

come on - nobody cares about this bullshit bingo about what are jobs, units
and services

Please try to be polite when you are in a situation where you could be
perceived as representing a community. Responses like this to discussion
of a technical issue do not help systemd's reputation, and using jargon
terms precisely is a useful way to describe how code works.

For what it's worth, I think I agree with the technical point you were
making, which (if I understand correctly) is that it would be better for
each "systemctl start" invocation to create a single transaction (job)
that will start all the units named on the command-line in an order
chosen by the systemd manager to respect their Before/After ordering.

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


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Simon McVittie]

On Thu, 11 Jan 2018 at 21:41:54 +0100, Reindl Harald wrote:
> come on - nobody cares about this bullshit bingo about what are jobs, units
> and services

Please try to be polite when you are in a situation where you could be
perceived as representing a community. Responses like this to discussion
of a technical issue do not help systemd's reputation, and using jargon
terms precisely is a useful way to describe how code works.

For what it's worth, I think I agree with the technical point you were
making, which (if I understand correctly) is that it would be better for
each "systemctl start" invocation to create a single transaction (job)
that will start all the units named on the command-line in an order
chosen by the systemd manager to respect their Before/After ordering.

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

Re: [systemd-devel] systemctl start second.service first.service

[Reindl Harald]

Am 12.01.2018 um 08:12 schrieb Andrei Borzenkov:

On Thu, Jan 11, 2018 at 11:41 PM, Reindl Harald  wrote:


come on - nobody cares about this bullshit bingo about what are jobs, units
and services



I naively believe that understanding software design and how software
works is helpful when discussing said software. May be you are right
and it is not needed anymore, in which case I sincerely apologize -
old habits die hard ...


as long as you strip the relevant parts of a message and are not capable 
to operate a mail-coent (just resposnd to the list) please refrain from 
additional answers especially since nobody asked *you* at all


until now you did not have any logical argument, you are not the one who 
would implement something anything and you don't understand the topic 
because you are unwilling to do so - so please go away

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

Re: [systemd-devel] systemctl start second.service first.service

[Reindl Harald]

Am 12.01.2018 um 04:59 schrieb Andrei Borzenkov:

12.01.2018 03:47, 林自均 пишет:

How about adding an "--order" option to systemctl? With this option,
systemctl will sort those units by ordering dependencies before submitting
them.


And why does it matter? If unit A can be started without unit B, why
does it matter in which order they are started? If unit A can *not* be
started without unit B, it must tell so using Requires or Requisite.

What are you trying to achieve?


there is a difference between Requires/After

After is optional, means the service *can* work without the other *but* 
if both are enabled there is a defined ordering at boot as well as at 
shutdown


with your broken logic Before/After would be completly useless because 
why would you care at boot time when you don't in case of restarts?


P.S.: fix your mail client
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[林自均]

Hi Andrei,

> If unit A can be started without unit B, why does it matter in which
order they are started?

Are you suggesting that After=/Before= must come with Requires= or similar?
I think this breaks the design of making ordering dependencies and
requirement dependencies orthogonal.

Take smbd.service and nmbd.service for example. smbd.service
specifies After=nmbd.service, but no requirement dependencies
on nmbd.service. It means that the 2 services can live without each other,
but when the two services are starting together, ordering matters.

John Lin

Andrei Borzenkov  於 2018年1月12日 週五 上午11:59寫道：

> 12.01.2018 03:47, 林自均 пишет:
> > How about adding an "--order" option to systemctl? With this option,
> > systemctl will sort those units by ordering dependencies before
> submitting
> > them.
>
> And why does it matter? If unit A can be started without unit B, why
> does it matter in which order they are started? If unit A can *not* be
> started without unit B, it must tell so using Requires or Requisite.
>
> What are you trying to achieve?
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Andrei Borzenkov]

12.01.2018 03:47, 林自均 пишет:
> How about adding an "--order" option to systemctl? With this option,
> systemctl will sort those units by ordering dependencies before submitting
> them. 

And why does it matter? If unit A can be started without unit B, why
does it matter in which order they are started? If unit A can *not* be
started without unit B, it must tell so using Requires or Requisite.

What are you trying to achieve?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[林自均]

How about adding an "--order" option to systemctl? With this option,
systemctl will sort those units by ordering dependencies before submitting
them. Although I personally wanted this to be the default behavior, I can
understand comparability matters.

John Lin

Reindl Harald  於 2018年1月12日 週五 上午4:57寫道：

>
> Am 11.01.2018 um 20:27 schrieb Andrei Borzenkov:
> > 11.01.2018 21:56, Reindl Harald пишет:
> >>
> >> it complete unexpected nonsense when i have two services which have a
> >> clear start ordering
> >
> > "services start ordering" is fundamental misconception. Ordering exists
> > between jobs, not units. Unfortunately, systemd documentation does very
> > little to explain it
>
> come on - nobody cares about this bullshit bingo about what are jobs,
> units and services
>
> "systemctl restart a.service b.service" are two jobs when you want it to
> call that way witch a implicit ordering defined with After/Before when
> you want it to call job
>
> just because i give you 2 tasks at the same time you are not supposed to
> do them at the same time when you look at them and see a benefit for
> both in doing it in a specific order
>
> *please* forget the bullshit bingo
>
> when i have to look into avery unit if it contains After/Before to fire
> up the restarts ina correct order by hand something is broken - it's
> really that simple
> ___
> 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

Re: [systemd-devel] systemctl start second.service first.service

[Reindl Harald]

Am 11.01.2018 um 20:27 schrieb Andrei Borzenkov:

11.01.2018 21:56, Reindl Harald пишет:


it complete unexpected nonsense when i have two services which have a
clear start ordering


"services start ordering" is fundamental misconception. Ordering exists
between jobs, not units. Unfortunately, systemd documentation does very
little to explain it


come on - nobody cares about this bullshit bingo about what are jobs, 
units and services


"systemctl restart a.service b.service" are two jobs when you want it to 
call that way witch a implicit ordering defined with After/Before when 
you want it to call job


just because i give you 2 tasks at the same time you are not supposed to 
do them at the same time when you look at them and see a benefit for 
both in doing it in a specific order


*please* forget the bullshit bingo

when i have to look into avery unit if it contains After/Before to fire 
up the restarts ina correct order by hand something is broken - it's 
really that simple

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

Re: [systemd-devel] systemctl start second.service first.service

[Andrei Borzenkov]

11.01.2018 21:56, Reindl Harald пишет:
> 
> it complete unexpected nonsense when i have two services which have a
> clear start ordering 

"services start ordering" is fundamental misconception. Ordering exists
between jobs, not units. Unfortunately, systemd documentation does very
little to explain it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Reindl Harald]

Am 11.01.2018 um 20:30 schrieb Andrei Borzenkov:

11.01.2018 22:04, Mantas Mikulėnas пишет:


It could, if there was an API call to start multiple jobs at once.
(Actually, isn't there one already?...)



None I can find in sources (fdo is down for me currently)


who cares about fdo when it's hosted on github for a long time now?
https://github.com/systemd
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Andrei Borzenkov]

11.01.2018 22:04, Mantas Mikulėnas пишет:
> 
> It could, if there was an API call to start multiple jobs at once.
> (Actually, isn't there one already?...)
> 

None I can find in sources (fdo is down for me currently).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Mantas Mikulėnas]

On Thu, Jan 11, 2018, 20:11 Uoti Urpala  wrote:

> On Thu, 2018-01-11 at 15:34 +0100, Reindl Harald wrote:
> > Am 11.01.2018 um 15:25 schrieb Uoti Urpala:
> > > I'd guess this is due to systemctl starting each listed unit
> > > independently rather than as a single transaction. Thus, the second
> > > version first starts second.service without first.service being active
> > > at all. Since there's only an After relationship, not Wants/Requires,
> > > second.service will immediately start. Then systemctl starts
> > > first.service; since second.service is already running, there's nothing
> > > the After relationship could affect
> >
> > but why?
> >
> > the one "After=" should be enough to have a clear ordering of stop/start
> > both as it happens in shutdown/boot
>
> At boot, both would be started as part of the same transaction (same
> would happen here if you started a third.service that depended on both
> first.service and second.service, then second.service would always
> wait). Here second.service is just started individually, and systemd
> has no idea at that time that first.service is going to be running at
> all. Given that, it really can't behave any differently (it can't delay
> the start of second.service to wait for first.service, when as far as
> it knows first.service may well never get started at all!). It's only
> after second.service is already running that it sees that first.service
> will be started, and at that point it's too late to make second.service
> wait. There really is nothing the init portion could do differently
> given the semantics of bare "After" (the behavior could be changed in
> the systemctl binary).


It could, if there was an API call to start multiple jobs at once.
(Actually, isn't there one already?...)
-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl start second.service first.service

[Reindl Harald]

Am 11.01.2018 um 16:52 schrieb Uoti Urpala:

On Thu, 2018-01-11 at 15:34 +0100, Reindl Harald wrote:

Am 11.01.2018 um 15:25 schrieb Uoti Urpala:

I'd guess this is due to systemctl starting each listed unit
independently rather than as a single transaction. Thus, the second
version first starts second.service without first.service being active
at all. Since there's only an After relationship, not Wants/Requires,
second.service will immediately start. Then systemctl starts
first.service; since second.service is already running, there's nothing
the After relationship could affect


but why?

the one "After=" should be enough to have a clear ordering of stop/start
both as it happens in shutdown/boot


At boot, both would be started as part of the same transaction (same
would happen here if you started a third.service that depended on both
first.service and second.service, then second.service would always
wait). Here second.service is just started individually, and systemd
has no idea at that time that first.service is going to be running at
all


that's a design error and don't follow the least surprise principle and 
until today i did not even consider that to be possible at all



Given that, it really can't behave any differently (it can't delay
the start of second.service to wait for first.service, when as far as
it knows first.service may well never get started at all!). It's only
after second.service is already running that it sees that first.service
will be started, and at that point it's too late to make second.service
wait. There really is nothing the init portion could do differently
given the semantics of bare "After" (the behavior could be changed in
the systemctl binary)
surely - systemctl could tell PID1 the whole list at once instead 
blindly fire up individual restart commands or *at least* it could make 
a ordering between the listed units from the restart command


it complete unexpected nonsense when i have two services which have a 
clear start ordering and may depend one from the other because you are 
even not able to do the right thing in your systemcl command because 
stop and start need the reverse ordner and so "restat a b c" is always 
wrong in one of both cases

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

Re: [systemd-devel] systemctl start second.service first.service

[Uoti Urpala]

On Thu, 2018-01-11 at 15:34 +0100, Reindl Harald wrote:
> Am 11.01.2018 um 15:25 schrieb Uoti Urpala:
> > I'd guess this is due to systemctl starting each listed unit
> > independently rather than as a single transaction. Thus, the second
> > version first starts second.service without first.service being active
> > at all. Since there's only an After relationship, not Wants/Requires,
> > second.service will immediately start. Then systemctl starts
> > first.service; since second.service is already running, there's nothing
> > the After relationship could affect
> 
> but why?
> 
> the one "After=" should be enough to have a clear ordering of stop/start 
> both as it happens in shutdown/boot

At boot, both would be started as part of the same transaction (same
would happen here if you started a third.service that depended on both
first.service and second.service, then second.service would always
wait). Here second.service is just started individually, and systemd
has no idea at that time that first.service is going to be running at
all. Given that, it really can't behave any differently (it can't delay
the start of second.service to wait for first.service, when as far as
it knows first.service may well never get started at all!). It's only
after second.service is already running that it sees that first.service
will be started, and at that point it's too late to make second.service
wait. There really is nothing the init portion could do differently
given the semantics of bare "After" (the behavior could be changed in
the systemctl binary).

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

Re: [systemd-devel] systemctl start second.service first.service

[Reindl Harald]

Am 11.01.2018 um 15:25 schrieb Uoti Urpala:

On Thu, 2018-01-11 at 10:59 +, 林自均 wrote:

I have 2 service unist: first.service and second.service. I
configured "After=first.service" in second.service. Both services are
"Type=oneshot".

If I execute:

# systemctl start first.service second.service

The ordering dependency will work, i.e. second.service will start
after first.service.

However, if I execute:

# systemctl start second.service first.service

first.service and second.service will start at the same time.

Is this behavior documented somewhere? Thanks!


I'd guess this is due to systemctl starting each listed unit
independently rather than as a single transaction. Thus, the second
version first starts second.service without first.service being active
at all. Since there's only an After relationship, not Wants/Requires,
second.service will immediately start. Then systemctl starts
first.service; since second.service is already running, there's nothing
the After relationship could affect


but why?

the one "After=" should be enough to have a clear ordering of stop/start 
both as it happens in shutdown/boot

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

Re: [systemd-devel] systemctl start second.service first.service

[Uoti Urpala]

On Thu, 2018-01-11 at 10:59 +, 林自均 wrote:
> I have 2 service unist: first.service and second.service. I
> configured "After=first.service" in second.service. Both services are
> "Type=oneshot".
> 
> If I execute:
> 
> # systemctl start first.service second.service
> 
> The ordering dependency will work, i.e. second.service will start
> after first.service.
> 
> However, if I execute:
> 
> # systemctl start second.service first.service
> 
> first.service and second.service will start at the same time.
> 
> Is this behavior documented somewhere? Thanks!

I'd guess this is due to systemctl starting each listed unit
independently rather than as a single transaction. Thus, the second
version first starts second.service without first.service being active
at all. Since there's only an After relationship, not Wants/Requires,
second.service will immediately start. Then systemctl starts
first.service; since second.service is already running, there's nothing
the After relationship could affect.

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

Re: [systemd-devel] systemctl start second.service first.service

[Andrei Borzenkov]

On Thu, Jan 11, 2018 at 1:59 PM, 林自均  wrote:
> Hi folks,
>
> I have 2 service unist: first.service and second.service. I configured
> "After=first.service" in second.service. Both services are "Type=oneshot".
>
> If I execute:
>
> # systemctl start first.service second.service
>
> The ordering dependency will work, i.e. second.service will start after
> first.service.
>
> However, if I execute:
>
> # systemctl start second.service first.service
>
> first.service and second.service will start at the same time.
>

Ordering dependencies are between jobs. To have any effect here
systemd must have both start jobs queued concurrently. What is
unexpected is that multiple services are apparently submitted as
individual independent jobs, not as single "transaction". I am not
sure even if there is method to start multiple units concurrently.

> Is this behavior documented somewhere?

The systemctl behavior? Not to my best knowledge, at least explicitly.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel