[systemd-devel] Does "runlevel" ever show 6 as the current runlevel?

[林自均]

Hi folks,

I know runlevel is a out-of-date concept, but I am still a bit curious
about the current support of runlevel in systemd. If I understand
correctly, the runlevel is updated via "systemd-update-utmp". After I check
the source code, I think "systemd-update-utmp" has the following behavior:

- "systemd-update-utmp reboot": update with ut_type=BOOT_TIME and ut_pid=0.
- "systemd-update-utmp shutdown": update with ut_type=RUN_LVL and ut_pid=0.
- "systemd-update-utmp runlevel": update with ut_type=RUN_LVL and
ut_pid=(runlevel, prev-runlevel), where runlevel may be 1, 3, 5.

Since I didn't see the runlevel will be updated to 6 anywhere, may I ask if
the current behavior of "runlevel" command will show 6, indicating that the
system is rebooting?

Thank you.

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

Re: [systemd-devel] [Install] section of symlinked unit file ignored if drop-in file is used

[林自均]

Hi John,

I can reproduced your problem on systemd v236 to v238, but not v235. I
think it's because from v236 to v238 contains the commit in
https://github.com/systemd/systemd/pull/7158. However, it seems that the
commit "d04a93864d" in the git repo fixes the issue. Therefore, you can
expect that the next systemd version (v239) won't have the issue then.

John Lin

林自均 <johnl...@gmail.com> 於 2018年5月23日 週三 下午10:32寫道：

> Hi John,
>
> I'm not sure whether this issue is because of
> https://github.com/systemd/systemd/pull/7158 or not. I will figure it
> out. Thanks.
>
> John Lin
>
> John Gallagher <john.gallag...@delphix.com> 於 2018年5月24日 週四 上午8:07寫道：
>
>> If I have a unit file for a service that lives off the unit file
>> search path, I can link it, and then enable it using the service name
>> instead of the full path of the unit file:
>>
>> $ cat foo.service
>> [Service]
>> Type=simple
>> ExecStart=/bin/sleep 1
>>
>> [Install]
>> WantedBy=multi-user.target
>> $ sudo systemctl link ~/foo.service
>> Created symlink /etc/systemd/system/foo.service →
>> /export/home/delphix/foo.service.
>> $ sudo systemctl enable foo
>> Created symlink
>> /etc/systemd/system/multi-user.target.wants/foo.service →
>> /export/home/delphix/foo.service.
>>
>> If I add a drop-in file for the service though, enabling the service
>> using the service name does not behave the same way:
>>
>> $ cat /etc/systemd/system/foo.service.d/env.conf
>> [Service]
>> Environment=FOO=bar
>> $ sudo systemctl enable foo
>> The unit files have no installation config (WantedBy, RequiredBy, Also,
>> Alias
>> settings in the [Install] section, and DefaultInstance for template
>> units).
>> This means they are not meant to be enabled using systemctl.
>> Possible reasons for having this kind of units are:
>> 1) A unit may be statically enabled by being symlinked from another unit's
>>.wants/ or .requires/ directory.
>> 2) A unit's purpose may be to act as a helper for some other unit which
>> has
>>a requirement dependency on it.
>> 3) A unit may be started when needed via activation (socket, path, timer,
>>D-Bus, udev, scripted systemctl call, ...).
>> 4) In case of template units, the unit is meant to be enabled with some
>>instance name specified.
>>
>> I get the warning above, and the expected link in
>> /etc/systemd/system/multi-user.target.wants/ is not created. I can
>> work around this behavior by doing the enable using the path of the
>> unit file:
>>
>> $ sudo systemctl enable ~/foo.service
>> Created symlink
>> /etc/systemd/system/multi-user.target.wants/foo.service →
>> /export/home/delphix/foo.service.
>>
>> The [Install] section of the unit file being ignored or respected
>> based on the presence or absence of a drop-in file seems inconsistent
>> to me, but I am fairly new to systemd, so I may be missing something.
>> Is this behavior expected?
>>
>> Thanks,
>> John
>> ___
>> 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] [Install] section of symlinked unit file ignored if drop-in file is used

[林自均]

Hi John,

I'm not sure whether this issue is because of
https://github.com/systemd/systemd/pull/7158 or not. I will figure it out.
Thanks.

John Lin

John Gallagher  於 2018年5月24日 週四 上午8:07寫道：

