Re: [systemd-devel] bpfilter blocks root unmount during shutdown
El 24-09-2018 a las 13:30, Andrei Borzenkov escribió: This process is spawned as special kernel thread, even though it is otherwise normal user process. WUT ? So how is this new kind of task supposed to be handled by userspace ? looks like a kernel bug to me. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [REMINDER] systemd hackfest/talkfest/BoF/miniconf
Heya! Here's just a quick reminder that we'll have a systemd hackfest this Sunday (2018-09-30) at All Systems Go! 2018, from 10am till 6pm. Please join us at the main conference venue in the "Gallerie" room. Many systemd core developers will be around, and we'll talk and work on anything attendees are interested in. Also see: https://cfp.all-systems-go.io/en/ASG2018/public/events/226 See you on sunday! 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
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 ? >> >> 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
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
