Re: [systemd-devel] How to debug why a unit is started when?

[Andrei Borzenkov]

16.03.2018 18:49, Paul Menzel пишет:
> Dear systemd folks,
> 
> 
> I am trying to get the GDM login screen started earlier on a Dell XPS 13
> 9370 with Debian Sid/unstable system with systemd 238. Currently, after
> selecting the Linux kernel in GRUB it’s only displayed after roughly
> eight to ten seconds while Linux takes around two seconds [1].
> 
> Using systemd-bootchart I see that GDM is started quite late [1], and I
> wondering if there is an option to find out why.
> 
> GDM’s service unit [2] has the “dependencies” below.
> 
>     After=rc-local.service plymouth-start.service
> systemd-user-sessions.service
> 
> Is there a debug option, where systemd says, why a certain unit is
> started? For example, reached target X and therefore starting Y.
> 

systemctl --after (--recursive) --list-dependencies gdm.service

may be the first step. Or use systemd-analyze chart to see full picture
of what was started when.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to debug why a unit is started when?

[Tomasz Torcz ️]

On Fri, Mar 16, 2018 at 04:49:28PM +0100, Paul Menzel wrote:
> Dear systemd folks,
> 
> 
> I am trying to get the GDM login screen started earlier on a Dell XPS 13
> 9370 with Debian Sid/unstable system with systemd 238. Currently, after
> selecting the Linux kernel in GRUB it’s only displayed after roughly eight
> to ten seconds while Linux takes around two seconds [1].
> 
> Using systemd-bootchart I see that GDM is started quite late [1], and I
> wondering if there is an option to find out why.

  Not a direct answer to your question, but you can use systemd-bootchart
to get graphical timeline of how long did it take to start different
units.  Then you will have to find box for GDM and see which other
boxes ended at the moment GDM started.

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to debug why a unit is started when?

[Paul Menzel]

Dear systemd folks,


I am trying to get the GDM login screen started earlier on a Dell XPS 13 
9370 with Debian Sid/unstable system with systemd 238. Currently, after 
selecting the Linux kernel in GRUB it’s only displayed after roughly 
eight to ten seconds while Linux takes around two seconds [1].


Using systemd-bootchart I see that GDM is started quite late [1], and I 
wondering if there is an option to find out why.


GDM’s service unit [2] has the “dependencies” below.

After=rc-local.service plymouth-start.service 
systemd-user-sessions.service


Is there a debug option, where systemd says, why a certain unit is 
started? For example, reached target X and therefore starting Y.



Kind regards,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=794336
[2] https://git.gnome.org/browse/gdm/tree/data/gdm.service.in



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] safe and fast shutdown/reboot

[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 > 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


> )
>

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] safe and fast shutdown/reboot

[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.

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 
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 UNITTYPE  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@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] safe and fast shutdown/reboot

[Andrei Borzenkov]

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 UNITTYPE  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
> )
> 

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] safe and fast shutdown/reboot

[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 UNITTYPE  STATE
1972 reboot.target   start waiting
1974 shutdown.target start waiting

2 jobs listed.

and get if shutdown has started

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
)


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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel