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' <zbys...@in.waw.pl> Cc: systemd-devel@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-cfg@6-127.0.0.1:5302-127.0.0.1:63714.service: Trying to enqueue job hacl-cfg@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@.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:zbys...@in.waw.pl] Sent: Wednesday, September 19, 2018 12:11 PM To: Tiwari, Hari Sahaya <hari-sahaya.tiw...@hpe.com> Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] systemd behavior during shutdown On Wed, Sep 19, 2018 at 05:01:33AM +0000, Tiwari, Hari Sahaya wrote: > 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
