Re: systemd behavior during shutdown

["Tiwari, Hari Sahaya" <hari-sahaya.tiwari@xxxxxxx>]

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:lennart@xxxxxxxxxxxxxx] 
Sent: Friday, October 5, 2018 11:03 PM
To: Tiwari, Hari Sahaya <hari-sahaya.tiwari@xxxxxxx>
Cc: Andrei Borzenkov <arvidjaar@xxxxxxxxx>; systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re:  systemd behavior during shutdown

On Mi, 26.09.18 09:14, Tiwari, Hari Sahaya (hari-sahaya.tiwari@xxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel