25.09.2018 15:10, 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@3-127.0.0.1:5302-127.0.0.1:48900.service > hacl-cfg@2-127.0.0.1:5302-127.0.0.1:48896.service > hacl-cfg@5-127.0.0.1:5302-127.0.0.1:48906.service > hacl-cfg@4-127.0.0.1:5302-127.0.0.1:48904.service > WantedBy=sockets.target > Before=hacl-cfg@3-127.0.0.1:5302-127.0.0.1:48900.service > hacl-cfg@2-127.0.0.1:5302-127.0.0.1:48896.service > hacl-cfg@5-127.0.0.1:5302-127.0.0.1:48906.service > hacl-cfg@4-127.0.0.1:5302-127.0.0.1:48904.service > After=-.slice > Triggers=hacl-cfg@3-127.0.0.1:5302-127.0.0.1:48900.service > hacl-cfg@2-127.0.0.1:5302-127.0.0.1:48896.service > hacl-cfg@5-127.0.0.1:5302-127.0.0.1:48906.service > hacl-cfg@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@5-127.0.0.1:5302-127.0.0.1:48906.service > Names=hacl-cfg@5-127.0.0.1:5302-127.0.0.1:48906.service hacl-cfg@5.service > Requires=system-hacl\x2dcfg.slice hacl-cfg.socket
With high probability system-hacl-cfg.slice conflicts with shutdown.target. > 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@.service > > > Thanks, > Hari. > > > > > > -----Original Message----- > From: Lennart Poettering [mailto:lenn...@poettering.net] > Sent: Monday, September 24, 2018 6:56 PM > To: Tiwari, Hari Sahaya <hari-sahaya.tiw...@hpe.com> > Cc: Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl>; > systemd-devel@lists.freedesktop.org > Subject: Re: [systemd-devel] systemd behavior during shutdown > > On Mi, 19.09.18 18:44, Tiwari, Hari Sahaya (hari-sahaya.tiw...@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@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 >> # 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@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 > _______________________________________________ > 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
