Discussion:
systemd behavior during shutdown
(too old to reply)
Tiwari, Hari Sahaya
2018-09-19 05:01:33 UTC
Permalink
Hi,

I am facing one issue with systemd where systems socket is not opening a new connection during shutdown.
I get below logs,

Sep 12 20:01:32 jara2 systemd[1]: mytestX.socket: Incoming traffic
Sep 12 20:01:32 jara2 systemd[1]: mytestX.socket: Suppressing connection request since unit stop is scheduled.

I have one systemd service which is trying to open a new connection during shutdown sequence but looks like systemd sockets stop accepting new connections as soon as they are marked for stop.
I tried putting various combination of dependencies but that didn't help. Everytime getting the above message.

Is there any parameter which can be set in unit files to resolve this issue? Any pointers will be appreciated.

Thanks!
-Hari.
Zbigniew Jędrzejewski-Szmek
2018-09-19 06:40:48 UTC
Permalink
Post by Tiwari, Hari Sahaya
Hi,
I am facing one issue with systemd where systems socket is not opening a new connection during shutdown.
I get below logs,
Sep 12 20:01:32 jara2 systemd[1]: mytestX.socket: Incoming traffic
Sep 12 20:01:32 jara2 systemd[1]: mytestX.socket: Suppressing connection request since unit stop is scheduled.
I have one systemd service which is trying to open a new connection during shutdown sequence but looks like systemd sockets stop accepting new connections as soon as they are marked for stop.
I tried putting various combination of dependencies but that didn't help. Everytime getting the above message.
Is there any parameter which can be set in unit files to resolve this issue? Any pointers will be appreciated.
Hi,

yes, this is intentional. It was added to avoid the situation where
services are stop and subsequently restarted during shutdown because
something opens a connection, leading to loops.

If you absolutely need to open a connection to a socket activated
unit, then you could try making the .socket and .service units have
DefaultDependencies=false, so that they will not conflict with
shutdown.target and the start jobs will not be created for them. But
then you need to make sure that they actually *are* stopped at the
right time, but issuing a 'systemctl stop' request for them.
This can be done, but will be messy, so I'd use a different approach
if possible.

Zbyszek
Tiwari, Hari Sahaya
2018-09-19 18:44:54 UTC
Permalink
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-***@6-127.0.0.1:5302-127.0.0.1:63714.service: Trying to enqueue job hacl-***@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-***@.service
[Unit]
Description=config TCP service
Requires=hacl-cfg.socket
DefaultDependencies=false

[Service]
ExecStart=/opt/cmcluster/bin/cmclconfd -c
StandardInput=socket
KillMode=process

[Install]
WantedBy=multi-user.target

Socket File
-----------------
# cat hacl-cfg.socket
[Unit]
Description= config TCP socket
DefaultDependencies=false

[Socket]
ListenStream=5302
Accept=true
MaxConnections=900

[Install]
WantedBy=sockets.target


Service file which tries to open a new connection with hacl-cfg.socket during shutdown
--------------------------------------------------------------------------------------------------------
# cat test.service
[Unit]
Description=test Service

[Service]
ExecStart=/bin/test start
ExecStop=/bin/test stop
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target


Thanks,
Hari.

-----Original Message-----
From: Zbigniew Jędrzejewski-Szmek [mailto:***@in.waw.pl]
Sent: Wednesday, September 19, 2018 12:11 PM
To: Tiwari, Hari Sahaya <hari-***@hpe.com>
Cc: systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] systemd behavior during shutdown
Post by Tiwari, Hari Sahaya
Hi,
I am facing one issue with systemd where systems socket is not opening a new connection during shutdown.
I get below logs,
Sep 12 20:01:32 jara2 systemd[1]: mytestX.socket: Incoming traffic Sep
12 20:01:32 jara2 systemd[1]: mytestX.socket: Suppressing connection request since unit stop is scheduled.
I have one systemd service which is trying to open a new connection during shutdown sequence but looks like systemd sockets stop accepting new connections as soon as they are marked for stop.
I tried putting various combination of dependencies but that didn't help. Everytime getting the above message.
Is there any parameter which can be set in unit files to resolve this issue? Any pointers will be appreciated.
Hi,

yes, this is intentional. It was added to avoid the situation where services are stop and subsequently restarted during shutdown because something opens a connection, leading to loops.

If you absolutely need to open a connection to a socket activated unit, then you could try making the .socket and .service units have DefaultDependencies=false, so that they will not conflict with shutdown.target and the start jobs will not be created for them. But then you need to make sure that they actually *are* stopped at the right time, but issuing a 'systemctl stop' request for them.
This can be done, but will be messy, so I'd use a different approach if possible.

Zbyszek
Lennart Poettering
2018-09-24 13:25:48 UTC
Permalink
Post by Tiwari, Hari Sahaya
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]: 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.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-***@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
Tiwari, Hari Sahaya
2018-09-25 12:10:23 UTC
Permalink
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-***@3-127.0.0.1:5302-127.0.0.1:48900.service hacl-***@2-127.0.0.1:5302-127.0.0.1:48896.service hacl-***@5-127.0.0.1:5302-127.0.0.1:48906.service hacl-***@4-127.0.0.1:5302-127.0.0.1:48904.service
WantedBy=sockets.target
Before=hacl-***@3-127.0.0.1:5302-127.0.0.1:48900.service hacl-***@2-127.0.0.1:5302-127.0.0.1:48896.service hacl-***@5-127.0.0.1:5302-127.0.0.1:48906.service hacl-***@4-127.0.0.1:5302-127.0.0.1:48904.service
After=-.slice
Triggers=hacl-***@3-127.0.0.1:5302-127.0.0.1:48900.service hacl-***@2-127.0.0.1:5302-127.0.0.1:48896.service hacl-***@5-127.0.0.1:5302-127.0.0.1:48906.service hacl-***@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-***@5-127.0.0.1:5302-127.0.0.1:48906.service
Names=hacl-***@5-127.0.0.1:5302-127.0.0.1:48906.service hacl-***@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-***@.service


Thanks,
Hari.





-----Original Message-----
From: Lennart Poettering [mailto:***@poettering.net]
Sent: Monday, September 24, 2018 6:56 PM
To: Tiwari, Hari Sahaya <hari-***@hpe.com>
Cc: Zbigniew Jędrzejewski-Szmek <***@in.waw.pl>; systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] systemd behavior during shutdown
Post by Tiwari, Hari Sahaya
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]: 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.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-***@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
Andrei Borzenkov
2018-09-25 17:47:13 UTC
Permalink
Post by 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
WantedBy=sockets.target
After=-.slice
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.
Requires=system-hacl\x2dcfg.slice hacl-cfg.socket
With high probability system-hacl-cfg.slice conflicts with shutdown.target.
Post by Tiwari, Hari Sahaya
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
Thanks,
Hari.
-----Original Message-----
Sent: Monday, September 24, 2018 6:56 PM
Subject: Re: [systemd-devel] systemd behavior during shutdown
Post by Tiwari, Hari Sahaya
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]: 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.socket
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
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Tiwari, Hari Sahaya
2018-09-26 09:14:14 UTC
Permalink
Yes, you are correct.
system-hacl-cfg.slice does have conflict with shutdown.target and for this DefaultDependencies is yes. May be that is the reason.

Id=system-hacl-cfg.slice
Names=system-hacl-cfg.slice
Requires=system-hacl.slice
Conflicts=shutdown.target
Before=shutdown.target
After=system-hacl.slice
Description=system-hacl-cfg.slice
.
DefaultDependencies=yes

Is there a different step to set "DefaultDependencies=false" for .slice? I thought it will take from [Unit] section of corresponding socket & service file.

Regards,
Hari.

