[systemd-devel] Has systemd booted up command

[Umut Tezduyar]

On Thu, Jul 18, 2013 at 7:06 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Thu, 18.07.13 10:08, Umut Tezduyar (umut at tezduyar.com) wrote:
>
>> Hi,
>>
>> This is in reference to
>> https://bugs.freedesktop.org/show_bug.cgi?id=66926 request.
>>
>> I have been polling systemd with  "systemctl is-active default.target"
>> to detect if boot up has been completed or not. I have noticed that
>> this is not enough though.
>>
>> It seems like starting a service that is not part of the initial job
>> tree can keep in state activating after default.target is reached. I
>> could use systemctl list-jobs to detect if there are still jobs
>> available but systemctl list-jobs's output is not meant for
>> programming.
>>
>> Same problem happens when I switch targets. Currently I rely on
>> systemctl list-jobs output to detect if the target switch has been
>> completed or not.
>>
>> What can we do about it?
>>
>> One way would be having a command "systemctl job-count", other would
>> be having a command "systemctl has-booted" or something similar?
>>
>> Any thoughts?
>
> systemctl job-count is available in "systemctl show -p NJobs". You can
> query this property easily via D-Bus too.
>
> It should be relatively easy to write a tool that waits for the boot to
> "complete", as we send out a StartupFinished signal in that case, and
> "systemctl show -p Progress" will tell you as a fractional between 0 and
> 1 how far the boot completed so far. However, the problem I have with
> adding this is the weak definition of "finished start-up". For example,
> StartupFinished is actually sent out as soon as the job queue ran empty
> for the first time (i.e. NJobs is 0). But you already want something
> slightly different there, and also wait for some later jobs? And of
> course, such a concept still wouldn't include desktop initialization times and
> suchlike, so I am not totally convinced we could find an approach that
> is sufficientlly well-defined that it works for most people, not just
> some. If you follow what I mean...
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.

Hi,

Implementing a tool that catches the dbus signal, like you have said
must be relatively easy. In fact I believe it should be possible to do
it by dbus-monitor but the main problem is, tool itself must be
started by systemd as a service with a Before={target you are booting
to}. Otherwise you cannot be sure if the StartupFinished signal has
been sent before the tool starts.

To begin with, I see the need of having a command that outputs OK or
Not OK depending on StartupFinished sent or not. Like you said though,
there is a way to do it as "systemctl is-active default.target &&
systemctl shop -pNJobs | grep -q Njobs=0". Why would I want to know
this? Because, I would like to start a test suite on my device as soon
as the device reaches to a complete state. Or, I would like to gather
statistics on the complete state. I do believe that this must be a
common use case.

The other need is coming due to an item in our TODO list which is,
"when isolating, try to figure out a way how we implicitly can order
all units we stop before the isolating unit...". Since the stop jobs
are asynchronous, I would be using following command to make sure that
isolation is fully complete: "systemctl is-active MyIsolated.target &&
systemctl show -pNJobs | grep -q Njobs=0". I do believe, this might
not be a common use case and I can live with parsing the output of
"systemctl show -pNJobs".

Thanks,
Umut