> If I have a unit file for a service that lives off the unit file
> search path, I can link it, and then enable it using the service name
> instead of the full path of the unit file:
>
> $ cat foo.service
> [Service]
> Type=simple
> ExecStart=/bin/sleep 1
>
> [Install]
> WantedBy=multi-user.target
> $ sudo systemctl link ~/foo.service
> Created symlink /etc/systemd/system/foo.service →
> /export/home/delphix/foo.service.
> $ sudo systemctl enable foo
> Created symlink
> /etc/systemd/system/multi-user.target.wants/foo.service →
> /export/home/delphix/foo.service.
>
> If I add a drop-in file for the service though, enabling the service
> using the service name does not behave the same way:
>
> $ cat /etc/systemd/system/foo.service.d/env.conf
> [Service]
> Environment=FOO=bar
> $ sudo systemctl enable foo
> The unit files have no installation config (WantedBy, RequiredBy, Also,
> Alias
> settings in the [Install] section, and DefaultInstance for template units).
> This means they are not meant to be enabled using systemctl.
> Possible reasons for having this kind of units are:
> 1) A unit may be statically enabled by being symlinked from another unit's
>.wants/ or .requires/ directory.
> 2) A unit's purpose may be to act as a helper for some other unit which has
>a requirement dependency on it.
> 3) A unit may be started when needed via activation (socket, path, timer,
>D-Bus, udev, scripted systemctl call, ...).
> 4) In case of template units, the unit is meant to be enabled with some
>instance name specified.
>
> I get the warning above, and the expected link in
> /etc/systemd/system/multi-user.target.wants/ is not created. I can
> work around this behavior by doing the enable using the path of the
> unit file:
>
> $ sudo systemctl enable ~/foo.service
> Created symlink
> /etc/systemd/system/multi-user.target.wants/foo.service →
> /export/home/delphix/foo.service.
>
> The [Install] section of the unit file being ignored or respected
> based on the presence or absence of a drop-in file seems inconsistent
> to me, but I am fairly new to systemd, so I may be missing something.
> Is this behavior expected?
>
> Thanks,
> John
> ___
> 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] Does systemd-tmpfiles create hard links?

[林自均]

Hi Lennart,

Thanks for the quick response. I filed
https://github.com/systemd/systemd/issues/8860.

John Lin

Lennart Poettering <lenn...@poettering.net> 於 2018年4月30日 週一 下午7:40 寫道：

> On Mo, 30.04.18 10:47, 林自均 (johnl...@gmail.com) wrote:
>
> > Hi folks,
> >
> > According to tmpfiles.d(5), the type "L" creates symbolic links. But I
> > can't find any type to create hard links. Did I miss anything? Thanks!
>
> It does not. So far nobody requested it and a usecase wasn't obvious
> to us. I see no reason not to add that though. Hence, if you need
> this, then please file an RFE issue for it on github, or even better
> provide a patch!
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Does systemd-tmpfiles create hard links?

[林自均]

Hi folks,

According to tmpfiles.d(5), the type "L" creates symbolic links. But I
can't find any type to create hard links. Did I miss anything? Thanks!

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

Re: [systemd-devel] Create a target unit to start & stop a group of services

[林自均]

Hi Zbyszek,

Thank you for your explanation.

However, I found that Conflicts= will be a good choice for me:

# /etc/systemd/system/my-apps-start.target
[Unit]
Wants=docker.service sshd.service mongodb.service

# /etc/systemd/system/my-apps-stop.target
[Unit]
Conflicts=docker.service sshd.service mongodb.service
After=docker.service sshd.service mongodb.service

Then

systemctl start my-apps-start.target # starts all my apps
systemctl start my-apps-stop.target # stops all my apps

And both operations are sync, i.e. will wait for all apps to be
started/stopped before systemctl exits.

Thank you all for solving my problems.

John Lin

Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> 於 2018年3月7日 週三 下午8:48寫道：

> On Tue, Mar 06, 2018 at 03:07:30AM +, 林自均 wrote:
> > Anyone?
> >
> > John Lin
> >
> > 林自均 <johnl...@gmail.com> 於 2018年2月27日 週二 下午6:20寫道：
> >
> > > Hi Jérémy,
> > >
> > > Thank you, but I read the section "Mapping of unit properties to their
> > > inverses" in the man page
> > > https://www.freedesktop.org/software/systemd/man/systemd.unit.html and
> > > then found out the PropagatesReloadTo= and ReloadPropagatedFrom= are
> > > inverses to each other and both can be configured in a unit file. I was
> > > wondering why PartOf= and ConsistsOf= are not the case. Thank you.
>
> No particular reason, just noobody got around to implementing the
> parsing of that option. Shouldn't be too hard though.
>
> Zbyszek
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Create a target unit to start & stop a group of services

[林自均]

Anyone?

John Lin

林自均 <johnl...@gmail.com> 於 2018年2月27日 週二 下午6:20寫道：

> Hi Jérémy,
>
> Thank you, but I read the section "Mapping of unit properties to their
> inverses" in the man page
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html and
> then found out the PropagatesReloadTo= and ReloadPropagatedFrom= are
> inverses to each other and both can be configured in a unit file. I was
> wondering why PartOf= and ConsistsOf= are not the case. Thank you.
>
> John Lin
>
>
> Jérémy Rosen <jeremy.ro...@smile.fr> 於 2018年2月27日 週二 下午4:35寫道：
>
>>
>>
>> On 27/02/2018 02:49, 林自均 wrote:
>>
>> Hi both Michal,
>>
>> Thank you for the quick responses! I think I will keep on using the tedious
>> PartOf= directive.
>>
>> However, may I ask why ConsistsOf= is readonly? If I can use it in my
>> "my-apps.target", that would be great.
>>
>> Because "ConsistsOf" doesn't exist in the way you think it does...
>>
>> Every relation between units (Wants, Before, PartOf) needs to have an
>> internal, reverse relation for accounting purpose
>>
>> That reverse relation is usually an internal detail, but it is handy to
>> expose
>> it in "systemctl show" & co.
>>
>> So that's what you see, an internal property exposed for ease-of-use. not
>> an
>> external, user configurable property
>>
>>
>>
>> John Lin
>>
>> Michal Koutný <mkou...@suse.com> <mkou...@suse.com> 於 2018年2月26日 週一 下午7:28寫道：
>>
>>
>>
>>
>> On 02/26/2018 11:08 AM, Michal Sekletar wrote:
>>
>> Unfortunately, we don't have a dependency (AFAIK) that only propagates
>> stop actions.
>>
>> FTR (not helpful for the original problem), there exists ConsistsOf= as
>> an inverse of PartOf= dependency. However, it's read only currently (or
>> strictly speaking, writable through the PartOf= endpoint).
>>
>> Michal
>>
>> ___
>> systemd-devel mailing 
>> listsystemd-devel@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>>
>>
>> ___
>> systemd-devel mailing 
>> listsystemd-devel@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>>
>> --
>> [image: 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
>>
>> [image: email] jeremy.ro...@smile.fr
>> [image: phone] +33141402967 <+33%201%2041%2040%2029%2067>
>> [image: url] http://www.smile.eu
>>
>> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
>> <https://www.facebook.com/smileopensource> [image: LinkedIn]
>> <https://www.linkedin.com/company/smile> [image: Github]
>> <https://github.com/Smile-SA>
>>
>> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
>> <http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
>>
>> [image: 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
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Create a target unit to start & stop a group of services

[林自均]

Hi Jérémy,

Thank you, but I read the section "Mapping of unit properties to their
inverses" in the man page
https://www.freedesktop.org/software/systemd/man/systemd.unit.html and then
found out the PropagatesReloadTo= and ReloadPropagatedFrom= are inverses to
each other and both can be configured in a unit file. I was wondering why
PartOf= and ConsistsOf= are not the case. Thank you.

John Lin


Jérémy Rosen <jeremy.ro...@smile.fr> 於 2018年2月27日 週二 下午4:35寫道：

>
>
> On 27/02/2018 02:49, 林自均 wrote:
>
> Hi both Michal,
>
> Thank you for the quick responses! I think I will keep on using the tedious
> PartOf= directive.
>
> However, may I ask why ConsistsOf= is readonly? If I can use it in my
> "my-apps.target", that would be great.
>
> Because "ConsistsOf" doesn't exist in the way you think it does...
>
> Every relation between units (Wants, Before, PartOf) needs to have an
> internal, reverse relation for accounting purpose
>
> That reverse relation is usually an internal detail, but it is handy to
> expose
> it in "systemctl show" & co.
>
> So that's what you see, an internal property exposed for ease-of-use. not
> an
> external, user configurable property
>
>
>
> John Lin
>
> Michal Koutný <mkou...@suse.com> <mkou...@suse.com> 於 2018年2月26日 週一 下午7:28寫道：
>
>
>
>
> On 02/26/2018 11:08 AM, Michal Sekletar wrote:
>
> Unfortunately, we don't have a dependency (AFAIK) that only propagates
> stop actions.
>
> FTR (not helpful for the original problem), there exists ConsistsOf= as
> an inverse of PartOf= dependency. However, it's read only currently (or
> strictly speaking, writable through the PartOf= endpoint).
>
> Michal
>
> ___
> systemd-devel mailing 
> listsystemd-devel@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
>
> ___
> systemd-devel mailing 
> listsystemd-devel@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
> --
> [image: 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
>
> [image: email] jeremy.ro...@smile.fr
> [image: phone] +33141402967 <+33%201%2041%2040%2029%2067>
> [image: url] http://www.smile.eu
>
> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
> <https://www.facebook.com/smileopensource> [image: LinkedIn]
> <https://www.linkedin.com/company/smile> [image: Github]
> <https://github.com/Smile-SA>
>
> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
> <http://smile.eu/?utm_source=signature_medium=email_campaign=signature>
>
> [image: 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
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Create a target unit to start & stop a group of services

[林自均]

Hi both Michal,

Thank you for the quick responses! I think I will keep on using the tedious
PartOf= directive.

However, may I ask why ConsistsOf= is readonly? If I can use it in my
"my-apps.target", that would be great.

John Lin

Michal Koutný  於 2018年2月26日 週一 下午7:28寫道：

>
>
> On 02/26/2018 11:08 AM, Michal Sekletar wrote:
> > Unfortunately, we don't have a dependency (AFAIK) that only propagates
> > stop actions.
> FTR (not helpful for the original problem), there exists ConsistsOf= as
> an inverse of PartOf= dependency. However, it's read only currently (or
> strictly speaking, writable through the PartOf= endpoint).
>
> Michal
>
> ___
> 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

[systemd-devel] Create a target unit to start & stop a group of services

[林自均]

Hi folks,

I would like to create a target unit to start and stop a group of services.
For example, I want a "my-apps.target" to start and stop "docker.service",
"sshd.service" and "mongodb.service". Here are my units and drop-ins:

# /etc/systemd/system/my-apps.target
[Unit]
Wants=docker.service sshd.service mongodb.service # for starting

# /etc/systemd/system/docker.service.d/my-apps.conf
[Unit]
PartOf=my-apps.target # for stopping

And the drop-ins for "sshd.service" and "mongodb.service" are similar.

Then I can use "systemctl start my-apps.target" and "systemctl stop
my-apps.target" to start and stop the 3 services.

However, it is a little bit tedious to write drop-ins for each service
units. Is there a directive for "my-apps.target" to propagate "stop"
operation to the 3 services? I was expecting something like
"PropagateStopTo=docker.service sshd.service mongodb.service".

Thanks!

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

Re: [systemd-devel] Multiple services using the same core service?

[林自均]

Hi Lennart,

Thank you, I will reconsider this design.

John Lin

Lennart Poettering <lenn...@poettering.net> 於 2018年1月24日 週三 19:41 寫道：

> On Di, 26.12.17 01:39, 林自均 (johnl...@gmail.com) wrote:
>
> > Hi folks,
> >
> > I am trying to achieve:
> >
> > # systemctl start sshd-shell.service (1)
> > # systemctl start sshd-sftp.service (2)
> > # systemctl stop sshd-shell.service (3)
> > # systemctl stop sshd-sftp.service (4)
> >
> > Before the command (1), sshd is not running. By typing (1),
> > /etc/sshd_config is configured to accept ssh shell connections but no
> sftp
> > connections, and then start sshd. By typing (2), /etc/sshd_config is
> > configured to accept sftp connections too, and sshd is reloaded. By
> typing
> > (3), /etc/sshd_config is configured to refuse ssh shell connection, and
> > sshd is reloaded again. By typing (4), sshd will be stopped.
>
> Quite frankly, this is not really in line with how systemd services
> are supposed to be used. They are supposed to wrap running processes,
> but not wrap configuration applied to others really.
>
> But anyway, of course, it's up to you how to make use of this stuff...
>
> > The current problem is that I don't know if there is a better way to
> > achieve this. For example, I have to sleep 1 second before reloading
> > sshd-core.service in sshd-shell.service because otherwise sshd didn't
> setup
> > the signal handler for SIGHUP and will terminate itself. Or systemd
> doesn't
> > suggest such use case?
>
> Yes, it's not really in-line with how this stuff was designed...
>
> That said, I am pretty sure there's something wrong with your
> sshd-core.service: the unit should not be considered up before the
> daemon process is fully running, and that includes having set up
> SIGHUP handlers properly.
>
> Most likely the Type= stuff is not set up correctly in that unit (or
> sshd is broken and doesn't set things up fully before reporting its
> startup being complete).
>
> 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] systemd-journald missing crash logs

[林自均]

Hi Farzad,

It seems that you missed Lennart's comments? It's here:
https://lists.freedesktop.org/archives/systemd-devel/2018-January/040162.html

John

Farzad Panahi  於 2018年1月20日 週六 05:52 寫道：

> Hey guys. I really appreciate any comment on this issue. Please let me
> know if this question does not belong to this mailing list.
>
> On Fri, Jan 12, 2018 at 4:13 PM, Farzad Panahi 
> wrote:
>
>> I am running Arch-ARM on RPi3. I have noticed when system crashes I
>> cannot find any related crash log in journal logs.
>>
>> Arch Linux ARM on RPi3: `Linux 4.4.37-1-ARCH #1 SMP armv7l GNU/Linux`
>>
>> Systemd: `systemd 232`
>>
>> `/etc/systemd/journald.conf`:
>>
>>
>> [Journal]
>> Storage=persistent
>> Compress=yes
>> #Seal=yes
>> #SplitMode=uid
>> SyncIntervalSec=1
>> #RateLimitIntervalSec=30s
>> #RateLimitBurst=1000
>> SystemMaxUse=1.5G
>> #SystemKeepFree=
>> #SystemMaxFileSize=
>> #SystemMaxFiles=100
>> #RuntimeMaxUse=
>> #RuntimeKeepFree=
>> #RuntimeMaxFileSize=
>> #RuntimeMaxFiles=100
>> MaxRetentionSec=1month
>> MaxFileSec=3hour
>> #ForwardToSyslog=no
>> #ForwardToKMsg=no
>> #ForwardToConsole=no
>> #ForwardToWall=yes
>> #TTYPath=/dev/console
>> #MaxLevelStore=debug
>> #MaxLevelSyslog=debug
>> #MaxLevelKMsg=notice
>> #MaxLevelConsole=info
>> #MaxLevelWall=emerg
>>
>> Recent crash log:
>>
>> Dec 29 03:43:48 sudo[21861]:  my_user : TTY=unknown ;
>> PWD=/opt/my_app/repo/src ; USER=root ; COMMAND=/usr/sbin/hciconfig hci0
>> reset
>> Dec 29 03:43:48 sudo[21861]: pam_unix(sudo:session): session opened
>> for user root by (uid=0)
>> Dec 29 03:43:48 sudo[21861]: pam_unix(sudo:session): session closed
>> for user root
>> Dec 29 03:43:48 my_app.py[17773]: trying to connect to
>> XX:XX:XX:XX:XX:XX
>> Dec 29 03:43:48 systemd-udevd[21865]: Process '/bin/hciconfig hci0:64
>> up' failed with exit code 1.
>> Dec 29 03:43:51 my_app.py[17773]: connection successful :)
>> -- Reboot --
>> Jan 03 16:31:25 systemd[1]: Time has been changed
>> Jan 03 16:31:26 dhcpcd[470]: forked to background, child pid 587
>> Jan 03 16:31:25 systemd-timesyncd[360]: Synchronized to time server
>> 206.108.0.133:123 (2.arch.pool.ntp.org).
>> Jan 03 16:31:25 systemd[1]: Starting Update man-db cache...
>> Jan 03 16:31:25 systemd[1]: Starting Rotate log files...
>> Jan 03 16:31:25 systemd[1]: Started Verify integrity of password and
>> group files.
>> Jan 03 16:31:25 systemd[1]: ssh-tunnel.service: Service hold-off time
>> over, scheduling restart.
>>
>>
>> **Looks like that somehow `journald` is failing to `sync` logs when a
>> crash happens.**
>>
>>  - Is this a known behaviour?
>>  - Is there a workaround for this?
>>
>>
>> --
>> Also I am curious to know if the following claim from [Arch Linux
>> wiki][1] is still valid:
>>
>> > Since the syslog component of systemd, journald, does not flush its
>> > logs to disk during normal operation, these logs will be gone when the
>> > machine is shut down abnormally (power loss, kernel lock-ups, ...). In
>> > the case of kernel lock-ups, it is pretty important to have some
>> > kernel logs for debugging. Until journald gains a configuration option
>> > for flushing kernel logs, rsyslog can be used in conjunction with
>> > journald.
>>
>>
>> --
>> related bug report (old): [Bug 61411 - All logs since last boot gone
>> after crash/hard reboot][2]
>>
>> similar issue (old):
>> https://unix.stackexchange.com/questions/67394/debugging-lock-up-systemd-loses-my-logs
>>
>>   [1]:
>> https://wiki.archlinux.org/index.php/Rsyslog#journald_with_rsyslog_for_kernel_messages
>>   [2]:
>> https://bugs.freedesktop.org/show_bug.cgi?id=61411
>>
>>
> ___
> 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] Multiple services using the same core service?

