[systemd-devel] Behavior of RestartSec= & Restart= parameters
Hi, I had a query on RestartSec= & Restart= parameters and how they work with StartLimitInterval= & StartLimitBurst= parameters. I have a socket-service pair (say test.socket & test.service) test.socket [Unit] Description=Test socket [Socket] ListenDatagram=123 Accept=No [Install] WantedBy=sockets.target test.service [Unit] Description=test service Requires=test.socket [Service] Type=simple ExecStart=/bin/mytest StandardInput=socket [Install] WantedBy=multi-user.target I see that the test.socket fails with following error, systemd[1]: test.service: Start request repeated too quickly. systemd[1]: test.service: Failed with result 'exit-code'. systemd[1]: Failed to start test service. systemd[1]: test.socket: Failed with result 'service-start-limit-hit'. The test.socket fails after trying to start test.service for 5 times. I think this this is due to the default values of StartLimitInterval= & StartLimitBurst= which are 10sec and 5 respectively. The test.service restart is attempted even though there is no "Restart=" parameter is specified in the file. So, this means StartLimitInterval= & StartLimitBurst= are not dependent on "Restart=" parameter? Is my understanding correct ? Is there a way to add a delay before attempting to restart the service without specifying "Restart=" parameter? As per my understanding "RestartSec=" works only when "Restart=" parameter is set to some value. Thanks & Regards, Hari. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SSL_connect fails on systemd socket
Thanks for the response. Yes the server program need not bind and listen because systemd socket will do that. On “Accept=True” parameter, here the requirement is that systemd should accept the connection and handover it to server. My query was on post the connection accept by systemd. Once the regular connection is accepted, client does SSL_connect over same fd to establish SSL connection. Will this SSL connect request also be handled by systemd ? Regards, Hari. From: Mantas Mikulėnas [mailto:graw...@gmail.com] Sent: Tuesday, January 28, 2020 8:02 PM To: Tiwari, Hari Sahaya Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] SSL_connect fails on systemd socket On Tue, Jan 28, 2020 at 4:23 PM Tiwari, Hari Sahaya mailto:hari-sahaya.tiw...@hpe.com>> wrote: Hi, I am trying to implement a client server program over SSL through systemd. Here I have a TCP systemd socket (listening on a predefined port) and its associated service. systemd socket file:- # cat /usr/lib/systemd/system/test_ssl.socket [Unit] Description=Test socket [Socket] ListenStream=2000 Accept=true MaxConnections=900 [Install] WantedBy=sockets.target systemd service file:- # cat /usr/lib/systemd/system/test_ssl@.service<mailto:/usr/lib/systemd/system/test_ssl@.service> [Unit] Description= Test Service Requires=test_ssl.socket [Service] ExecStart=/home/SSL/server StandardInput=socket KillMode=process [Install] WantedBy=multi-user.target The service file invoke the binary /home/SSL/server. Here is it a very simple client server program, where 1. Server binds and listens on a port number. You need to remove this part if you want to use socket activation. The whole point of .socket units here is that systemd binds to the socket and passes the fd over to your service. If your service ignores the received fd and tries to create its own socket, it will never be able to receive the connections. By default, the service would receive the sockets as fd#3 and ahove (see https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html<https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html> for documentation), but because you use StandardInput=socket, it will receive the socket as fd#1. 2. Client first connects to server with normal connect (server will do accept) Your .socket specifies Accept=true, so you should remove this part as well: the option means that systemd itself will accept the connection and only hand your server the accepted socket. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SSL_connect fails on systemd socket
Hi, I am trying to implement a client server program over SSL through systemd. Here I have a TCP systemd socket (listening on a predefined port) and its associated service. systemd socket file:- # cat /usr/lib/systemd/system/test_ssl.socket [Unit] Description=Test socket [Socket] ListenStream=2000 Accept=true MaxConnections=900 [Install] WantedBy=sockets.target systemd service file:- # cat /usr/lib/systemd/system/test_ssl@.service [Unit] Description= Test Service Requires=test_ssl.socket [Service] ExecStart=/home/SSL/server StandardInput=socket KillMode=process [Install] WantedBy=multi-user.target The service file invoke the binary /home/SSL/server. Here is it a very simple client server program, where 1. Server binds and listens on a port number. 2. Client first connects to server with normal connect (server will do accept) 3. Once it gets the fd, client does the SSL_connect over same connection. (server will do SSL_accept) 4. After that it will be SSL_read & SSL_write. Once, I start the systemd socket I can see the systemd starts listening on port 2000. # systemctl start test_ssl.socket # netstat -an | grep 2000 tcp6 0 0 :::2000 :::*LISTEN Post than when executing client, SSL_conect fails. # ./client localhost 2000 OpenConnection succedeed. << normal connect succeeds. SSL_connect failed. 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365: Here client is able to do normal connect, post that SSL_connect fails. This client server program works well outside of systemd. Do I need to add some extra steps to get this working? Any help or reference would be appreciated. Thanks & Regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] service fails to use the latest value of the slice
Hello, I have one query on the behaviour I am overserving with systemd service. Below are the contents of service file, # cat /usr/lib/systemd/system/qs.service [Unit] Description=init script After=network.target [Service] ExecStartPre=/bin/sh /usr/local/cmcluster/bin/realtimeslice.sh -s /usr/lib/systemd/system/qs.service ExecStart=/usr/local/qs/bin/qs Type=simple [Install] WantedBy=multi-user.target What realtimeslice.sh does is to identify a slice having RT quantum (cpu.rt_runtime_us) as 95. Once the slice is identified the service attaches the binary mentioned in ExecStart to that slice. This is done because binary(/usr/local/qs/bin/qs) tries to set realtime priority. Now coming to the issue which I am facing, 1. Suppose I have 2 slices, A.slice (cpu.rt_runtime_us value = 95) and B.slice (cpu.rt_runtime_us value = 0) 2. Currently the service qs.service is attached to A.slice 3. Now I changed cpu.rt_runtime_us values for these slices: A.slice to 0 and B.slice to 95. 4. When I restart the service, ExecStartPre (i.e realtimeslice.sh) determines that B.slice is eligible slice and it updates the slice name in the configuration files and in drop-ins. 5. But Binary at ExecStart still doesn't see the updated slice info and fails to set the realtime priority. 6. If I restart the service again it is working fine and binary is able to set the realtime priority. Is it that systemd at its invocation caches the all the information (including slice values) and uses those values for ExecStart[Pre] ? Because in the next run it is working fine. Is there a way reload/refresh the settings done at ExecStartPre, so that it will reflect at ExecStart. Thanks & Regards, Hari. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd behavior during shutdown
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-cfg@8-127.0.0.1:5302-127.0.0.1:45234.service: Trying to enqueue job hacl-cfg@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:lenn...@poettering.net] Sent: Friday, October 5, 2018 11:03 PM To: Tiwari, Hari Sahaya Cc: Andrei Borzenkov ; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] systemd behavior during shutdown On Mi, 26.09.18 09:14, Tiwari, Hari Sahaya (hari-sahaya.tiw...@hpe.com) wrote: > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd behavior during shutdown
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-boun...@lists.freedesktop.org] On Behalf Of Andrei Borzenkov Sent: Tuesday, September 25, 2018 11:17 PM To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] systemd behavior during shutdown 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 > Cc: Zbigniew Jędrzejewski-Szmek ; > 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 ? >> >&
Re: [systemd-devel] systemd behavior during shutdown
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 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 Cc: Zbigniew Jędrzejewski-Szmek ; 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
Re: [systemd-devel] systemd behavior during shutdown
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' 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 Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] systemd behavior during shutdown On Wed, Sep 19, 2018 at 05:01:33AM +, 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
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 Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] systemd behavior during shutdown On Wed, Sep 19, 2018 at 05:01:33AM +, 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
[systemd-devel] systemd behavior during shutdown
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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
