[systemd-devel] systemd behavior during shutdown

[Tiwari, Hari Sahaya]

Hi,
Thanks for reply.

I checked the dependencies through "systemctl show" and couldn't find any conflicts.
I checked for "Before, After, Requires, etc." Should I check for some other fields in that output ?

Also, I wanted to share another update on this.
I tried with UDP socket, for that I am able to spawn a service during shutdown with DefaultDependencies=False.
I am facing this only for TCP socket.

Below is relevant snippet from the output.
hacl-cfg.socket
-----------------------
Id=hacl-cfg.socket
Names=hacl-cfg.socket
Requires=-.slice
RequiredBy=hacl-cfg at 3-127.0.0.1:5302-127.0.0.1:48900.service hacl-cfg at 2-127.0.0.1:5302-127.0.0.1:48896.service hacl-cfg at 5-127.0.0.1:5302-127.0.0.1:48906.service hacl-cfg at 4-127.0.0.1:5302-127.0.0.1:48904.service
WantedBy=sockets.target
Before=hacl-cfg at 3-127.0.0.1:5302-127.0.0.1:48900.service hacl-cfg at 2-127.0.0.1:5302-127.0.0.1:48896.service hacl-cfg at 5-127.0.0.1:5302-127.0.0.1:48906.service hacl-cfg at 4-127.0.0.1:5302-127.0.0.1:48904.service
After=-.slice
Triggers=hacl-cfg at 3-127.0.0.1:5302-127.0.0.1:48900.service hacl-cfg at 2-127.0.0.1:5302-127.0.0.1:48896.service hacl-cfg at 5-127.0.0.1:5302-127.0.0.1:48906.service hacl-cfg at 4-127.0.0.1:5302-127.0.0.1:48904.service
Description=config TCP socket
LoadState=loaded
ActiveState=active
SubState=listening
FragmentPath=/usr/lib/systemd/system/hacl-cfg.socket

The services spawned by hacl-cfg.socket has almost the same contents.

Id=hacl-cfg at 5-127.0.0.1:5302-127.0.0.1:48906.service
Names=hacl-cfg at 5-127.0.0.1:5302-127.0.0.1:48906.service hacl-cfg at 5.service
Requires=system-hacl\x2dcfg.slice hacl-cfg.socket
After=system-hacl\x2dcfg.slice hacl-cfg.socket
TriggeredBy=hacl-cfg.socket
Description=config TCP service (127.0.0.1:48906)
LoadState=loaded
ActiveState=active
SubState=running
FragmentPath=/usr/lib/systemd/system/hacl-cfg at .service


Thanks,
Hari.





-----Original Message-----
From: Lennart Poettering [mailto:lennart at poettering.net] 
Sent: Monday, September 24, 2018 6:56 PM
To: Tiwari, Hari Sahaya <hari-sahaya.tiwari at hpe.com>
Cc: Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl>; systemd-devel at lists.freedesktop.org
Subject: Re: [systemd-devel] systemd behavior during shutdown

On Mi, 19.09.18 18:44, Tiwari, Hari Sahaya (hari-sahaya.tiwari at hpe.com) wrote:

> HI,
> Many thanks for the reply.
> 
> I tried putting DefaultDependencies=false in both .socket & .service files.
> I was able to verify that socket was still in "listening" state when my other systemd service tried to start a new connection with socket.
> Also the "Suppressing connection request since unit stop is scheduled" message is no more seen.
> 
> Now I am getting below error when the new connection is requested.
> 
> Sep 19 23:31:33 jara1 systemd[1]: hacl-cfg.socket: Incoming traffic 
> Sep 19 23:31:33 jara1 systemd[1]: 
> hacl-cfg at 6-127.0.0.1:5302-127.0.0.1:63714.service: Trying to enqueue 
> job hacl-cfg at 6-127.0.0.1:5302-127.0.0.1:63714.service/start/replace
> Sep 19 23:31:33 jara1 systemd[1]: Requested transaction contradicts existing jobs: Transaction is destructive.
> Sep 19 23:31:33 jara1 systemd[1]: hacl-cfg.socket: One connection closed, 1 left.
> Sep 19 23:31:33 jara1 systemd[1]: hacl-cfg.socket: Failed to queue service startup job (Maybe the service file is missing or not a non-template unit?): Transaction is destructive.
> Sep 19 23:31:33 jara1 systemd[1]: hacl-cfg.socket: Changed listening 
> -> failed
> 
> Do I have to set some other parameter in the systemd unit files ?
> 
> Following are the contents of systemd files, Service File
> -------------------
> # cat hacl-cfg at .service
> # cat hacl-cfg.socket

Any chance you can verify the precise deps of these services in effect with "systemctl show"? (i.e. paste the output of "systemctl show hal-cfg.socket hacl-cfg at foobar.service" somewhere)

My educated guess is that some .mount unit you are shutting down ends up being required by the service, and thus you get the conflicting jobs queued...

Lennart

--
Lennart Poettering, Red Hat