Re: [systemd-devel] Has systemd booted up command

2013-09-11 Thread Lennart Poettering
On Thu, 18.07.13 20:36, Umut Tezduyar (u...@tezduyar.com) wrote:

Hey,

 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.

This won't work. If you run the tool as a service like you suggest then
this service will have a job queued as long as it is running and you
will hence never get StartupFinished since your own tool is still queued.

 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.

Note that if two units are ordered against each other (regardles whether
with Before= or After=) and a stop job is queued for one of them, and a
start job is queued for the other, then the stop job will always be
executed first, the start job second. Hence it is sufficient to simply
order all units you want to have finished before or after your isolated
unit and you get what you need.

It's usually safer (and less deadlock-prone) to use systemd's own job
queuing rather than attempting your own on the side...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Has systemd booted up command

2013-07-18 Thread Umut Tezduyar
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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Has systemd booted up command

2013-07-18 Thread Lennart Poettering
On Thu, 18.07.13 10:08, Umut Tezduyar (u...@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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Has systemd booted up command

2013-07-18 Thread Umut Tezduyar
On Thu, Jul 18, 2013 at 7:06 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 18.07.13 10:08, Umut Tezduyar (u...@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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Has systemd booted up command

2013-07-18 Thread Hoyer, Marko (ADITG/SW2)
 -Original Message-
 From: systemd-devel-bounces+mhoyer=de.adit-jv@lists.freedesktop.org
 [mailto:systemd-devel-bounces+mhoyer=de.adit-jv@lists.freedesktop.org] On
 Behalf Of Umut Tezduyar
 Sent: Thursday, July 18, 2013 8:38 PM
 To: Lennart Poettering
 Cc: Mailing-List systemd
 Subject: Re: [systemd-devel] Has systemd booted up command
 
 On Thu, Jul 18, 2013 at 7:06 PM, Lennart Poettering lenn...@poettering.net
 wrote:
  On Thu, 18.07.13 10:08, Umut Tezduyar (u...@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?

Why not simply writing a unit notify_default_target_done.service that
- is linked into multi-user.target.wants
- and defines: After=default.target

Should work  to my understanding ...


Cheers,

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