[林自均]

Hi folks,

I re-designed my units as follows:

# sshd-core.service
[Unit]
Description=OpenSSH Daemon
After=network.target

[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always

# sshd-shell.service
[Unit]
PropagatesReloadTo=sshd-core.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/config-sshd.sh enable-shell
ExecStop=/usr/local/bin/config-sshd.sh disable-shell
ExecReload=/bin/true
RemainAfterExit=yes
ExecStartPost=/bin/mkdir -p /var/run/sshd-running
ExecStartPost=/bin/systemctl reload-or-restart sshd-core.service
ExecStartPost=/bin/touch /var/run/sshd-running/sshd-shell.service
ExecStopPost=/bin/rm -f /var/run/sshd-running/sshd-shell.service
ExecStopPost=/bin/bash -c 'if [ "$(ls /var/run/sshd-running | wc -l)"
== "0" ] ; then /bin/systemctl stop sshd-core.service ; else /bin/systemctl
reload-or-restart sshd-core.service ; fi'

This version doesn't need to sleep 1 second to wait for sshd, so I guess it
makes more sense.

Is there any suggestion on that? Thanks!

John Lin

林自均 <johnl...@gmail.com> 於 2017年12月26日 週二 上午9:39寫道：

> Hi folks,
>
> I am trying to achieve:
>
> # systemctl start sshd-shell.service (1)
> # systemctl start sshd-sftp.service (2)
> # systemctl stop sshd-shell.service (3)
> # systemctl stop sshd-sftp.service (4)
>
> Before the command (1), sshd is not running. By typing (1),
> /etc/sshd_config is configured to accept ssh shell connections but no sftp
> connections, and then start sshd. By typing (2), /etc/sshd_config is
> configured to accept sftp connections too, and sshd is reloaded. By typing
> (3), /etc/sshd_config is configured to refuse ssh shell connection, and
> sshd is reloaded again. By typing (4), sshd will be stopped.
>
> Basically, I wrote the following 3 service units:
>
> - sshd-core.service: the original sshd
> - sshd-shell.service: ssh shell
> - sshd-sftp.service: sftp server
>
> The units looks like:
>
> # sshd-core.service
> [Unit]
> Description=OpenSSH Daemon
> After=network.target
> StopWhenUnneeded=yes
> RefuseManualStart=yes
>
> [Service]
> ExecStart=/usr/bin/sshd -D
> ExecReload=/bin/kill -HUP $MAINPID
> KillMode=process
> Restart=always
>
> # sshd-shell.service
> [Unit]
> Requires=sshd-core.service
> After=sshd-core.service
> PropagatesReloadTo=sshd-core.service
>
> [Service]
> Type=oneshot
> ExecStart=/usr/local/bin/config-sshd.sh enable-shell
> ExecStop=/usr/local/bin/config-sshd.sh disable-shell
> ExecReload=/bin/true
> RemainAfterExit=yes
> ExecStartPost=/bin/sleep 1
> ExecStartPost=-/bin/systemctl reload --no-block sshd-core.service
> ExecStopPost=-/bin/systemctl reload --no-block sshd-core.service
>
> And sshd-sftp.service is similar to sshd-shell.service except the
> ExecStart= and ExecStop= configures sftp.
>
> The current problem is that I don't know if there is a better way to
> achieve this. For example, I have to sleep 1 second before reloading
> sshd-core.service in sshd-shell.service because otherwise sshd didn't setup
> the signal handler for SIGHUP and will terminate itself. Or systemd doesn't
> suggest such use case?
>
> Thanks for any comments.
>
> John
>
___
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

