safe and fast shutdown/reboot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks
I understand that
'systemctl isolate other.target' will stop all present services and start
services of other.target

My thinking is :
I can put all my apps in my.target
and my.target can start after multi-user.target.

When shutting down , somewhere first i will do 'systemctl iso
multi-user.target' so that all my services in my.target will stop.
but my understanding is this will stop my services with SIGTERM
but i want them to be killed with SIGKILL.
Is there a way to SIGKILL my services in my.target when i do  'systemctl
iso multi-user.target' (something equivalent to concept of  ' systemctl iso
multi-user.target --signal= SIGKILL  ' )  ?

Regards



On Fri, Mar 16, 2018 at 1:19 PM, Andrei Borzenkov <arvidjaar at gmail.com>
wrote:

> 16.03.2018 10:19, aleivag пиÑ?еÑ?:
> >>
> >>
> >> Won't work. Status changes only when job for a unit completes and jobs
> >> are executed in order of dependencies. Actually, jobs are *queued* in
> >> order of dependencies so nothing would indicate that you are going to
> >> shutdown until it is too late (i.e. all normal services are stopped).
> >>
> >>
> > yes, but those units have started, so during a `systemctl reboot` you can
> > execute
> >
> > [~] systemctl list-jobs shutdown.target reboot.target
> >  JOB UNIT            TYPE  STATE
> > 1972 reboot.target   start waiting
> > 1974 shutdown.target start waiting
> >
> > 2 jobs listed.
> >
> > and get if shutdown has started
> >
>
> Yes, you are right. I'm sure I have seen cases when jobs were not
> present in other cases so I assumed it will be here as well.
>
> > the other thing that may help you know if you are in shutdown mode is
> > execute `systemctl is-system-running`  and then check if returns
> `stopping`,
> > during a shutdown is suppose to return something like that. and i think
> it
> > does this by checking is shutdown.target has started (
> > https://github.com/systemd/systemd/blob/7a30dfeb18d09940a844389e06b25c
> a2bca5e093/src/core/manager.c#L3833-L3836
> > )
> >
>
> Yes, could be more reliable.
>
> >
> > Logically runlevel is not changed until *after* new runlevel has been
> >> reached. Practically systemd does not update runlevel during shutdown at
> >> all.
> >
> >
> > yeap, you are right here, i was wrong :D
> >
>
> _______________________________________________
> 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/20180316/844c1a0a/attachment.html>


[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux