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

[林自均]

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]

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]

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

[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.

[Reindl Harald]

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]

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]

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]

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]

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

[林自均]

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]

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?

[林自均]

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]

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]

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]

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]

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)]

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]

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.

[Reindl Harald]

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)]

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]

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]

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]

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

[Reindl Harald]

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]

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

[Reindl Harald]

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]

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]

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 [phone]
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]

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

[Mantas Mikulėnas]

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?...)

[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).

[Reindl Harald]

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]

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]

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

[林自均]

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]

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