safe and fast shutdown/reboot

[h.reindl@xxxxxxxxxxxxx (Reindl Harald)]

Am 16.03.2018 um 11:36 schrieb prashantkumar dhotre:
> 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.

that are all dirty workarounds and even if you manage to get it done 
expect it to be fragile because nobody else is running anything this way

what is so special about your services that they

a) take that long for a clean stop
b) you don't care at all at shutdown but at normal stop

> 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 ' )Â  ?
> 
> On Fri, Mar 16, 2018 at 1:19 PM, Andrei Borzenkov <arvidjaar at gmail.com 
> <mailto: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/7a30dfeb18d09940a844389e06b25ca2bca5e093/src/core/manager.c#L3833-L3836
>     <https://github.com/systemd/systemd/blob/7a30dfeb18d09940a844389e06b25ca2bca5e093/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