[systemd-devel] systemd behavior during shutdown

Lennart Poettering lennart at poettering.net
Mon Sep 24 13:25:48 UTC 2018


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


More information about the systemd-devel mailing list