[林自均]

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 <arvidj...@gmail.com> 於 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

[林自均]

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

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

Re: [systemd-devel] Required kernel version for pid1 only?

[林自均]

Hi Zbyszek and Mantas,

I got it. Thank you for the detailed answers.

John Lin

Mantas Mikulėnas <graw...@gmail.com> 於 2018年1月9日 週二 下午4:23寫道：

> On Tue, Jan 9, 2018 at 10:10 AM, 林自均 <johnl...@gmail.com> wrote:
>
>> Hi folks,
>>
>> I saw the following lines in README:
>>
>> > REQUIREMENTS:
>> > Linux kernel >= 3.13
>> > Linux kernel >= 4.2 for unified cgroup hierarchy support
>>
>> I guess it means that some part of the whole systemd project requires
>> Linux kernel 3.13. What if I don't need that part and only pid1 is relevant
>> to me? Is such information provided somewhere?
>>
>
> There's no full list. You can only check commit logs to find out why the
> requirement was bumped (git log -p README), but once the new dependency is
> published, it's always possible that other parts of systemd code will start
> implicitly depending on *other* kernel features available in that release.
>
> For example, here's what prompted each bump:
>
> 3.13 - DM_DEFERRED_REMOVE (dcce98a4bdc3)
> 3.12 - %P in core_pattern (58015d7815bc)
> 3.11 - arbitrary (a0c3e16b7bce)
> 3.7 - kernel-based firmware loading (be2ea723b1d0)
> 3.0 - cgroup.procs (e946948eff51)
> 2.6.39 - oh come on
>
> ~
>
> In short, if it says "REQUIREMENTS: Linux ≥ 3.13", that's what you need to
> use. Anything below that is at your own risk.
>
> --
> Mantas Mikulėnas
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Required kernel version for pid1 only?

[林自均]

Hi folks,

I saw the following lines in README:

> REQUIREMENTS:
> Linux kernel >= 3.13
> Linux kernel >= 4.2 for unified cgroup hierarchy support

I guess it means that some part of the whole systemd project requires Linux
kernel 3.13. What if I don't need that part and only pid1 is relevant to
me? Is such information provided somewhere?

Thanks.

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

[systemd-devel] Multiple services using the same core service?

[林自均]

Hi folks,

I am trying to achieve:

# systemctl start sshd-shell.service (1)
# systemctl start sshd-sftp.service (2)
# systemctl stop sshd-shell.service (3)
# systemctl stop sshd-sftp.service (4)

Before the command (1), sshd is not running. By typing (1),
/etc/sshd_config is configured to accept ssh shell connections but no sftp
connections, and then start sshd. By typing (2), /etc/sshd_config is
configured to accept sftp connections too, and sshd is reloaded. By typing
(3), /etc/sshd_config is configured to refuse ssh shell connection, and
sshd is reloaded again. By typing (4), sshd will be stopped.

Basically, I wrote the following 3 service units:

- sshd-core.service: the original sshd
- sshd-shell.service: ssh shell
- sshd-sftp.service: sftp server

The units looks like:

# sshd-core.service
[Unit]
Description=OpenSSH Daemon
After=network.target
StopWhenUnneeded=yes
RefuseManualStart=yes

