[systemd-devel] Systemd killed processes of custom services instead of graceful shutdown

Kamal Rathi kr30april at gmail.com
Mon Jun 15 11:18:48 UTC 2020


>> can you plesse only respond to the list to not break reply-to
I will use reply to all


>> useless unless you set "DefaultDependencies=no" which you shouldn't do
for normal services

>> if i remove all the service and only put After=grid.service, so it will
work similar way that how it is currently behaving correct.

so it doesn't make any difference if services will be in [Unit] section.
Even strange thing is that when  systemd-cgls as it is showing under
.user.slice, i think if service get started with systemd then it should
come under systemd.slice.
Mya be i can wrong about it as systemd is a vast subject and may be i
mis-understand something incorrectly.

I am just trying to understand and want to get some solution for my
services to be run flawlessly at boot.



On Mon, Jun 15, 2020 at 5:00 AM Reindl Harald <h.reindl at thelounge.net>
wrote:

> can you plesse only respond to the list to not break reply-to
>
> Am 15.06.20 um 11:49 schrieb Kamal Rathi:
> > can you answer the question why you did put that option at all into the
> > unit file and why do you add random options to your units like
> > "After=syslog.target systemd-user-sessions.service system.slice"
> >  I have added above options so that my script will start after
> > filesystems,network and user sessions are online and should be stopped
> > before those all services so that custom service will be first at
> > shutdown or at least before user.slice killed
>
> useless unless you set "DefaultDependencies=no" which you shouldn't do
> for normal services
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200615/99bf3404/attachment.htm>


More information about the systemd-devel mailing list