Discussion:
systemctl start second.service first.service
(too old to reply)
林自均
2018-01-11 10:59:55 UTC
Permalink
Raw Message
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!

John Lin
Andrei Borzenkov
2018-01-11 14:24:05 UTC
Permalink
Raw Message
Post by 林自均
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".
# systemctl start first.service second.service
The ordering dependency will work, i.e. second.service will start after
first.service.
# 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.
Post by 林自均
Is this behavior documented somewhere?
The systemctl behavior? Not to my best knowledge, at least explicitly.
Lennart Poettering
2018-01-12 16:38:54 UTC
Permalink
Raw Message
Post by Andrei Borzenkov
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.
Post by 林自均
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
Uoti Urpala
2018-01-11 14:25:27 UTC
Permalink
Raw Message
Post by 林自均
I have 2 service unist: first.service and second.service. I
configured "After=first.service" in second.service. Both services are
"Type=oneshot".
# systemctl start first.service second.service
The ordering dependency will work, i.e. second.service will start
after first.service.
# 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.
Reindl Harald
2018-01-11 14:34:38 UTC
Permalink
Raw Message
Post by Uoti Urpala
Post by 林自均
I have 2 service unist: first.service and second.service. I
configured "After=first.service" in second.service. Both services are
"Type=oneshot".
# systemctl start first.service second.service
The ordering dependency will work, i.e. second.service will start
after first.service.
# 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
Uoti Urpala
2018-01-11 15:52:44 UTC
Permalink
Raw Message
Post by Reindl Harald
Post by 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).
Reindl Harald
2018-01-11 18:56:41 UTC
Permalink
Raw Message
Post by Uoti Urpala
Post by Reindl Harald
Post by 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
Post by Uoti Urpala
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
Andrei Borzenkov
2018-01-11 19:27:19 UTC
Permalink
Raw Message
Post by 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.
Reindl Harald
2018-01-11 20:41:54 UTC
Permalink
Raw Message
Post by Andrei Borzenkov
Post by 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
林自均
2018-01-12 00:47:05 UTC
Permalink
Raw Message
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
Post by Reindl Harald
Post by Andrei Borzenkov
Post by 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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Andrei Borzenkov
2018-01-12 03:59:27 UTC
Permalink
Raw Message
Post by 林自均
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?
林自均
2018-01-12 04:51:36 UTC
Permalink
Raw Message
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
Post by 林自均
How about adding an "--order" option to systemctl? With this option,
systemctl will sort those units by ordering dependencies before
submitting
Post by 林自均
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?
Andrei Borzenkov
2018-01-12 07:11:09 UTC
Permalink
Raw Message
Post by 林自均
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?
Post by 林自均
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.
Post by 林自均
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).
Post by 林自均
John Lin
Post by 林自均
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?
Reindl Harald
2018-01-12 04:55:22 UTC
Permalink
Raw Message
Post by Andrei Borzenkov
Post by 林自均
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
Michael Chapman
2018-01-12 08:55:32 UTC
Permalink
Raw Message
Post by Andrei Borzenkov
Post by 林自均
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.
Reindl Harald
2018-01-12 09:48:48 UTC
Permalink
Raw Message
Post by Michael Chapman
Post by Andrei Borzenkov
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
Boyce, Kevin P [US] (AS)
2018-01-15 13:39:14 UTC
Permalink
Raw Message
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
Why wouldn't the mysql/postgres/mariadb packager have a section as follows:
[Install]
Alias=database.service

Then you could have other services reference the dependency on database.service. I think this would work much like the display-manager.service. Not everyone uses gdm, some use lightdm, kdm, etc. I expect it work work the same way.

Kevin
Mantas Mikulėnas
2018-01-15 14:19:02 UTC
Permalink
Raw Message
On Mon, Jan 15, 2018 at 3:39 PM, Boyce, Kevin P [US] (AS) <
Post by Reindl Harald
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
[Install]
Alias=database.service
Then you could have other services reference the dependency on
database.service. I think this would work much like the
display-manager.service. Not everyone uses gdm, some use lightdm, kdm,
etc. I expect it work work the same way.
No, they're different.

Display managers are exclusive – there's usually only one per system. But
the same system could easily run several different databases at once –
MySQL, Postgres, Firebird do not conflict with each other. So an alias
would prohibit that.

If a program has selectable database backends, I would say it's up to the
sysadmin to define dependencies as well. `systemctl add-requires
my-app.service mysql.service` would do the job. Or the app could ship a
"generator" (similar to the existing fstab-generator, nfs-generator,
openvpn-generator...) which adds those dependencies dynamically.
--
Mantas Mikulėnas
Reindl Harald
2018-01-15 14:28:47 UTC
Permalink
Raw Message
Post by Boyce, Kevin P [US] (AS)
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
[Install]
Alias=database.service
Then you could have other services reference the dependency on database.service. I think this would work much like the display-manager.service. Not everyone uses gdm, some use lightdm, kdm, etc. I expect it work work the same way.
because that is just a workaround caused by unexpected behavior?

because it would need to be implemented in all unit-files across
distributions including user-overrides?

because restart of services with requires is not that funny anyways

because it should not be needed and is *only one* sample case while the
problem is a greater one where your idea don't scale at all

come on and solve the call below that way while at boot and shutdown
they all get started/stoppe din right order automatically!

systemctl condrestart acpid alsa-state apcupsd asterisk asteriskweb
avahi-daemon clamav-milter clamd clamd-sa crond cups dbmail-imapd
dbmail-lmtpd dbmail-pop3d dbmail-timsieved dhcpd dhcpd-guest
dhcpd-vmware dm-event dnsmasq dovecot forward-flow-home forward-hosting
haveged hostapd hostapd-guest httpd imapproxy irqbalance jabber
lm_sensors lvm2-lvmetad mailgraph mdmonitor mediatomb
monitor-dbmail-imapd monitor-dbmail-lmtpd monitor-dbmail-pop3d
monitor-httpd mpdscribble named netatalk network-wan-bridge ntpd openvpn
openvpn-as openvpn-flow openvpn-io openvpn-rh openvpn-server
openvpn-south panel postfix postgrey preload pulsed pure-ftpd rbldnsd
replication rngd rsyncd rsyslog serverstatus smartd smb smokeping
spamassassin spamassassin-debug spamassassin-submission spamass-milter
spamass-milter-submission sshd trafficserver udisks2 unbound upower
vmtoolsd vnstat xinetd
Boyce, Kevin P [US] (AS)
2018-01-15 14:36:30 UTC
Permalink
Raw Message
come on and solve the call below that way while at boot and shutdown they all get started/stoppe din right order automatically!
You sure do have a funny way of asking for help! Not saying you're wrong, just probably not the most productive way to get the result you want from people.

Kevin
Reindl Harald
2018-01-15 15:21:00 UTC
Permalink
Raw Message
Post by Boyce, Kevin P [US] (AS)
come on and solve the call below that way while at boot and shutdown they all get started/stoppe din right order automatically!
You sure do have a funny way of asking for help! Not saying you're wrong, just probably not the most productive way to get the result you want from people
i just don't like "hey look how easy you can solve something with a
specific workaround" which don't consider the root cause and that doing
so would end in the same cruft as all the thousands of initscripts and
hacks systemd aimed to replace in a clean way

Reindl Harald
2018-01-15 14:30:14 UTC
Permalink
Raw Message
Post by Boyce, Kevin P [US] (AS)
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
[Install]
Alias=database.service
Then you could have other services reference the dependency on database.service. I think this would work much like the display-manager.service. Not everyone uses gdm, some use lightdm, kdm, etc. I expect it work work the same way
and what do you do on a server which is running postgresql *and* mysql
both are not exlusive at all!
Lennart Poettering
2018-01-12 17:00:39 UTC
Permalink
Raw Message
Post by 林自均
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
Reindl Harald
2018-01-12 09:13:49 UTC
Permalink
Raw Message
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
Lennart Poettering
2018-01-12 16:49:02 UTC
Permalink
Raw Message
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
Reindl Harald
2018-01-12 16:52:25 UTC
Permalink
Raw Message
Post by Lennart Poettering
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
Post by Lennart Poettering
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?
Simon McVittie
2018-01-12 13:11:32 UTC
Permalink
Raw Message
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
Jérémy Rosen
2018-01-12 13:15:42 UTC
Permalink
Raw Message
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...
Post by Simon McVittie
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
SMILE <http://www.smile.eu/>

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


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

email ***@smile.fr <mailto:***@smile.fr>
phone +33141402967
url http://www.smile.eu

Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>


Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planÚte, n'imprimez ce mail que si c'est nécessaire
Lennart Poettering
2018-01-12 16:35:08 UTC
Permalink
Raw Message
Post by Andrei Borzenkov
Post by 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
Mantas Mikulėnas
2018-01-11 19:04:14 UTC
Permalink
Raw Message
Post by Uoti Urpala
Post by Reindl Harald
Post by 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 <***@gmail.com>
Sent from my phone
Andrei Borzenkov
2018-01-11 19:30:48 UTC
Permalink
Raw Message
Post by 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).
Reindl Harald
2018-01-11 20:08:17 UTC
Permalink
Raw Message
Post by Andrei Borzenkov
Post by 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
Lennart Poettering
2018-01-12 16:42:25 UTC
Permalink
Raw Message
Post by 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
Lennart Poettering
2018-01-12 16:41:34 UTC
Permalink
Raw Message
Post by Uoti Urpala
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
林自均
2018-01-15 01:20:00 UTC
Permalink
Raw Message
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
Post by Lennart Poettering
Post by Uoti Urpala
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering
2018-01-12 13:20:31 UTC
Permalink
Raw Message
Post by 林自均
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".
# systemctl start first.service second.service
The ordering dependency will work, i.e. second.service will start after
first.service.
# 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
Loading...