[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always

# sshd-shell.service
[Unit]
Requires=sshd-core.service
After=sshd-core.service
PropagatesReloadTo=sshd-core.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/config-sshd.sh enable-shell
ExecStop=/usr/local/bin/config-sshd.sh disable-shell
ExecReload=/bin/true
RemainAfterExit=yes
ExecStartPost=/bin/sleep 1
ExecStartPost=-/bin/systemctl reload --no-block sshd-core.service
ExecStopPost=-/bin/systemctl reload --no-block sshd-core.service

And sshd-sftp.service is similar to sshd-shell.service except the
ExecStart= and ExecStop= configures sftp.

The current problem is that I don't know if there is a better way to
achieve this. For example, I have to sleep 1 second before reloading
sshd-core.service in sshd-shell.service because otherwise sshd didn't setup
the signal handler for SIGHUP and will terminate itself. Or systemd doesn't
suggest such use case?

Thanks for any comments.

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

Re: [systemd-devel] Why do passive target units have to exist?

[林自均]

Hi Lennart,

Yes, it makes sense to me. Thank you for your explanation.

However, I still have a question about it. If the general goal is to
minimize synchronization points, why don't we convert more active targets
into passive targets? For example: not all machines have swap, so can the
swap.target be a passive target to avoid unnecessary sync point? I guess
there must be a reason not to do so, but I don't know what it is.

John

Lennart Poettering <lenn...@poettering.net> 於 2017年10月24日 週二 下午4:45寫道：

> On Mo, 16.10.17 15:15, 林自均 (johnl...@gmail.com) wrote:
>
> > Hi folks,
> >
> > I am reading systemd documents, and I find passive target units a little
> > bit confusing.
> >
> > Take "network.target" for example:
> >
> > "systemd-networkd.service" specifies "Wants=network.target" and
> > "Before=network.target". That effectively makes starting
> > "systemd-networkd.service" brings up both "systemd-networkd.service" and
> > "network.target", and make sure that "network.target" is active after
> > "systemd-networkd.service" being active. It also implies that the
> shutdown
> > order is correct: "network.target" will be stopped before
> > "systemd-networkd.service".  Everything is fine.
> >
> > What if we use an active target unit to achieve all this? Can we specify
> a
> > "WantedBy=network.target" in "systemd-network.target"? So that we can
> > enable "systemd-network.service" (which makes a symbolic link in the
> > "network.target.wants" directory) and start "network.target" to pull in
> > "systemd-networkd.service". That also makes sure "network.target" is
> active
> > after "systemd-networkd.service" because of the target unit default
> > dependencies. And shutdown order will be correct too.
> >
> > The only difference I can tell is the units to start. With a passive
> > "network.target", we start "systemd-networkd.service". With an active
> > "network.target", we start "network.target".
> >
> > Is there any benefits of passive target units over active target units?
>
> We generally try to minimize synchronization points. "network.target"
> is one, and we don't want it around if there's no reason to have
> it. The more synchronization points you have the more serial your boot
> becomes.
>
> The logic hence is: if there's not networking stack then there's no
> reason for services to synchronize before or after it, and thus it's
> the networking stack that pulls in network.target and not its
> consumer, if you so will.
>
> Does that make sense?
>
> 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] Why do passive target units have to exist?

[林自均]

Hi Andrei,

Thank you for your reply!
Just to confirm: there are about 10 passive system targets in
systemd.special(5):

- getty-pre.target
- cryptsetup-pre.target
- local-fs-pre.target
- network.target
- network-pre.target
- nss-lookup.target
- nss-user-lookup.target
- remote-fs-pre.target
- rpcbind.target
- time-sync.target

Are they all related to early days initscripts?

Thanks.

John

Andrei Borzenkov <arvidj...@gmail.com> 於 2017年10月18日 週三 00:58 寫道：

> 16.10.2017 18:15, 林自均 пишет:
> > Hi folks,
> >
> > I am reading systemd documents, and I find passive target units a little
> > bit confusing.
> >
> > Take "network.target" for example:
> >
> > "systemd-networkd.service" specifies "Wants=network.target" and
> > "Before=network.target". That effectively makes starting
> > "systemd-networkd.service" brings up both "systemd-networkd.service" and
> > "network.target", and make sure that "network.target" is active after
> > "systemd-networkd.service" being active. It also implies that the
> shutdown
> > order is correct: "network.target" will be stopped before
> > "systemd-networkd.service".  Everything is fine.
> >
> > What if we use an active target unit to achieve all this? Can we specify
> a
> > "WantedBy=network.target" in "systemd-network.target"? So that we can
> > enable "systemd-network.service" (which makes a symbolic link in the
> > "network.target.wants" directory) and start "network.target" to pull in
> > "systemd-networkd.service". That also makes sure "network.target" is
> active
> > after "systemd-networkd.service" because of the target unit default
> > dependencies. And shutdown order will be correct too.
> >
> > The only difference I can tell is the units to start. With a passive
> > "network.target", we start "systemd-networkd.service". With an active
> > "network.target", we start "network.target".
> >
> > Is there any benefits of passive target units over active target units?
> >
>
> I think it's historical artefact from the very early days when systemd
> had to rely on initscripts. initscript implementing networking did
> provide $network a.k.a network.target, but of course did not hook itself
> into native systemd units. As long as you are sure to use native units
> only there is no practical difference.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why is the [Install] section in a drop-in not respected?

[林自均]

Hi Zbyszek,