-----Original Message-----
From: systemd-devel [mailto:systemd-devel-***@lists.freedesktop.org] On Behalf Of Andrei Borzenkov
Sent: Tuesday, September 25, 2018 11:17 PM
To: systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] systemd behavior during shutdown
Post by 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
WantedBy=sockets.target
After=-.slice
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.
With high probability system-hacl-cfg.slice conflicts with shutdown.target.
Post by Tiwari, Hari Sahaya
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
Thanks,
Hari.
-----Original Message-----
Sent: Monday, September 24, 2018 6:56 PM
Subject: Re: [systemd-devel] systemd behavior during shutdown
Post by Tiwari, Hari Sahaya
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]: 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.socket
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
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering
2018-10-05 17:32:58 UTC
Permalink
Post by Tiwari, Hari Sahaya
Yes, you are correct.
system-hacl-cfg.slice does have conflict with shutdown.target and for this DefaultDependencies is yes. May be that is the reason.
Id=system-hacl-cfg.slice
Names=system-hacl-cfg.slice
Requires=system-hacl.slice
Conflicts=shutdown.target
Before=shutdown.target
After=system-hacl.slice
Description=system-hacl-cfg.slice
.
DefaultDependencies=yes
Is there a different step to set "DefaultDependencies=false" for .slice? I thought it will take from [Unit] section of corresponding socket & service file.
Set it the property in the .slice unit file, that should just work.

Lennart
--
Lennart Poettering, Red Hat
Tiwari, Hari Sahaya
2018-11-26 13:17:05 UTC
Permalink
Sorry for reverting back late on this.
I was able to try the suggested solution.
There was no .slice unit file on the system by default.
So, I created the .slice file for my services.

# cat /usr/lib/systemd/system/hacl-cfg.slice
[Unit]
Description=hacl-cfg Slice
DefaultDependencies=no

After this I was able to verify that there is no Conflicts with shutdown.target. Still I am getting the same error.

Oct 02 03:41:05 gamma1 systemd[1]: Preset files say disable hacl-cfg.socket.
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfg.socket: Incoming traffic
Oct 02 03:41:05 gamma1 systemd[1]: hacl-***@8-127.0.0.1:5302-127.0.0.1:45234.service: Trying to enqueue job hacl-***@8-127.0.0.1:5302-127.0.0.1:45234.service/start/replace
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfg.socket: One connection closed, 1 left.
Oct 02 03:41:05 gamma1 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.
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfg.socket: Changed listening -> failed
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfg.socket: Unit entered failed state.

As I mentioned earlier this works fine for UDP service, for TCP service above error is seen.

Below are UDP logs, where UDP socket is able to spawn a new service during shutdown.

Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.socket: Incoming traffic
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.service: Trying to enqueue job hacl-cfgudp.service/start/replace
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.service: Installed new job hacl-cfgudp.service/start as 2108
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.service: Enqueued job hacl-cfgudp.service/start as 2108
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.socket: Changed listening -> running
Oct 02 03:41:05 gamma1 systemd[1]: Preset files say disable hacl-cfg.socket.
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.service: Passing 1 fds to service
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.service: About to execute: /opt/cmcluster/bin/cmclconfd -p
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.service: Forked /opt/cmcluster/bin/cmclconfd as 17300
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.service: Changed dead -> running
Oct 02 03:41:05 gamma1 systemd[1]: hacl-cfgudp.service: Job hacl-cfgudp.service/start finished, result=done
Oct 02 03:41:05 gamma1 systemd[17300]: hacl-cfgudp.service: Executing: /opt/cmcluster/bin/cmclconfd -p
Oct 02 03:41:20 gamma1 systemd[1]: hacl-cfgudp.service: Child 17300 belongs to hacl-cfgudp.service
Oct 02 03:41:20 gamma1 systemd[1]: hacl-cfgudp.service: Main process exited, code=exited, status=0/SUCCESS
Oct 02 03:41:20 gamma1 systemd[1]: hacl-cfgudp.service: Changed running -> dead
Oct 02 03:41:20 gamma1 systemd[1]: hacl-cfgudp.socket: Changed running -> listening

Is there anything else which I am missing? Any insights would be very helpful.

Thanks & Regards,
Hari.

-----Original Message-----
From: Lennart Poettering [mailto:***@poettering.net]
Sent: Friday, October 5, 2018 11:03 PM
To: Tiwari, Hari Sahaya <hari-***@hpe.com>
Cc: Andrei Borzenkov <***@gmail.com>; systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] systemd behavior during shutdown
Post by Tiwari, Hari Sahaya
Yes, you are correct.
system-hacl-cfg.slice does have conflict with shutdown.target and for this DefaultDependencies is yes. May be that is the reason.
Id=system-hacl-cfg.slice
Names=system-hacl-cfg.slice
Requires=system-hacl.slice
Conflicts=shutdown.target
Before=shutdown.target
After=system-hacl.slice
Description=system-hacl-cfg.slice
.
DefaultDependencies=yes
Is there a different step to set "DefaultDependencies=false" for .slice? I thought it will take from [Unit] section of corresponding socket & service file.
Set it the property in the .slice unit file, that should just work.

Lennart
--
Lennart Poettering, Red Hat
Tiwari, Hari Sahaya
2018-09-24 03:29:12 UTC
Permalink
Hi,

Any insights on below error which I am seeing.
Is it something expected with "DefaultDependencies=False"?

Thanks,
Hari.

-----Original Message-----
From: Tiwari, Hari Sahaya
Sent: Thursday, September 20, 2018 12:15 AM
To: 'Zbigniew Jędrzejewski-Szmek' <***@in.waw.pl>
Cc: systemd-***@lists.freedesktop.org
Subject: RE: [systemd-devel] systemd behavior during shutdown

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-***@6-127.0.0.1:5302-127.0.0.1:63714.service: Trying to enqueue job hacl-***@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-***@.service
[Unit]
Description=config TCP service
Requires=hacl-cfg.socket
DefaultDependencies=false

[Service]
ExecStart=/opt/cmcluster/bin/cmclconfd -c StandardInput=socket KillMode=process

[Install]
WantedBy=multi-user.target

Socket File
-----------------
# cat hacl-cfg.socket
[Unit]
Description= config TCP socket
DefaultDependencies=false

[Socket]
ListenStream=5302
Accept=true
MaxConnections=900

[Install]
WantedBy=sockets.target


Service file which tries to open a new connection with hacl-cfg.socket during shutdown
--------------------------------------------------------------------------------------------------------
# cat test.service
[Unit]
Description=test Service

[Service]
ExecStart=/bin/test start
ExecStop=/bin/test stop
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target


Thanks,
Hari.

-----Original Message-----
From: Zbigniew Jędrzejewski-Szmek [mailto:***@in.waw.pl]
Sent: Wednesday, September 19, 2018 12:11 PM
To: Tiwari, Hari Sahaya <hari-***@hpe.com>
Cc: systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] systemd behavior during shutdown
Post by Tiwari, Hari Sahaya
Hi,
I am facing one issue with systemd where systems socket is not opening a new connection during shutdown.
I get below logs,
Sep 12 20:01:32 jara2 systemd[1]: mytestX.socket: Incoming traffic Sep
12 20:01:32 jara2 systemd[1]: mytestX.socket: Suppressing connection request since unit stop is scheduled.
I have one systemd service which is trying to open a new connection during shutdown sequence but looks like systemd sockets stop accepting new connections as soon as they are marked for stop.
I tried putting various combination of dependencies but that didn't help. Everytime getting the above message.
Is there any parameter which can be set in unit files to resolve this issue? Any pointers will be appreciated.
Hi,

yes, this is intentional. It was added to avoid the situation where services are stop and subsequently restarted during shutdown because something opens a connection, leading to loops.

If you absolutely need to open a connection to a socket activated unit, then you could try making the .socket and .service units have DefaultDependencies=false, so that they will not conflict with shutdown.target and the start jobs will not be created for them. But then you need to make sure that they actually *are* stopped at the right time, but issuing a 'systemctl stop' request for them.
This can be done, but will be messy, so I'd use a different approach if possible.

Zbyszek
Colin Guthrie
2018-09-19 08:03:03 UTC
Permalink
This post might be inappropriate. Click to display it.
Continue reading on narkive:
Loading...