Got it! I will file an RFE and a pull request for that. Thanks so much!

John

Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> 於 2017年10月17日 週二 22:40 寫道：

> On Tue, Oct 17, 2017 at 09:49:36AM +, 林自均 wrote:
> > Hi folks,
> >
> > I learned that [Install] section in a drop-in is not respected. This
> > behavior is documented, but I failed to see *why*.
> >
> > I found this related GitHub issue:
> > https://github.com/systemd/systemd/issues/1774, and here is the quote
> from
> > "poettering commented on 5 Nov 2015":
>
> Hi,
>
> things have changed a bit since then, and if somebody writes the code to
> honour
> [Install] section in dropins, I expect it'd be merged.
>
> Back then we didn't have support for drop-ins in /usr/lib, and
> drop-ins were only expected to be used by users to _override_
> configuration provided by packagers.  But now drop-ins in /usr/lib are
> supported everywhere, and it's understood that packaging configuration
> might
> be composed from a few independent pieces.
>
> Zbyszek
>
> > > Well, this has been requested before, but generally, install info is
> > something that is provided by the unit file vendor in the unit files.
> > drop-ins and symlinks in /etc are user extensions however. "systemctl
> > enable" is for applying that install info to /etc. It would be
> > contradictory to use user configuration to create user configuration
> > though. Hence we do not respect install info in drop-ins.
> >
> > However, I don't think it's contradictory since drop-ins are not always
> > user configuration. For "s.service", the drop-ins in
> > /usr/lib/systemd/system/s.service.d/
> > and /var/run/systemd/generator/s.service.d/ are respected, but they are
> not
> > user configurations.
> >
> > For example, one can create a package that includes 2 things:
> >
> > 1. a target unit called "remote-access.target"
> > 2. a systemd generator that generates the following drop-ins for
> > "sshd.service", "telnetd.service" and "vnc.service":
> >
> > [Unit]
> > PartOf=remote-access.target
> >
> > [Install]
> > WantedBy=remote-access.target
> >
> > That way, after a user typed "systemctl enable sshd telnetd vnc", he/she
> > can:
> >
> > - systemctl start remote-access.target
> > - systemctl stop remote-access.target
> >
> > to conveniently start/stop all remote access services.
> >
> > In conclusion, I consider drop-ins as a way to enhance the original unit
> > files. Just like [Unit], [Service] or any other sections, [Install]
> should
> > be enhance-able too.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Why is the [Install] section in a drop-in not respected?

[林自均]

Hi folks,

I learned that [Install] section in a drop-in is not respected. This
behavior is documented, but I failed to see *why*.

I found this related GitHub issue:
https://github.com/systemd/systemd/issues/1774, and here is the quote from
"poettering commented on 5 Nov 2015":

> Well, this has been requested before, but generally, install info is
something that is provided by the unit file vendor in the unit files.
drop-ins and symlinks in /etc are user extensions however. "systemctl
enable" is for applying that install info to /etc. It would be
contradictory to use user configuration to create user configuration
though. Hence we do not respect install info in drop-ins.

However, I don't think it's contradictory since drop-ins are not always
user configuration. For "s.service", the drop-ins in
/usr/lib/systemd/system/s.service.d/
and /var/run/systemd/generator/s.service.d/ are respected, but they are not
user configurations.

For example, one can create a package that includes 2 things:

1. a target unit called "remote-access.target"
2. a systemd generator that generates the following drop-ins for
"sshd.service", "telnetd.service" and "vnc.service":

[Unit]
PartOf=remote-access.target

[Install]
WantedBy=remote-access.target

That way, after a user typed "systemctl enable sshd telnetd vnc", he/she
can:

- systemctl start remote-access.target
- systemctl stop remote-access.target

to conveniently start/stop all remote access services.

In conclusion, I consider drop-ins as a way to enhance the original unit
files. Just like [Unit], [Service] or any other sections, [Install] should
be enhance-able too.

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

[systemd-devel] Why do passive target units have to exist?

[林自均]

Hi folks,

I am reading systemd documents, and I find passive target units a little
bit confusing.

Take "network.target" for example:

"systemd-networkd.service" specifies "Wants=network.target" and
"Before=network.target". That effectively makes starting
"systemd-networkd.service" brings up both "systemd-networkd.service" and
"network.target", and make sure that "network.target" is active after
"systemd-networkd.service" being active. It also implies that the shutdown
order is correct: "network.target" will be stopped before
"systemd-networkd.service".  Everything is fine.

What if we use an active target unit to achieve all this? Can we specify a
"WantedBy=network.target" in "systemd-network.target"? So that we can
enable "systemd-network.service" (which makes a symbolic link in the
"network.target.wants" directory) and start "network.target" to pull in
"systemd-networkd.service". That also makes sure "network.target" is active
after "systemd-networkd.service" because of the target unit default
dependencies. And shutdown order will be correct too.

The only difference I can tell is the units to start. With a passive
"network.target", we start "systemd-networkd.service". With an active
"network.target", we start "network.target".

Is there any benefits of passive target units over active target units?

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