Re: [systemd-devel] systemd services via SSH (-H key)

2015-10-22 Thread Ivan Shapovalov
On 2015-10-22 at 23:12 +0200, Reindl Harald wrote:
> [...]
> and why not simply "timedatectl -H user@host[:port]" since host:port
> is 
> a well known protocol agnostic way to specify a non-default port?

Because the syntax of -H parameter is "[user@]host[:container]"
and it does not allow specifying an explicit port number.

Why don't you read manpages before replying?

-- 
Ivan Shapovalov / intelfx /



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists

2015-08-13 Thread Ivan Shapovalov
On 2015-08-10 at 15:46 +0200, Reindl Harald wrote:
 
 Am 10.08.2015 um 15:28 schrieb Ivan Shapovalov:
  On 2015-08-10 at 15:14 +0200, Reindl Harald wrote:
   
   Am 10.08.2015 um 15:05 schrieb Ivan Shapovalov:
On 2015-08-10 at 11:16 +0200, Reindl Harald wrote:
Moreover,

 
 * RuntimeDirectory is a service configuration
 * the daemon is started as unprivileged user
 * RuntimeDirectory should be created long before
  ExecStart / ExecStartPost

This is wrong. The runtime directory will be created ...
when
the unit is started, and removed when the unit is stopped.
   
   what is wrong?
  
  The runtime directory should be created right before the unit is
  started, not long before ExecStart / ExecStartPost.
 
 so why trying to create it before ExecStart *and* ExecStartPost

Because there may be no ExecStart= but ExecStartPost=.

   unit is started is for me pretty clear the whole systemd-unit
   
As can be seen from the code, the runtime directory creation is
attempted on execution of each configured process, be it
ExecStart=
or
ExecStartPost= (or whatever else)
   
   and why in the world is the code written that way?
  
  This is pointless rhetoric.
 
 no it is not pointless rhetoric
 it's a serious question

See above.

Doing explicit checks against existence of certain entries or
implementing an ad-hoc FSM is way more fragile than just writing
idempotent code.


 
   there is no logical reason that RuntimeDirectory created once
   would
   disappear while starting the other processes as well as
   tempfiles.d
   which get replaced by RuntimeDirectory isn't fired all the time
  
  Why do you think that it would disappear between starting two
  processes
  belonging to the same unit?
 
 why do the developers think that?

See above.

 if they don't think so why attempt creation for *each configured 
 process* of the same systemd-unit?
 
  The runtime directory is destroyed when a
  unit enters inactive state. systemd always attempts to create it
  when
  it forks off a control process, just (I guess) because it's more
  robust
  to do it that way rather than to implement a separate state machine
  just for that purpose. Now, there was a TOCTOU-style race
  condition,
  and it got fixed indeed as far as I can see
 
 yes, the race condition seems now to be fixed
 
 but it would have been impossible to happen if *really* The runtime 
 directory should be created right before the unit is started would
 be 
 the implementation because there would be no second (needless) attemt 
 to create it

See above.

-- 
Ivan Shapovalov / intelfx /

 but a single point of early code which creates it with the 
 correct permissions and any following ExecStart* could rely that it 
 exists

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists

2015-08-10 Thread Ivan Shapovalov
On 2015-08-10 at 11:16 +0200, Reindl Harald wrote:
 
 Am 10.08.2015 um 07:57 schrieb Ivan Shapovalov:
  On 2015-08-06 at 15:01 +0200, Michael Biebl wrote:
   2015-08-06 14:43 GMT+02:00 Reindl Harald h.rei...@thelounge.net
   :
well, but Type=simple is default and recommended everywhere
because there
is no main-pid to guess and the with Restart=always monitored 
is
in fact
ExecStart
   
   Actually, Type=simple has its own share of problems:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913
  
  That's a direct consequence of Type=simple semantics. From 
  systemd's
  standpoint, a daemon which crashes 10ms after start-up due to bad
  config is indistinguishable from a daemon which crashes 10hrs after
  starting due to an internal error.
  
  To make things more robust, the daemon should either *properly*
  implement Type=forking (i. e. fork only after initial start-up)
  or it should implement Type=notify
 
 sorry but in context of the topic that's wrong

Moreover,

 
 * RuntimeDirectory is a service configuration
 * the daemon is started as unprivileged user
 * RuntimeDirectory should be created long before
ExecStart / ExecStartPost

This is wrong. The runtime directory will be created ... when
the unit is started, and removed when the unit is stopped.

As can be seen from the code, the runtime directory creation is
attempted on execution of each configured process, be it ExecStart= or
ExecStartPost= (or whatever else).

-- 
Ivan Shapovalov / intelfx /

 and hence i wonder how
there can exist a race condition at all, there
is no valid reason trying to create it twice



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists

2015-08-10 Thread Ivan Shapovalov
On 2015-08-10 at 15:14 +0200, Reindl Harald wrote:
 
 Am 10.08.2015 um 15:05 schrieb Ivan Shapovalov:
  On 2015-08-10 at 11:16 +0200, Reindl Harald wrote:
  Moreover,
  
   
   * RuntimeDirectory is a service configuration
   * the daemon is started as unprivileged user
   * RuntimeDirectory should be created long before
   ExecStart / ExecStartPost
  
  This is wrong. The runtime directory will be created ... when
  the unit is started, and removed when the unit is stopped.
 
 what is wrong?

The runtime directory should be created right before the unit is
started, not long before ExecStart / ExecStartPost.

 
 unit is started is for me pretty clear the whole systemd-unit
 
  As can be seen from the code, the runtime directory creation is
  attempted on execution of each configured process, be it ExecStart= 
  or
  ExecStartPost= (or whatever else)
 
 and why in the world is the code written that way?

This is pointless rhetoric.

 
 there is no logical reason that RuntimeDirectory created once would 
 disappear while starting the other processes as well as tempfiles.d 
 which get replaced by RuntimeDirectory isn't fired all the time

Why do you think that it would disappear between starting two processes
belonging to the same unit? The runtime directory is destroyed when a
unit enters inactive state. systemd always attempts to create it when
it forks off a control process, just (I guess) because it's more robust
to do it that way rather than to implement a separate state machine
just for that purpose. Now, there was a TOCTOU-style race condition,
and it got fixed indeed as far as I can see.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists

2015-08-09 Thread Ivan Shapovalov
On 2015-08-06 at 15:01 +0200, Michael Biebl wrote:
 2015-08-06 14:43 GMT+02:00 Reindl Harald h.rei...@thelounge.net:
  well, but Type=simple is default and recommended everywhere 
  because there
  is no main-pid to guess and the with Restart=always monitored is 
  in fact
  ExecStart
 
 
 Actually, Type=simple has its own share of problems:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913

That's a direct consequence of Type=simple semantics. From systemd's
standpoint, a daemon which crashes 10ms after start-up due to bad
config is indistinguishable from a daemon which crashes 10hrs after
starting due to an internal error.

To make things more robust, the daemon should either *properly*
implement Type=forking (i. e. fork only after initial start-up)
or it should implement Type=notify.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] oneshot service

2015-07-07 Thread Ivan Shapovalov
On 2015-07-07 at 13:04 -0400, Ernast Sevo wrote:
 Apologies that was mistakenly sent. The example service is below.
 
 [Unit]
 Before=local-fs.target
 After=some service
 DefaultDependencies=false
 
 [Service]
 Type=oneshot
 ExecStart=/usr/bin/xxx
 RemainAfterExit=yes
 
 [Install]
 WantedBy=local-fs.target
 
 The problem is I can see boot-up continue prior to this service doing
 its job. I am not sure if I am missing
 something but I haven't come across anything in the documentation 
 that
 can help. The service finishes its job
 later but something's that depend on it have already failed and have
 not waited for it to finish doing what it is doing.
 
 Any thoughts as to what could be causing this?

Two questions.

1) Does the /usr/bin/xxx program fork? A fork will not be waited for;
systemd will consider the unit active right when the initially
started process exits.

2) Remember, in absence of ordering dependencies (Before=/After=)
everything in systemd is started in parallel. Oneshot services are not
an exception: they do not pause everything, they are just kept in
starting state until the process exits.
What exactly do you want to serialize against start-up of your service?

Side-note: Most common services will get implicitly ordered after
your service with a chain like this:
xxx.service - local-fs.target - sysinit.target - basic.target - ...
However, early-boot services (which have DefaultDependencies=false as
well) will _not_ get ordered against your service in any way.

HTHs,
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

2015-05-15 Thread Ivan Shapovalov
On 2015-05-14 at 22:31 +0200, Lennart Poettering wrote:
 On Thu, 07.05.15 04:37, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  On 2015-05-06 at 18:59 +0200, Lennart Poettering wrote:
   On Wed, 06.05.15 19:53, Andrei Borzenkov (arvidj...@gmail.com) 
   wrote:
   
I still think that being able to define and start group of 
units 
as one
unit (pun unintended) is better in the long run.

This really far exceeds original scope of systemd-run which was
quickly start something under systemd supervision. When we 
have
complex set of units with interdependency either systemd-run is 
the
wrong tool for it or it should do it right, not paper over.
   
   Hmm, you actually have a point, and we already *do* support 
   queuing
   groups of units, and that should suffice for this usecase, so 
   that we
   don't need to allow definiton of reverse deps.
   
   This is actually already used for the time-based systemd-run 
   stuff,
   where we create both a transient timer and a transient service 
   unit
   and then start the timer unit.
   
   Ivan, what you are trying to do hence should already work just 
   fine 
   in
   the lower level apis, using the auxiliary list of units that 
   the
   StartTransientUnt() bus call takes. systemd-run doesn't 
   generically
   open this up yet though (and i dont know how it could do so 
   nicely).
  
  Yeah, auxiliary units could help here, though they suffer from the 
  same
  kind of problem: either auxiliary units are read from message and
  created before the main one, or vice versa. The problems are the 
  same
  as with two consecutive StartTransientUnit calls.
 
 Hmm, if , I think this should be fixable though. Already, allocating 
 a
 unit, loading a unit and starting a unit are three separate steps. It
 shouldn't be too hard to fix PID 1 to allow allocating all transient
 units to create in a group first, then in a second step load all of
 them, and finally start one of them. With such an order in place it
 should be easily possible to do what you want to do, no?

Yeah, makes sense. I'll try to do that in meantime.

BTW, regarding creating aux units from systemd-run(1). I guess it can
be done in two ways:

- --aux-unit parameter which adds another aux unit and makes all
following parameters (until another --aux-unit) set parameters of this
new aux unit (i. e. stateful command line);

- --aux-units-from-file parameter or something like that which reads
the given file and parses each line of it as a separate command line,
creating an aux unit from it.

The former would look like this:

$ systemd-run --name foo.service -p Wants=aux-1.service /bin/foo \
--aux-unit --name aux-1.service -p BindsTo=foo.service /bin/aux-1

The latter (in bash syntax) would look like this:

$ systemd-run --name foo.service -p Wants=aux-1.service /bin/foo \
  --aux-units-from-file /dev/stdin -EOF
--name aux-1.service -p BindsTo=foo.service /bin/aux-1
EOF

Would any of this be OK?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

2015-05-15 Thread Ivan Shapovalov
On 2015-05-15 at 11:54 +0200, Lennart Poettering wrote:
 On Fri, 15.05.15 11:38, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
   Hmm, if , I think this should be fixable though. Already,
   allocating a unit, loading a unit and starting a unit are three
   separate steps. It shouldn't be too hard to fix PID 1 to allow
   allocating all transient units to create in a group first, then 
   in
   a second step load all of them, and finally start one of
   them. With such an order in place it should be easily possible to
   do what you want to do, no?
  
  Yeah, makes sense. I'll try to do that in meantime.
  
  BTW, regarding creating aux units from systemd-run(1). I guess it 
  can
  be done in two ways:
  
  - --aux-unit parameter which adds another aux unit and makes all
  following parameters (until another --aux-unit) set parameters of 
  this
  new aux unit (i. e. stateful command line);
  
  - --aux-units-from-file parameter or something like that which 
  reads
  the given file and parses each line of it as a separate command 
  line,
  creating an aux unit from it.
  
  The former would look like this:
  
  $ systemd-run --name foo.service -p Wants=aux-1.service /bin/foo \
  --aux-unit --name aux-1.service -p BindsTo=foo.service /bin/aux-1
  
  The latter (in bash syntax) would look like this:
  
  $ systemd-run --name foo.service -p Wants=aux-1.service /bin/foo \
--aux-units-from-file /dev/stdin -EOF
  --name aux-1.service -p BindsTo=foo.service /bin/aux-1
  EOF
  
  Would any of this be OK?
 
 Hmm, what about this: use -- as separator for multiple unit
 definitions?
 
 $ systemd-run --name=foo.service /bin/foo -- --name=bar.service -p
   Nice=80 /bin/bar -- -p Nice=20 --name=bazz.service /usr/bin/bazz
 
 Alternatively, we could use ; as separator, similar to 
 /usr/bin/find
 does it... But I think -- is nicer...

Hm. Actually, usage of *any* token as a command line separator makes it
impossible to include that token *in* the command line. My original
idea is even worse as it disallows ever giving --aux-unit switch to
the client program. So I guess I retract that idea...
What about the second one?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

2015-05-06 Thread Ivan Shapovalov
On 2015-05-06 at 09:16 +0300, Andrei Borzenkov wrote:
 On Wed, May 6, 2015 at 5:52 AM, Ivan Shapovalov intelfx...@gmail.com
  wrote:
  On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote:
   On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx...@gmail.com) 
   wrote:
   
- do `systemd-run` twice and somehow set up the dependencies
between
  two transient units
   
   I'd be happy to take a patch that allows configuring deps for
   transient units when constructing them.
  
  Hi Lennart,
  
  I've just done this (also added manager-side support for
  JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, 
  this
  turned out to be insufficient for my usecase.
  
  I have to start two transient services, say, A.service and 
  B.service,
  and
  
  - B.service needs A.service
(i. e. B.service Requires=A.service and After=A.service)
  
  - A.service must be stopped as soon as B.service exits
(i. e. A.service BindsTo=B.service)
  
  And there is a contradiction: I can't make a dependency on an
  inexistent unit.
  If I create A.service before B.service, I can't set BindsTo=, and 
  if I
  create B.service before A.service, I can't set Requires= and 
  After=.
  
  Locally, I've solved this by allowing inverse dependencies to be 
  set
  over the bus. That is, I make B.service BoundBy=A.service. Is this
  acceptable for upstream?
  
 
 What about adding option --define-only (I do not care about actual
 name) that adds unit definition but does not start unit? Then you can
 define any number of transient units and then systemctl start them
 later.

I'm unsure how to fit this into the GC logic. Transient units get
unloaded (and hence removed from disk) once they become inactive.

If we create a transient unit without starting it at the same time
(before the GC has a chance to run), it will be immediately removed.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

2015-05-06 Thread Ivan Shapovalov
On 2015-05-06 at 18:59 +0200, Lennart Poettering wrote:
 On Wed, 06.05.15 19:53, Andrei Borzenkov (arvidj...@gmail.com) wrote:
 
  I still think that being able to define and start group of units 
  as one
  unit (pun unintended) is better in the long run.
  
  This really far exceeds original scope of systemd-run which was
  quickly start something under systemd supervision. When we have
  complex set of units with interdependency either systemd-run is the
  wrong tool for it or it should do it right, not paper over.
 
 Hmm, you actually have a point, and we already *do* support queuing
 groups of units, and that should suffice for this usecase, so that we
 don't need to allow definiton of reverse deps.
 
 This is actually already used for the time-based systemd-run stuff,
 where we create both a transient timer and a transient service unit
 and then start the timer unit.
 
 Ivan, what you are trying to do hence should already work just fine 
 in
 the lower level apis, using the auxiliary list of units that the
 StartTransientUnt() bus call takes. systemd-run doesn't generically
 open this up yet though (and i dont know how it could do so nicely).

Yeah, auxiliary units could help here, though they suffer from the same
kind of problem: either auxiliary units are read from message and
created before the main one, or vice versa. The problems are the same
as with two consecutive StartTransientUnit calls.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

2015-05-05 Thread Ivan Shapovalov
On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote:
 On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  - do `systemd-run` twice and somehow set up the dependencies 
  between
two transient units
 
 I'd be happy to take a patch that allows configuring deps for
 transient units when constructing them.

Hi Lennart,

I've just done this (also added manager-side support for
JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, this
turned out to be insufficient for my usecase.

I have to start two transient services, say, A.service and B.service,
and

- B.service needs A.service
  (i. e. B.service Requires=A.service and After=A.service)

- A.service must be stopped as soon as B.service exits
  (i. e. A.service BindsTo=B.service)

And there is a contradiction: I can't make a dependency on an
inexistent unit.
If I create A.service before B.service, I can't set BindsTo=, and if I
create B.service before A.service, I can't set Requires= and After=.

Locally, I've solved this by allowing inverse dependencies to be set
over the bus. That is, I make B.service BoundBy=A.service. Is this
acceptable for upstream?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-04-27 Thread Ivan Shapovalov
On 2015-04-27 at 17:14 +0200, Lennart Poettering wrote:
 On Sat, 25.04.15 05:48, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  On 2015-04-25 at 04:00 +0300, Ivan Shapovalov wrote:
   On 2015-04-24 at 16:04 +0200, Lennart Poettering wrote:
[...]

Actually, it really is about the UNIT_TRIGGERS dependencies 
only,
since we don't do the retroactive deps stuff at all when we are
coldplugging, it's conditionalized in m-n_reloading = 0.
   
   So, I think I understand the problem. We should do this not only 
   for
   UNIT_TRIGGERS, but also for any dependencies which may matter
   when activating that unit. That is, anything which is referenced 
   by
   transaction_add_job_and_dependencies()... recursively.
  
  Here is what I have in mind. Don't know whether this is correct, 
  but
  it fixes the problem for me.
  
  From 515d878e526e52fc154874e93a4c97555ebd8cff Mon Sep 17 00:00:00 
  2001
  From: Ivan Shapovalov intelfx...@gmail.com
  Date: Sat, 25 Apr 2015 04:57:59 +0300
  Subject: [PATCH] core: coldplug all units which participate in jobs
  
  This is yet another attempt to fix coldplugging order (more 
  especially,
  the problem which happens when one creates a job during 
  coldplugging, and
  it references a not-yet-coldplugged unit).
  
  Now we forcibly coldplug all units which participate in jobs. This
  is a superset of previously implemented handling of the 
  UNIT_TRIGGERS
  dependencies, so that handling is removed.
  ---
   src/core/transaction.c | 6 ++
   src/core/unit.c| 8 
   2 files changed, 6 insertions(+), 8 deletions(-)
  
  diff --git a/src/core/transaction.c b/src/core/transaction.c
  index 5974b1e..a02c02c 100644
  --- a/src/core/transaction.c
  +++ b/src/core/transaction.c
  @@ -848,6 +848,12 @@ int transaction_add_job_and_dependencies(
   assert(type  _JOB_TYPE_MAX_IN_TRANSACTION);
   assert(unit);
   
  +/* Before adding jobs for this unit, let's ensure that 
  its state has been loaded.
  + * This matters when jobs are spawned as part of 
  coldplugging itself (see. e. g. path_coldplug().
  + * This way, we recursively coldplug units, ensuring 
  that we do not look at state of
  + * not-yet-coldplugged units. */
  +unit_coldplug(unit);
 
 I like the simplicity of this patch actually, but it's unfortunately
 too simple: coldplugging is to be applied only for services that are
 around at the time we come back from a reload. If you start a service
 during runtime, without any reloading anywhere around, we should not
 coldplug at all.
 
 I figure we need a coldplugging bool or so in Manager, which we set
 while coldplugging and can then check here.

Yeah, right, I've fixed it locally but forgot to send a follow-up mail.
Actually, isn't it unit-manager-n_reloading  0?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCHv3] core: coldplug all units which participate in jobs during coldplugging

2015-04-27 Thread Ivan Shapovalov
This is yet another attempt to fix coldplugging order (more especially,
the problem which happens when one creates a job during coldplugging and
it references a not-yet-coldplugged unit).

Now we forcibly coldplug all units which participate in jobs. This
is a superset of previously implemented handling of the UNIT_TRIGGERS
dependencies, so that handling is removed.

http://lists.freedesktop.org/archives/systemd-devel/2015-April/031212.html
https://bugs.freedesktop.org/show_bug.cgi?id=88401 (once again)
---
 src/core/transaction.c | 7 +++
 src/core/unit.c| 8 
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/core/transaction.c b/src/core/transaction.c
index 5974b1e..6e39809 100644
--- a/src/core/transaction.c
+++ b/src/core/transaction.c
@@ -848,6 +848,13 @@ int transaction_add_job_and_dependencies(
 assert(type  _JOB_TYPE_MAX_IN_TRANSACTION);
 assert(unit);
 
+/* Before adding jobs for this unit, let's ensure that its state has 
been loaded
+ * This matters when jobs are spawned as part of coldplugging itself 
(see e. g. path_coldplug()).
+ * This way, we recursively coldplug units, ensuring that we do not 
look at state of
+ * not-yet-coldplugged units. */
+if (unit-manager-n_reloading  0)
+unit_coldplug(unit);
+
 /* log_debug(Pulling in %s/%s from %s/%s, */
 /*   unit-id, job_type_to_string(type), */
 /*   by ? by-unit-id : NA, */
diff --git a/src/core/unit.c b/src/core/unit.c
index 2b356e2..996b648 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -2889,14 +2889,6 @@ int unit_coldplug(Unit *u) {
 
 u-coldplugged = true;
 
-/* Make sure everything that we might pull in through
- * triggering is coldplugged before us */
-SET_FOREACH(other, u-dependencies[UNIT_TRIGGERS], i) {
-r = unit_coldplug(other);
-if (r  0)
-return r;
-}
-
 if (UNIT_VTABLE(u)-coldplug) {
 r = UNIT_VTABLE(u)-coldplug(u);
 if (r  0)
-- 
2.3.6

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


Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-04-24 Thread Ivan Shapovalov
not yet marked)On 2015-04-24 at 15:52 +0200, Lennart Poettering wrote:
 On Wed, 25.02.15 21:40, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
 Ivan,
 
  Because the order of coldplugging is not defined, we can reference 
  a
  not-yet-coldplugged unit and read its state while it has not yet 
  been
  set to a meaningful value.
  
  This way, already active units may get started again.
 
  We fix this by deferring such actions until all units have been at 
  least
  somehow coldplugged.
  
  Fixes https://bugs.freedesktop.org/show_bug.cgi?id=88401
 
 Hmm, so firstly, in this case, do those two alsa services 
 have RemainAfterExit=yes set? I mean, if they have not, they really
 should. I they have, then queuing jobs for them a second time is not
 really an issue, because the services are already running they will 
 be
 eaten up eventually.

They do not, but this is actually irrelevant to the root issue.
Setting RemainAfterExit=yes will simply hide it. Actually, in this bug
the basic.target is started second time.

IOW, the point is: no matter what is the configuration of units, none
of them should be re-run on reload (given no configuration changes).

 
 But regarding the patch:
 
 I am sorry, but we really should find a different way to fix this, if
 there really is an issue to fix...
 
 I really don't like the hashmap that maps units to functions. I mean,
 the whole concept of unit vtables exists to encapsulate the
 unit-type-specific functions, and we should not add different place
 for configuring those.

I agree, this is not the cleanest solution. But at least it gets the
semantics right, and I've waited for comments/suggestions for ~1month
before actually sending this patch... Revert as you see fit, let's
just make sure we eventually come up with a solution.

 
 Also, and more importantly, the whole coldplug function exists only 
 to
 seperate the unit loading and initial state changing into two 
 separate
 steps, so that we know that all units are fully loaded before we 
 start
 making state chnages.
 
 Now, I see that this falls short of the issue at hand here,

Yes, exactly. The problem is that during coldplug we may accidentally
look at the state of not-yet-coldplugged units.

 but I
 think the right fix is really to alter the order in which we
 coldplug. More specifically, I think we need to make the coldplugging
 order dependency aware:
 
 before we coldplug a unit, we should coldplug all units it might
 trigger, which are those with a listed UNIT_TRIGGERS dependency, as
 well as all those that retroactively_start_dependencies() and
 retroactively_stop_dependencies() operates on. Of course, we should
 also avoid running in loops here, but that should be easy by keeping 
 a
 per-unit coldplug boolean around.
 
 Anyway, I reverted the patch for now, this really needs more 
 thinking.

I think I agree with this idea. I just didn't know how to handle
potentially unbounded recursion. Maybe we can do something along these
lines (pseudocode):

while (any units left to coldplug)
for (unit in hashmap)
if (not yet marked)
if (all deps of unit are coldplugged)
coldplug_and_mark(unit);

That is, we will repeatedly loop over hashmap, coldplugging only those
units whose UNIT_TRIGGERS are already coldplugged, and leaving other
units for next outer iteration.

Makes sense?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-04-24 Thread Ivan Shapovalov
On 2015-04-24 at 16:04 +0200, Lennart Poettering wrote:
 On Fri, 24.04.15 15:52, Lennart Poettering (lenn...@poettering.net) 
 wrote:
 
  before we coldplug a unit, we should coldplug all units it might
  trigger, which are those with a listed UNIT_TRIGGERS dependency, as
  well as all those that retroactively_start_dependencies() and
  retroactively_stop_dependencies() operates on. Of course, we should
  also avoid running in loops here, but that should be easy by 
  keeping a
  per-unit coldplug boolean around.
 
 Actually, it really is about the UNIT_TRIGGERS dependencies only,
 since we don't do the retroactive deps stuff at all when we are
 coldplugging, it's conditionalized in m-n_reloading = 0.

So, I think I understand the problem. We should do this not only for
UNIT_TRIGGERS, but also for any dependencies which may matter
when activating that unit. That is, anything which is referenced by
transaction_add_job_and_dependencies()... recursively.

To illustrate:

- A.path triggers A.service
- A.service requires basic.target
- we begin coldplugging
- we coldplug A.path
- by your patch, we first coldplug A.service
  - A.service is now active
- we continue coldplugging A.path
  - NB: basic.target is not coldplugged yet!
- A.path enters running and starts A.service
- transaction_add_job_and_dependencies() adds jobs for
  all dependencies of A.service
- at this point we're fucked up:
  basic.target is not coldplugged, but a job is added for it

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-04-24 Thread Ivan Shapovalov
On 2015-04-25 at 04:00 +0300, Ivan Shapovalov wrote:
 On 2015-04-24 at 16:04 +0200, Lennart Poettering wrote:
  [...]
  
  Actually, it really is about the UNIT_TRIGGERS dependencies only,
  since we don't do the retroactive deps stuff at all when we are
  coldplugging, it's conditionalized in m-n_reloading = 0.
 
 So, I think I understand the problem. We should do this not only for
 UNIT_TRIGGERS, but also for any dependencies which may matter
 when activating that unit. That is, anything which is referenced by
 transaction_add_job_and_dependencies()... recursively.

Here is what I have in mind. Don't know whether this is correct, but
it fixes the problem for me.

From 515d878e526e52fc154874e93a4c97555ebd8cff Mon Sep 17 00:00:00 2001
From: Ivan Shapovalov intelfx...@gmail.com
Date: Sat, 25 Apr 2015 04:57:59 +0300
Subject: [PATCH] core: coldplug all units which participate in jobs

This is yet another attempt to fix coldplugging order (more especially,
the problem which happens when one creates a job during coldplugging, and
it references a not-yet-coldplugged unit).

Now we forcibly coldplug all units which participate in jobs. This
is a superset of previously implemented handling of the UNIT_TRIGGERS
dependencies, so that handling is removed.
---
 src/core/transaction.c | 6 ++
 src/core/unit.c| 8 
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/src/core/transaction.c b/src/core/transaction.c
index 5974b1e..a02c02c 100644
--- a/src/core/transaction.c
+++ b/src/core/transaction.c
@@ -848,6 +848,12 @@ int transaction_add_job_and_dependencies(
 assert(type  _JOB_TYPE_MAX_IN_TRANSACTION);
 assert(unit);
 
+/* Before adding jobs for this unit, let's ensure that its state has 
been loaded.
+ * This matters when jobs are spawned as part of coldplugging itself 
(see. e. g. path_coldplug().
+ * This way, we recursively coldplug units, ensuring that we do not 
look at state of
+ * not-yet-coldplugged units. */
+unit_coldplug(unit);
+
 /* log_debug(Pulling in %s/%s from %s/%s, */
 /*   unit-id, job_type_to_string(type), */
 /*   by ? by-unit-id : NA, */
diff --git a/src/core/unit.c b/src/core/unit.c
index 2b356e2..996b648 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -2889,14 +2889,6 @@ int unit_coldplug(Unit *u) {
 
 u-coldplugged = true;
 
-/* Make sure everything that we might pull in through
- * triggering is coldplugged before us */
-SET_FOREACH(other, u-dependencies[UNIT_TRIGGERS], i) {
-r = unit_coldplug(other);
-if (r  0)
-return r;
-}
-
 if (UNIT_VTABLE(u)-coldplug) {
 r = UNIT_VTABLE(u)-coldplug(u);
 if (r  0)
-- 
2.3.6

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-04-24 Thread Ivan Shapovalov
-16L6G swap0.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Found device 
WDC_WD10JPVX-08JC3T5 datastore0.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Found device 
WDC_WD10JPVX-08JC3T5 linux-build.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started File System Check 
on /dev/disk/by-label/linux-build.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Rebuild Journal 
Catalog.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Set Up Additional 
Binary Formats.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Rebuild Hardware 
Database.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target Paths.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Setup Virtual 
Console.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Create Static 
Device Nodes in /dev.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Rebuild Dynamic 
Linker Cache.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target Basic System.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Create Volatile 
Files and Directories.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Create System Users.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target Swap.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target System Time 
Synchronized.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started udev Coldplug all 
Devices.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Update UTMP about 
System Boot/Shutdown.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target Slices.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target System 
Initialization.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target Local File 
Systems (Pre).
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target Local File 
Systems.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Create list of 
required static device nodes for the current kernel.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Update is Completed.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target Encrypted 
Volumes.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Flush Journal to 
Persistent Storage.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Remount Root and 
Kernel File Systems.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Load/Save Random 
Seed.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Apply Kernel 
Variables.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target Timers.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Load Kernel Modules.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Reached target Sockets.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started File System Check 
on /dev/disk/by-label/datastore0.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Network Time 
Synchronization.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Mounted Virtual Machine and 
Container Storage.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Commit a transient 
machine-id on disk.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started First Boot Wizard.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Listening on Journal Audit 
Socket.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Manage Sound Card 
State (restore and store).
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Starting Restore Sound Card 
State...
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started File System Check 
on Root Device.
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started CUPS Scheduler.
2015-04-24T19:42:05+0300 intelfx-laptop sudo[15870]: pam_unix(sudo:session): 
session closed for user root
2015-04-24T19:42:05+0300 intelfx-laptop systemd[1]: Started Restore Sound Card 
State.
2015-04-24T19:42:05+0300 intelfx-laptop polkitd[8629]: Unregistered 
Authentication Agent for unix-process:15871:1490725 (system bus name :1.239, 
object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale ru_RU.utf8) 
(disconnected from bus)
 cut log here 

To reproduce, it takes three things:
- the order alteration patch (without it, bug may also happen, but it will be
  nondeterministic wrt different sets of units);
- any *.path unit which active at the moment of reloading
  (in my case, it is org.cups.cupsd.path);
- any Type=oneshot / RemainAfterExit=false / WantedBy=basic.target unit
  (in my case, it is alsa-restore.service), though without it you'll still
  get the above messages due to basic.target being re-started.

I'll try to look into code and see why your method fails...

-- 
Ivan Shapovalov / intelfx /

-- 
Ivan Shapovalov / intelfx /

-- 
Ivan Shapovalov / intelfx /
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd

Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-04-24 Thread Ivan Shapovalov
On 2015-04-24 at 20:19 +0200, Lennart Poettering wrote:
 On Fri, 24.04.15 20:46, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  On 2015-04-24 at 19:13 +0200, Lennart Poettering wrote:
   On Fri, 24.04.15 20:06, Ivan Shapovalov (intelfx...@gmail.com) 
   wrote:
   
With this patch applied, on `systemctl daemon-reload` I get the
following:
   
   Any chance you can do the same with debugging on? systemd
   -analyze
   set-log-level debug right before the daemon-reload?
   
   That should show the transaction being queued in.
  
  Sure, I've ran it (log attached), but well... it did not show
  any new jobs being enqueued. But alsa-restore.service _did_ run and
  did reset my ALSA volume to the bootup value.
  
  Pretty confused,
 
 Note that starting services is recursive: if a service is enqueued,
 then we add all its dependencies to the transaction, verify that the
 transaction is without cycles and can be applied, and then actually
 apply it.
 
 This means, that starting a service foo.service, that requires
 bar.target, that requires waldo.service, will mean that waldo.service
 is also started, even if bar.target is already started anyway.

Judging by current master, this is not the case. I've created a pair
of throw-away services and a target in the described configuration,
and dependencies of an already started target are not started again. I
think the status quo is correct because activating an already
activated target is a no-op.

Anyway, this is orthogonal. The issue at hand is that the core looks
at the state of not-yet-coldplugged units...

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/3] sysusers: allow separate alternate roots for configs and modifications

2015-04-23 Thread Ivan Shapovalov
On 2015-04-23 at 14:11 +0200, Lennart Poettering wrote:
 On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  This is useful, for example, to create system accounts on an 
  initramfs
  using the host's configuration.
 
 Hmm, but you can already do this, by specifiying the config files on
 the command line, no?

Actually, this means duplicating the logic of determining of the
directory list (/usr/lib vs /lib, ...).

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/3] sysusers: allow separate alternate roots for configs and modifications

2015-04-23 Thread Ivan Shapovalov
On 2015-04-23 at 16:48 +0200, Lennart Poettering wrote:
 On Thu, 23.04.15 17:46, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  On 2015-04-23 at 14:11 +0200, Lennart Poettering wrote:
   On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com) 
   wrote:
   
This is useful, for example, to create system accounts on an 
initramfs
using the host's configuration.
   
   Hmm, but you can already do this, by specifiying the config 
   files on
   the command line, no?
  
  Actually, this means duplicating the logic of determining of the
  directory list (/usr/lib vs /lib, ...).
 
 True, but it's not *that* complex in that case...

Not really, because it is then also needed to do priority-overriding
of the configuration snippets by hand. I would really like to avoid re
-implementing this logic.

There is an alternative to bind-mount all configuration directories
into the destination root, but it's not atomic against killing of
the process (if we get killed in between, stale bind mounts will
remain). So I won't like to do this either. I'm sure that mkinitcpio
maintainer in arch will not accept this solution as well.

Any other options?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/3] sysusers: allow separate alternate roots for configs and modifications

2015-04-23 Thread Ivan Shapovalov
On 2015-04-23 at 17:15 +0200, Lennart Poettering wrote:
 On Thu, 23.04.15 18:09, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  On 2015-04-23 at 16:48 +0200, Lennart Poettering wrote:
   On Thu, 23.04.15 17:46, Ivan Shapovalov (intelfx...@gmail.com) 
   wrote:
   
On 2015-04-23 at 14:11 +0200, Lennart Poettering wrote:
 On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com
 ) 
 wrote:
 
  This is useful, for example, to create system accounts on 
  an 
  initramfs
  using the host's configuration.
 
 Hmm, but you can already do this, by specifiying the config 
 files on
 the command line, no?

Actually, this means duplicating the logic of determining of 
the
directory list (/usr/lib vs /lib, ...).
   
   True, but it's not *that* complex in that case...
  
  Not really, because it is then also needed to do priority
  -overriding
  of the configuration snippets by hand. I would really like to 
  avoid re
  -implementing this logic.
  
  There is an alternative to bind-mount all configuration directories
  into the destination root, but it's not atomic against killing of
  the process (if we get killed in between, stale bind mounts will
  remain). So I won't like to do this either. I'm sure that 
  mkinitcpio
  maintainer in arch will not accept this solution as well.
  
  Any other options?
 
 Hmm, I don't really see the use for this I must say. That said, I
 figure I would accept a patch that adds a new switch
 --configuration-root= or so, similar to your original patch, but
 leaves --root= as it is right now, and really only adds a new
 --configuration-root= that if specified overrides the root directory
 otherwise specified for the reading of the configuration files. 
 
 If you add this tmpfiles should probably get something similar, to
 make this match up nicely...

Actually, thinking about this once more, I've realized that my usecase
is broken. I wanted to use systemd-sysusers to generate new
passwd/group for the initcpio, but never realized that newly created
UIDs and GIDs can mismatch the host ones (and we are copying files
from the host).

So, disregard this patch, there is indeed no usecase so far.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

2015-04-23 Thread Ivan Shapovalov
On 2015-04-08 at 19:28 +0200, Lennart Poettering wrote:
 On Mon, 23.03.15 16:04, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  Hello,
  
  is it possible/allowed/desired to support assigning ExecStartPre= 
  and
  similar options via dbus interface, i. e. in `systemctl set
  -property` or
  `systemd-run -p`?
 
 So far our philosophy for allowing dynamically changable properties 
 is
 that we do this only for properties we can actually really alter
 dynamically at runtime. For example, properties that map to cgroup
 attributes are of this kind, as we can pass them to the kernel
 immediately so that they take effect. However, other properties, like
 for example the nice level are not of this kind, since we can
 reasonably set them only while forking off processes, and afterwards
 it is not clear what to set them on (just the main process? all
 processes? and what to do if the service altered its own nice level,
 and applied different levels to different procecesses, what do we do
 then?).
 
 ExecStartPre= is a property we cannot really adjust dynamically, 
 after
 all it specifies what to execute, and that's only relevant during
 service startup?
 
  I'm hitting a usecase when I need to run a service with multiple
  executed processes via `systemd-run`. I think this makes sense to
  support, isn't it?
 
 Can you elaborate on this? A service with multiple processes?
 In parallel? Normally we recommend a 1:1 mapping between services and
 forked off processes, i.e. never fork off multiple processes for the
 same service (unless the service does that internally...). The only
 exception to this logic is for Type=oneshot services, where we allow
 multiple processes, but only serialized, not parallel.
 
 Anyway, I don't really grok what you want to to...

OK, in avoidance of an X-Y problem, I'll describe the initial task. I
would like to run a vnc connection tunneled over ssh. This requires
running two binaries: an ssh client in TCP port forwarding mode and a
vnc client. They are started one after another. The second one is
terminated at user's choice, the first one has no knowledge of vnc
session ended and hence should be manually terminated.

This could be solved with templated units, but there is more than one
parameter to pass (both to ssh and vnc clients). So, I need to
generate units on the fly. There are three possibilities:

- generate two units manually and somehow mark them as transient
  so that they will be removed after stop
- do `systemd-run` twice and somehow set up the dependencies between
  two transient units
- do `systemd-run` once, starting ssh client in ExecStartPre= and vnc
  client in ExecStart=

Neither of these is possible at the moment. How can this be achieved?

Thanks,
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

2015-03-24 Thread Ivan Shapovalov
On 2015-03-23 at 13:45 +, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Mar 23, 2015 at 04:04:28PM +0300, Ivan Shapovalov wrote:
  Hello,
  
  is it possible/allowed/desired to support assigning ExecStartPre= and
  similar options via dbus interface, i. e. in `systemctl set-property` or
  `systemd-run -p`?
  
  I'm hitting a usecase when I need to run a service with multiple
  executed processes via `systemd-run`. I think this makes sense to
  support, isn't it?
 Sounds like creating a transient unit would be better.

So, actually, I've ended up dynamically creating two dependent units
(because ExecStartPre= processes are not allowed to go into background),
but the question is still there -- how to make a unit automatically go
away after exiting? IOW, how to make a unit transient?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

2015-03-23 Thread Ivan Shapovalov
Hello,

is it possible/allowed/desired to support assigning ExecStartPre= and
similar options via dbus interface, i. e. in `systemctl set-property` or
`systemd-run -p`?

I'm hitting a usecase when I need to run a service with multiple
executed processes via `systemd-run`. I think this makes sense to
support, isn't it?

Cheers,
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

2015-03-23 Thread Ivan Shapovalov
On 2015-03-23 at 13:45 +, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Mar 23, 2015 at 04:04:28PM +0300, Ivan Shapovalov wrote:
  Hello,
  
  is it possible/allowed/desired to support assigning ExecStartPre= and
  similar options via dbus interface, i. e. in `systemctl set-property` or
  `systemd-run -p`?
  
  I'm hitting a usecase when I need to run a service with multiple
  executed processes via `systemd-run`. I think this makes sense to
  support, isn't it?
 Sounds like creating a transient unit would be better.

That is, ..?
How can I create a unit that will be removed as soon as it's stopped?

There is only StartTransientUnit() on the bus, which is exactly what
`systemd-run` does, and so isn't suitable...

Cheers,
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCHv2] sysusers: do not reject users with already present /etc/shadow entries

2015-03-07 Thread Ivan Shapovalov
This is needed to interoperate firstboot and sysusers. The former one is started
first, and it writes only /etc/shadow when it is told to set the root password.
It's better to relax checks here than to duplicate functionality in firstboot.
---

v2: rebased on top of master

 src/sysusers/sysusers.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 0b5668a..9c59792 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -603,6 +603,8 @@ static int write_files(void) {
 if (r  0)
 goto finish;
 
+lstchg = (long) (now(CLOCK_REALTIME) / USEC_PER_DAY);
+
 original = fopen(shadow_path, re);
 if (original) {
 struct spwd *sp;
@@ -616,8 +618,13 @@ static int write_files(void) {
 
 i = hashmap_get(users, sp-sp_namp);
 if (i  i-todo_user) {
-r = -EEXIST;
-goto finish;
+/* we will update the existing entry */
+sp-sp_lstchg = lstchg;
+
+/* only the /etc/shadow stage is left, 
so we can
+ * safely remove the item from the 
todo set */
+i-todo_user = false;
+hashmap_remove(todo_uids, 
UID_TO_PTR(i-uid));
 }
 
 errno = 0;
@@ -640,7 +647,6 @@ static int write_files(void) {
 goto finish;
 }
 
-lstchg = (long) (now(CLOCK_REALTIME) / USEC_PER_DAY);
 HASHMAP_FOREACH(i, todo_uids, iterator) {
 struct spwd n = {
 .sp_namp = i-name,
@@ -877,7 +883,6 @@ static int add_user(Item *i) {
 
 if (!arg_root) {
 struct passwd *p;
-struct spwd *sp;
 
 /* Also check NSS */
 errno = 0;
@@ -893,16 +898,6 @@ static int add_user(Item *i) {
 }
 if (!IN_SET(errno, 0, ENOENT))
 return log_error_errno(errno, Failed to check if user 
%s already exists: %m, i-name);
-
-/* And shadow too, just to be sure */
-errno = 0;
-sp = getspnam(i-name);
-if (sp) {
-log_error(User %s already exists in shadow database, 
but not in user database., i-name);
-return -EBADMSG;
-}
-if (!IN_SET(errno, 0, ENOENT))
-return log_error_errno(errno, Failed to check if user 
%s already exists in shadow database: %m, i-name);
 }
 
 /* Try to use the suggested numeric uid */
-- 
2.3.1

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


Re: [systemd-devel] [PATCH 0/3] using firstboot and sysusers to construct an initramfs

2015-03-07 Thread Ivan Shapovalov
On 2015-03-07 at 15:01 +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Mar 05, 2015 at 09:42:17PM +0300, Ivan Shapovalov wrote:
  On 2015-03-05 at 19:16 +0100, Zbigniew Jędrzejewski-Szmek wrote:
   On Thu, Mar 05, 2015 at 09:09:54PM +0300, Ivan Shapovalov wrote:
On 2015-02-26 at 02:53 +0300, Ivan Shapovalov wrote:
 On 2015-02-26 at 02:46 +0300, Ivan Shapovalov wrote:
  Hi there.
  
  These patches allow using firstboot and sysusers together to 
  construct an
  initramfs with a fully functional emergency.service and 
  rescue.service.
  
  Moreover, they allow to build a clean passwd for the initramfs 
  and don't
  resort to copying it from the host system (as it has been done in 
  Arch's
  mkinitcpio).
  
  The first one allows sysusers to take configuration from the real 
  root
  but to apply it to a specified alternate root.
  
  The next two patches fix an apparent integration problem between 
  firstboot
  and sysusers, as previously described here:
  http://lists.freedesktop.org/archives/systemd-devel/2015-February/028355.html
  
  All in all, with this series I'm able to do a simple
  
  systemd-firstboot --root=$BUILDROOT --root-password=
  systemd-sysusers --dest-root=$BUILDROOT
  
  and, after adding respective units and /sbin/sulogin to the 
  initramfs,
  to use rd.systemd.unit=rescue.target as a complete alternative to 
  pre-systemd
  arch-specific break=premount kernel parameter.
 
  [...]
 
 Forgot to add Dave Reisner to Cc:.
 
 Dave, what do you think about all this? If this is a bad idea, then 
 I'm
 open for suggestions.
 I just miss these break=... from the pre-systemd era.
 

Anyone?
   2/3 and 3/3 look fine. For 1/3 I was wondering if it wouldn't be simpler
   to simply copy the sysuser files into the tree. The semantics are then
   clear. But right now, if there are sysuser files in the source root, and
   in the destination root, it becomes unclear how to sort and merge them.
  
  Well, the intended semantics are pretty clear as well: simply ignore
  configs everywhere except the --config-root. (Just like we ignore
  configs in / when --root is given, for example.)
 Right, the semantics are clear as far as the patch goes and they fit your
 use case. But I think they would be less intuitive to users in general. 
 The main idea of sysusers (and tmpfiles) is that after wiping /etc the
 can be restored to factory defaults. If the configuration is created
 using external files in --config-root, this property is lost.
 
 Even if you don't intend / don't support wiping /etc, I still see value
 in seeing that certain parts of the configuration came from sysusers.
 
  Yes, copying/symlinking sysusers.d directories or individual files into
  the initramfs build root is less intrusive from the code perspective.
  But what if people add their own sysusers.d (people tend to have crazy
  setups...)? That'll need to be worked around.
 I don't understand. If they do something crazy in the root they are building,
 that's ok.

I mean that the code which will do the building will have to work around
if sysusers.d directories already exist due to some user-imposed
craziness. But well, this is a minor issue. If you are sure that this
functionality has no place in sysusers - let it be so.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-03-05 Thread Ivan Shapovalov
On 2015-02-28 at 00:50 +0300, Ivan Shapovalov wrote:
 On 2015-02-27 at 22:25 +0100, Zbigniew Jędrzejewski-Szmek wrote:
  On Wed, Feb 25, 2015 at 09:40:23PM +0300, Ivan Shapovalov wrote:
   Because the order of coldplugging is not defined, we can reference a
   not-yet-coldplugged unit and read its state while it has not yet been
   set to a meaningful value.
   
   This way, already active units may get started again.
   
   We fix this by deferring such actions until all units have been at least
   somehow coldplugged.
   
   Fixes https://bugs.freedesktop.org/show_bug.cgi?id=88401
   ---
   
   v2: set waiting state on path/timer units after deferring the actual 
   coldplug,
   so that we won't run into the exactly same problem during processing 
   the
   deferred entries.
  This looks good. I seems to be the correct thing to do independently of the
  idea to split device states into three with the new pending state.
  Let's see what Lennart thinks though.
 
 Hmm.. This does not relate to the ongoing discussion about adding a
 third state for .device units. This is about coldplugging .path
 and .timer units during reloads.
 

Ping? I don't want to miss v220 as well :)

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 0/3] using firstboot and sysusers to construct an initramfs

2015-03-05 Thread Ivan Shapovalov
On 2015-02-26 at 02:53 +0300, Ivan Shapovalov wrote:
 On 2015-02-26 at 02:46 +0300, Ivan Shapovalov wrote:
  Hi there.
  
  These patches allow using firstboot and sysusers together to construct an
  initramfs with a fully functional emergency.service and rescue.service.
  
  Moreover, they allow to build a clean passwd for the initramfs and don't
  resort to copying it from the host system (as it has been done in Arch's
  mkinitcpio).
  
  The first one allows sysusers to take configuration from the real root
  but to apply it to a specified alternate root.
  
  The next two patches fix an apparent integration problem between firstboot
  and sysusers, as previously described here:
  http://lists.freedesktop.org/archives/systemd-devel/2015-February/028355.html
  
  All in all, with this series I'm able to do a simple
  
  systemd-firstboot --root=$BUILDROOT --root-password=
  systemd-sysusers --dest-root=$BUILDROOT
  
  and, after adding respective units and /sbin/sulogin to the initramfs,
  to use rd.systemd.unit=rescue.target as a complete alternative to 
  pre-systemd
  arch-specific break=premount kernel parameter.
 
  [...]
 
 Forgot to add Dave Reisner to Cc:.
 
 Dave, what do you think about all this? If this is a bad idea, then I'm
 open for suggestions.
 I just miss these break=... from the pre-systemd era.
 

Anyone?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 0/3] using firstboot and sysusers to construct an initramfs

2015-03-05 Thread Ivan Shapovalov
On 2015-03-05 at 19:16 +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Mar 05, 2015 at 09:09:54PM +0300, Ivan Shapovalov wrote:
  On 2015-02-26 at 02:53 +0300, Ivan Shapovalov wrote:
   On 2015-02-26 at 02:46 +0300, Ivan Shapovalov wrote:
Hi there.

These patches allow using firstboot and sysusers together to construct 
an
initramfs with a fully functional emergency.service and rescue.service.

Moreover, they allow to build a clean passwd for the initramfs and 
don't
resort to copying it from the host system (as it has been done in Arch's
mkinitcpio).

The first one allows sysusers to take configuration from the real root
but to apply it to a specified alternate root.

The next two patches fix an apparent integration problem between 
firstboot
and sysusers, as previously described here:
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028355.html

All in all, with this series I'm able to do a simple

systemd-firstboot --root=$BUILDROOT --root-password=
systemd-sysusers --dest-root=$BUILDROOT

and, after adding respective units and /sbin/sulogin to the initramfs,
to use rd.systemd.unit=rescue.target as a complete alternative to 
pre-systemd
arch-specific break=premount kernel parameter.
   
[...]
   
   Forgot to add Dave Reisner to Cc:.
   
   Dave, what do you think about all this? If this is a bad idea, then I'm
   open for suggestions.
   I just miss these break=... from the pre-systemd era.
   
  
  Anyone?
 2/3 and 3/3 look fine. For 1/3 I was wondering if it wouldn't be simpler
 to simply copy the sysuser files into the tree. The semantics are then
 clear. But right now, if there are sysuser files in the source root, and
 in the destination root, it becomes unclear how to sort and merge them.

Well, the intended semantics are pretty clear as well: simply ignore
configs everywhere except the --config-root. (Just like we ignore
configs in / when --root is given, for example.)

Yes, copying/symlinking sysusers.d directories or individual files into
the initramfs build root is less intrusive from the code perspective.
But what if people add their own sysusers.d (people tend to have crazy
setups...)? That'll need to be worked around.

OTOH, the proposed changes are quite simple, and if needed, people with
strange setups could just rm the generated files.

However, no strong preference.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] journal: fix Inappropriate ioctl for device on ext4

2015-03-01 Thread Ivan Shapovalov
On 2015-03-01 at 21:13 -0300, Cristian Rodríguez wrote:
 Logs constantly show
 
 systemd-journald[395]: Failed to set file attributes: Inappropriate
 ioctl for device
 
 This is because ext4 does not support FS_NOCOW_FL.
 ---
  src/journal/journal-file.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
 index 9c9a548..ecabfd3 100644
 --- a/src/journal/journal-file.c
 +++ b/src/journal/journal-file.c
 @@ -2610,7 +2610,8 @@ int journal_file_open(
   * checksumming). */
  r = chattr_fd(f-fd, true, FS_NOCOW_FL);
  if (r  0)
 -log_warning_errno(errno, Failed to set file 
 attributes: %m);
 +if(r != -ENOTTY)

Maybe it's better to just say if (r  0  r != -ENOTTY) here?

Just nitpicking,
-- 
Ivan Shapovalov / intelfx /

 +log_warning_errno(errno, Failed to set file 
 attributes: %m);
  
  /* Let's attach the creation time to the journal file,
   * so that the vacuuming code knows the age of this



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv2] core: do not spawn jobs or touch other units during coldplugging

2015-02-27 Thread Ivan Shapovalov
On 2015-02-27 at 22:25 +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Wed, Feb 25, 2015 at 09:40:23PM +0300, Ivan Shapovalov wrote:
  Because the order of coldplugging is not defined, we can reference a
  not-yet-coldplugged unit and read its state while it has not yet been
  set to a meaningful value.
  
  This way, already active units may get started again.
  
  We fix this by deferring such actions until all units have been at least
  somehow coldplugged.
  
  Fixes https://bugs.freedesktop.org/show_bug.cgi?id=88401
  ---
  
  v2: set waiting state on path/timer units after deferring the actual 
  coldplug,
  so that we won't run into the exactly same problem during processing the
  deferred entries.
 This looks good. I seems to be the correct thing to do independently of the
 idea to split device states into three with the new pending state.
 Let's see what Lennart thinks though.

Hmm.. This does not relate to the ongoing discussion about adding a
third state for .device units. This is about coldplugging .path
and .timer units during reloads.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] user-sessions: move into own subdir and build independently of logind

2015-02-25 Thread Ivan Shapovalov
Suggested by Zbyszek on IRC.

---

This does not conditionalize on HAVE_PAM. Don't know whether that's right.

 Makefile.am   | 37 
 man/systemd-user-sessions.service.xml |  2 +-
 src/login/Makefile|  1 -
 src/login/user-sessions.c | 80 ---
 src/user-sessions/Makefile|  1 +
 src/user-sessions/user-sessions.c | 80 +++
 6 files changed, 101 insertions(+), 100 deletions(-)
 delete mode 12 src/login/Makefile
 delete mode 100644 src/login/user-sessions.c
 create mode 12 src/user-sessions/Makefile
 create mode 100644 src/user-sessions/user-sessions.c

diff --git a/Makefile.am b/Makefile.am
index 93c0509..0378478 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -393,7 +393,8 @@ rootlibexec_PROGRAMS = \
systemd-sleep \
systemd-bus-proxyd \
systemd-socket-proxyd \
-   systemd-update-done
+   systemd-update-done \
+   systemd-user-sessions
 
 if HAVE_UTMP
 rootlibexec_PROGRAMS += \
@@ -554,7 +555,8 @@ nodist_systemunit_DATA = \
units/initrd-udevadm-cleanup-db.service \
units/initrd-switch-root.service \
units/systemd-nspawn@.service \
-   units/systemd-update-done.service
+   units/systemd-update-done.service \
+   units/systemd-user-sessions.service
 
 if HAVE_UTMP
 nodist_systemunit_DATA += \
@@ -607,7 +609,8 @@ EXTRA_DIST += \
units/initrd-udevadm-cleanup-db.service.in \
units/initrd-switch-root.service.in \
units/systemd-nsp...@.service.in \
-   units/systemd-update-done.service.in
+   units/systemd-update-done.service.in \
+   units/systemd-user-sessions.service.in
 
 CLEANFILES += \
units/console-shell.service.m4 \
@@ -2123,6 +2126,13 @@ systemd_update_done_LDADD = \
libsystemd-shared.la
 
 # 
--
+systemd_user_sessions_SOURCES = \
+   src/user-sessions/user-sessions.c
+
+systemd_user_sessions_LDADD = \
+   libsystemd-shared.la
+
+# 
--
 systemd_shutdownd_SOURCES = \
src/shutdownd/shutdownd.c
 
@@ -5903,15 +5913,8 @@ endif
 noinst_LTLIBRARIES += \
libsystemd-logind-core.la
 
-systemd_user_sessions_SOURCES = \
-   src/login/user-sessions.c
-
-systemd_user_sessions_LDADD = \
-   libsystemd-shared.la
-
 rootlibexec_PROGRAMS += \
-   systemd-logind \
-   systemd-user-sessions
+   systemd-logind
 
 loginctl_SOURCES = \
src/login/loginctl.c \
@@ -6011,8 +6014,7 @@ dist_pamconf_DATA = \
 endif
 
 nodist_systemunit_DATA += \
-   units/systemd-logind.service \
-   units/systemd-user-sessions.service
+   units/systemd-logind.service
 
 dist_systemunit_DATA += \
units/user.slice
@@ -6036,8 +6038,7 @@ INSTALL_DIRS += \
$(systemdstatedir)
 
 MULTI_USER_TARGET_WANTS += \
-   systemd-logind.service \
-   systemd-user-sessions.service
+   systemd-logind.service
 
 SYSTEM_UNIT_ALIASES += \
systemd-logind.service dbus-org.freedesktop.login1.service
@@ -6066,8 +6067,7 @@ EXTRA_DIST += \
src/login/logind-gperf.gperf \
src/login/71-seat.rules.in \
src/login/73-seat-late.rules.in \
-   units/systemd-logind.service.in \
-   units/systemd-user-sessions.service.in
+   units/systemd-logind.service.in
 
 # 
--
 if HAVE_PYTHON_DEVEL
@@ -6592,7 +6592,8 @@ LOCAL_FS_TARGET_WANTS += \
 
 MULTI_USER_TARGET_WANTS += \
getty.target \
-   systemd-ask-password-wall.path
+   systemd-ask-password-wall.path \
+   systemd-user-sessions.service
 
 SYSINIT_TARGET_WANTS += \
dev-hugepages.mount \
diff --git a/man/systemd-user-sessions.service.xml 
b/man/systemd-user-sessions.service.xml
index 9d796b1..9a228df 100644
--- a/man/systemd-user-sessions.service.xml
+++ b/man/systemd-user-sessions.service.xml
@@ -19,7 +19,7 @@
   You should have received a copy of the GNU Lesser General Public License
   along with systemd; If not, see http://www.gnu.org/licenses/.
 --
-refentry id=systemd-user-sessions.service conditional='HAVE_PAM'
+refentry id=systemd-user-sessions.service
 
   refentryinfo
 titlesystemd-user-sessions.service/title
diff --git a/src/login/Makefile b/src/login/Makefile
deleted file mode 12
index d0b0e8e..000
--- a/src/login/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-../Makefile
\ No newline at end of file
diff --git a/src/login/user-sessions.c b/src/login/user-sessions.c
deleted file mode 100644
index 1c31769..000
--- a/src/login/user-sessions.c
+++ /dev/null
@@ -1,80 +0,0 @@
-/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
-
-/***
-  This file is part of systemd.
-
-  Copyright 2010 Lennart Poettering
-
-  systemd is free software; you can redistribute it 

[systemd-devel] [PATCH 1/3] sysusers: allow separate alternate roots for configs and modifications

2015-02-25 Thread Ivan Shapovalov
This is useful, for example, to create system accounts on an initramfs
using the host's configuration.
---
 src/sysusers/sysusers.c | 97 +
 1 file changed, 66 insertions(+), 31 deletions(-)

diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 0b5668a..9d39bd4 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -64,7 +64,7 @@ typedef struct Item {
 bool todo_group:1;
 } Item;
 
-static char *arg_root = NULL;
+static char *arg_root_config = NULL, *arg_root_dest = NULL;
 
 static const char conf_file_dirs[] = CONF_DIRS_NULSTR(sysusers);
 
@@ -79,7 +79,7 @@ static uid_t search_uid = UID_INVALID;
 static UidRange *uid_range = NULL;
 static unsigned n_uid_range = 0;
 
-#define fix_root(x) (arg_root ? strjoina(arg_root, x) : x)
+#define fix_root_dest(x) (arg_root_dest ? strjoina(arg_root_dest, x) : x)
 
 static int load_user_database(void) {
 _cleanup_fclose_ FILE *f = NULL;
@@ -87,7 +87,7 @@ static int load_user_database(void) {
 struct passwd *pw;
 int r;
 
-passwd_path = fix_root(/etc/passwd);
+passwd_path = fix_root_dest(/etc/passwd);
 f = fopen(passwd_path, re);
 if (!f)
 return errno == ENOENT ? 0 : -errno;
@@ -139,7 +139,7 @@ static int load_group_database(void) {
 struct group *gr;
 int r;
 
-group_path = fix_root(/etc/group);
+group_path = fix_root_dest(/etc/group);
 f = fopen(group_path, re);
 if (!f)
 return errno == ENOENT ? 0 : -errno;
@@ -368,7 +368,7 @@ static int write_files(void) {
 _cleanup_fclose_ FILE *original = NULL;
 
 /* First we update the actual group list file */
-group_path = fix_root(/etc/group);
+group_path = fix_root_dest(/etc/group);
 r = fopen_temporary_label(/etc/group, group_path, group, 
group_tmp);
 if (r  0)
 goto finish;
@@ -447,7 +447,7 @@ static int write_files(void) {
 }
 
 /* OK, now also update the shadow file for the group list */
-gshadow_path = fix_root(/etc/gshadow);
+gshadow_path = fix_root_dest(/etc/gshadow);
 r = fopen_temporary_label(/etc/gshadow, gshadow_path, 
gshadow, gshadow_tmp);
 if (r  0)
 goto finish;
@@ -513,7 +513,7 @@ static int write_files(void) {
 long lstchg;
 
 /* First we update the user database itself */
-passwd_path = fix_root(/etc/passwd);
+passwd_path = fix_root_dest(/etc/passwd);
 r = fopen_temporary_label(/etc/passwd, passwd_path, passwd, 
passwd_tmp);
 if (r  0)
 goto finish;
@@ -598,7 +598,7 @@ static int write_files(void) {
 }
 
 /* The we update the shadow database */
-shadow_path = fix_root(/etc/shadow);
+shadow_path = fix_root_dest(/etc/shadow);
 r = fopen_temporary_label(/etc/shadow, shadow_path, shadow, 
shadow_tmp);
 if (r  0)
 goto finish;
@@ -772,7 +772,7 @@ static int uid_is_ok(uid_t uid, const char *name) {
 return 0;
 
 /* Let's also check via NSS, to avoid UID clashes over LDAP and such, 
just in case */
-if (!arg_root) {
+if (!arg_root_dest) {
 errno = 0;
 p = getpwuid(uid);
 if (p)
@@ -792,10 +792,10 @@ static int uid_is_ok(uid_t uid, const char *name) {
 return 1;
 }
 
-static int root_stat(const char *p, struct stat *st) {
+static int root_dest_stat(const char *p, struct stat *st) {
 const char *fix;
 
-fix = fix_root(p);
+fix = fix_root_dest(p);
 if (stat(fix, st)  0)
 return -errno;
 
@@ -811,7 +811,7 @@ static int read_id_from_file(Item *i, uid_t *_uid, gid_t 
*_gid) {
 assert(i);
 
 /* First, try to get the gid directly */
-if (_gid  i-gid_path  root_stat(i-gid_path, st) = 0) {
+if (_gid  i-gid_path  root_dest_stat(i-gid_path, st) = 0) {
 gid = st.st_gid;
 found_gid = true;
 }
@@ -819,7 +819,7 @@ static int read_id_from_file(Item *i, uid_t *_uid, gid_t 
*_gid) {
 /* Then, try to get the uid directly */
 if ((_uid || (_gid  !found_gid))
  i-uid_path
- root_stat(i-uid_path, st) = 0) {
+ root_dest_stat(i-uid_path, st) = 0) {
 
 uid = st.st_uid;
 found_uid = true;
@@ -837,7 +837,7 @@ static int read_id_from_file(Item *i, uid_t *_uid, gid_t 
*_gid) {
 if (found_gid) {
 uid = (uid_t) gid;
 found_uid = true;
-} else if (root_stat(i-gid_path, st) = 0) {
+

[systemd-devel] [PATCH 0/3] using firstboot and sysusers to construct an initramfs

2015-02-25 Thread Ivan Shapovalov
Hi there.

These patches allow using firstboot and sysusers together to construct an
initramfs with a fully functional emergency.service and rescue.service.

Moreover, they allow to build a clean passwd for the initramfs and don't
resort to copying it from the host system (as it has been done in Arch's
mkinitcpio).

The first one allows sysusers to take configuration from the real root
but to apply it to a specified alternate root.

The next two patches fix an apparent integration problem between firstboot
and sysusers, as previously described here:
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028355.html

All in all, with this series I'm able to do a simple

systemd-firstboot --root=$BUILDROOT --root-password=
systemd-sysusers --dest-root=$BUILDROOT

and, after adding respective units and /sbin/sulogin to the initramfs,
to use rd.systemd.unit=rescue.target as a complete alternative to pre-systemd
arch-specific break=premount kernel parameter.

Ivan Shapovalov (3):
  sysusers: allow separate alternate roots for configs and modifications
  firstboot: set all spwd fields to -1 for consistency with sysusers
  sysusers: do not reject users with already present /etc/shadow entries

 src/firstboot/firstboot.c |   6 +--
 src/sysusers/sysusers.c   | 120 +-
 2 files changed, 78 insertions(+), 48 deletions(-)

-- 
2.3.0

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


[systemd-devel] [PATCH 2/3] firstboot: set all spwd fields to -1 for consistency with sysusers

2015-02-25 Thread Ivan Shapovalov
---
 src/firstboot/firstboot.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/firstboot/firstboot.c b/src/firstboot/firstboot.c
index a765d6d..a37ca17 100644
--- a/src/firstboot/firstboot.c
+++ b/src/firstboot/firstboot.c
@@ -525,9 +525,9 @@ static int process_root_password(void) {
 
 struct spwd item = {
 .sp_namp = (char*) root,
-.sp_min = 0,
-.sp_max = 9,
-.sp_warn = 7,
+.sp_min = -1,
+.sp_max = -1,
+.sp_warn = -1,
 .sp_inact = -1,
 .sp_expire = -1,
 .sp_flag = (unsigned long) -1, /* this appears to be what 
everybody does ... */
-- 
2.3.0

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


[systemd-devel] [PATCH 3/3] sysusers: do not reject users with already present /etc/shadow entries

2015-02-25 Thread Ivan Shapovalov
This is needed to interoperate firstboot and sysusers. The former one is started
first, and it writes only /etc/shadow when it is told to set the root password.
It's better to relax checks here than to duplicate functionality in firstboot.
---
 src/sysusers/sysusers.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 9d39bd4..ec3e8ad 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -603,6 +603,8 @@ static int write_files(void) {
 if (r  0)
 goto finish;
 
+lstchg = (long) (now(CLOCK_REALTIME) / USEC_PER_DAY);
+
 original = fopen(shadow_path, re);
 if (original) {
 struct spwd *sp;
@@ -616,8 +618,13 @@ static int write_files(void) {
 
 i = hashmap_get(users, sp-sp_namp);
 if (i  i-todo_user) {
-r = -EEXIST;
-goto finish;
+/* we will update the existing entry */
+sp-sp_lstchg = lstchg;
+
+/* only the /etc/shadow stage is left, 
so we can
+ * safely remove the item from the 
todo set */
+i-todo_user = false;
+hashmap_remove(todo_uids, 
UID_TO_PTR(i-uid));
 }
 
 errno = 0;
@@ -640,7 +647,6 @@ static int write_files(void) {
 goto finish;
 }
 
-lstchg = (long) (now(CLOCK_REALTIME) / USEC_PER_DAY);
 HASHMAP_FOREACH(i, todo_uids, iterator) {
 struct spwd n = {
 .sp_namp = i-name,
@@ -877,7 +883,6 @@ static int add_user(Item *i) {
 
 if (!arg_root_dest) {
 struct passwd *p;
-struct spwd *sp;
 
 /* Also check NSS */
 errno = 0;
@@ -893,16 +898,6 @@ static int add_user(Item *i) {
 }
 if (!IN_SET(errno, 0, ENOENT))
 return log_error_errno(errno, Failed to check if user 
%s already exists: %m, i-name);
-
-/* And shadow too, just to be sure */
-errno = 0;
-sp = getspnam(i-name);
-if (sp) {
-log_error(User %s already exists in shadow database, 
but not in user database., i-name);
-return -EBADMSG;
-}
-if (!IN_SET(errno, 0, ENOENT))
-return log_error_errno(errno, Failed to check if user 
%s already exists in shadow database: %m, i-name);
 }
 
 /* Try to use the suggested numeric uid */
-- 
2.3.0

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


Re: [systemd-devel] Combining systemd-firstboot and systemd-sysusers

2015-02-21 Thread Ivan Shapovalov
On 2015-02-14 at 08:07 +0300, Ivan Shapovalov wrote:
 Hi all,
 
 I'm trying to adapt systemd-{sysusers,firstboot} for creating the system
 users in an initramfs (at generation time).
 (Note: I use systemd-firstboot to set the root password.)
 
 The situation
 -
 So, I'm running firstboot before sysusers (judging from the unit files,
 this seems to be desired order).
 
 systemd-firstboot --root=... --root-password=PASSWORD
 systemd-sysusers --root=...
 
 The problem
 ---
 systemd-firstboot, when ran, writes /etc/shadow only. Then
 systemd-sysusers is ran, but it expects entries to be present
 in both /etc/passwd and /etc/shadow.
 
 An entry which is present only in /etc/shadow but not in /etc/passwd
 produces an EEXIST error at lines 620-623 (if I had run the tools
 without --root argument, a different codepath would've been taken and I
 would've got an EBADMSG error at lines 902-905).
 
 The solutions
 -
 I see three solutions.
 
 - we can make systemd-firstboot write both /etc/passwd and /etc/shadow
   entries
   (but this is duplication of functionality; I don't like this way...)
 
 - we can run systemd-sysusers before systemd-firstboot
   (but systemd-firstboot won't write the password if the entry already
exists)
 
 - make systemd-sysusers correctly handle entries which are only present
   in /etc/shadow
   (how? by preserving the shadow entry? by overwriting it, preserving 
the password? how else?)
 
 The question
 
 Which one to implement?
 
 Thanks for consideration,

Ping? Anything on this?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

2015-02-21 Thread Ivan Shapovalov
On 2015-02-05 at 02:03 +0300, Ivan Shapovalov wrote:
 On 2015-01-28 at 22:29 +0300, Ivan Shapovalov wrote:
  On 2015-01-28 at 20:15 +0100, Lennart Poettering wrote:
   On Sun, 18.01.15 04:21, Ivan Shapovalov (intelfx...@gmail.com) wrote:
   
Hi folks,

I'm trying to fix this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88401

The initial problem (as reported) looks following: performing a reload
(maybe implicitly) re-starts alsa-restore.service if it is enabled.

With a bit of debugging I've apparently found a root cause. Explanation
following.

Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
started.

We enter manager_reload(), units are serialized, reset, re-read,
deserialized and then cold-plugged. (Note that e. g. unit_notify() has
special protection to avoid spawning jobs when a reload is in
progress.)

So, if org.cups.cupsd.path is started, *it is almost first to be
cold-plugged*. The call chain is:

unit_coldplug()
path_coldplug()
path_enter_waiting() // recheck == true
path_check_good() // returns true
path_enter_running()
manager_add_job() // at this point we're fucked up

So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
because a reload should never enqueue any jobs (IIUC). So, the job is
enqueued... remember that almost all units are inactive by now. Thus we
end up re-starting half a system (the whole basic.target) as
dependencies.

Questions:
- is my analysis correct?
- if yes, then how to fix this? Maybe add a similar
  if (UNIT(p)-manager-n_reloading = 0) check to
  path_enter_running() to avoid calling manager_add_job() during
  reloading?
   
   Hmm, how does this relate to the ALSA case? I mean, the alsa units
   don't use .path units, do they?
  
  The .path unit from CUPS is triggered and starts its .service unit
  *while the service unit's state has not yet been coldplugged*.
  Actually, almost nothing is coldplugged at that point. Thus the
  basic.target is effectively re-started with all its dependencies,
  ignoring all existing state (because it is not yet coldplugged). This
  is the actual bug, and it is the root cause of the reported bug.
  
  Reported bug, on the other hand, happens due to
  1) the above-described bug (not related to alsa) takes place;
  2) alsa-restore.service is Type=oneshot, RemainAfterExit=false and
 WantedBy=basic.target.
  
  Hope it makes things clearer...
 
 Ping? Lennart, do you understand what's going on, or should I try to
 describe things more carefully?
 
 // I would like to get this fixed before v219 ;)

Or, at worst, before v220...

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] user units and system units behavior

2015-02-17 Thread Ivan Shapovalov
On 2015-02-16 at 11:14 +, Simon McVittie wrote:
 On 14/02/15 18:26, Ivan Shapovalov wrote:
  Yes, the per-session bus is there, but it is not used at all for
  communication with per-user systemd instance.
 
 I do want this to work, and I'm working on making it happen. It works on 
 my Debian system, with the patched dbus that I recently uploaded to 
 experimental.
 
 When my patches on https://bugs.freedesktop.org/show_bug.cgi?id=61301 
 have been merged, if dbus is compiled with --enable-user-session and you 
 are running systemd, the per-login-session dbus-daemon --session will 
 be replaced by a per-user-session dbus-daemon --session (see earlier 
 thread for explanation of login session vs. user session). At that 
 point, the dbus-daemon --session can be suitable for communicating 
 with `systemd --user`.
 
 (I believe the plan is (still) that kdbus systems will always have an 
 equivalent of this new per-user-session bus, and never a 
 per-login-session bus.)
 
  No, mine /etc/X11/xinitrc.d is Simon's /etc/X11/Xsession.d and similar
  setups. It's apparently a distro-specific path.
 
 Yes. I think /etc/X11/xinitrc.d is what Red Hat and its derivatives use. 
 Xsession.d is used instead in Debian and its derivatives, including 
 Ubuntu. The differences are because, historically, this sort of plumbing 
 was something that every distribution had to invent for itself.
 
  S
 

Thanks for the heads-up and your work, Simon. I'm also looking forward
for the time when all the bits are there. It means that `systemd --user`
will be finally able to launch various pieces of DE, right?

(Maybe with policykit patches to grant needed permissions to processes
under `systemd --user`...)

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] user units and system units behavior

2015-02-14 Thread Ivan Shapovalov
On 2015-02-14 at 00:17 -0800, Alison Chaiken wrote:
 Inside a Fedora 21 Qemu, I made a dead-simple 'gnome-weather.service'
 and experimented with moving it in between system and user directories
 in systemd 215.
 
 Case 0: With /etc/systemd/system/gnome-weather.service,  starts
 normally with 'systemctl start gnome-weather'
 
 Case 1: With /etc/systemd/user/gnome-weather.service, starts normally
 with 'systemctl --user start gnome-weather'
 
 I wanted to try 'busctl monitor' so I compiled systemd 218 and installed it.
 
 [achaiken@fedora21 ~]$ systemctl --version
 systemd 218
 -PAM -AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
 +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS
 +KMOD +IDN
 
 Case 0: works as before, with 'busctl monitor
 org.freedesktop.systemd1' producing many screens of output.
 
 Case 1: 'systemctl --user start gnome-weather'  now fails:
 
 [achaiken@fedora21 ~]$ systemctl start --user gnome-weather
 Failed to start gnome-weather.service: Process
 org.freedesktop.systemd1 exited with status 1
 
 Meanwhile 'busctl --user monitor org.freedesktop.systemd1' shows no output.
 
 Question: What does the error message 'Process
 org.freedesktop.systemd1 exited with status 1' mean?

Hi Alison,

this is a sign of that the systemd user instance (`systemd --user`)
isn't running.

More specifically, the systemd user instance wasn't running, so its bus
name hadn't been taken, so the dbus1 server tried to do the bus
activation, but the dbus1 service file for systemd (not to be confused
with systemd's unit files) contains Exec=/bin/false (as to prevent bus
activation), so that activation had failed.

..or this could be a sign of that `systemctl --user` couldn't connect to
`systemd --user`.

 
 Question: is it correct that the user bus show no traffic in the
 second case?   Or is that a symptom of what's wrong?

This is the current out-of-the-box situation. The problem lies in that
there is currently no single user bus. There is a number of session
busses, launched by a scriptlet in /etc/X11/xinitrc.d for each X11
session separately. Everything in the user's world works through that
bus. But not `systemd --user`: it is per-user, not per-session. It just
appears before any session is created, so it does not know about any
session busses.

The intent here, as I understand it, some time ago was to have a single
user bus under a well-defined address
($XDG_RUNTIME_DIR/dbus/user_bus_socket), which will be managed by the
systemd user instance (by means of dbus.socket+dbus.service, just like
in the system instance). But there is no such bus, so `systemctl --user`
connects to the systemd user instance via their own private bus: cf.
src/libsystemd/sd-bus/bus-util.c:bus_open_transport_systemd() and
src/libsystemd/sd-bus/bus-util.c:bus_open_user_systemd().

That's why you can't see the traffic using `busctl --user`.

And this all is going to change when kdbus becomes finally there.

HTHs,
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Combining systemd-firstboot and systemd-sysusers

2015-02-13 Thread Ivan Shapovalov
Hi all,

I'm trying to adapt systemd-{sysusers,firstboot} for creating the system
users in an initramfs (at generation time).
(Note: I use systemd-firstboot to set the root password.)

The situation
-
So, I'm running firstboot before sysusers (judging from the unit files,
this seems to be desired order).

systemd-firstboot --root=... --root-password=PASSWORD
systemd-sysusers --root=...

The problem
---
systemd-firstboot, when ran, writes /etc/shadow only. Then
systemd-sysusers is ran, but it expects entries to be present
in both /etc/passwd and /etc/shadow.

An entry which is present only in /etc/shadow but not in /etc/passwd
produces an EEXIST error at lines 620-623 (if I had run the tools
without --root argument, a different codepath would've been taken and I
would've got an EBADMSG error at lines 902-905).

The solutions
-
I see three solutions.

- we can make systemd-firstboot write both /etc/passwd and /etc/shadow
  entries
  (but this is duplication of functionality; I don't like this way...)

- we can run systemd-sysusers before systemd-firstboot
  (but systemd-firstboot won't write the password if the entry already
   exists)

- make systemd-sysusers correctly handle entries which are only present
  in /etc/shadow
  (how? by preserving the shadow entry? by overwriting it, preserving 
   the password? how else?)

The question

Which one to implement?

Thanks for consideration,
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

2015-02-13 Thread Ivan Shapovalov
On 2015-01-28 at 20:15 +0100, Lennart Poettering wrote:
 On Sun, 18.01.15 04:21, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  Hi folks,
  
  I'm trying to fix this bug:
  https://bugs.freedesktop.org/show_bug.cgi?id=88401
  
  The initial problem (as reported) looks following: performing a reload
  (maybe implicitly) re-starts alsa-restore.service if it is enabled.
  
  With a bit of debugging I've apparently found a root cause. Explanation
  following.
  
  Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
  started.
  
  We enter manager_reload(), units are serialized, reset, re-read,
  deserialized and then cold-plugged. (Note that e. g. unit_notify() has
  special protection to avoid spawning jobs when a reload is in
  progress.)
  
  So, if org.cups.cupsd.path is started, *it is almost first to be
  cold-plugged*. The call chain is:
  
  unit_coldplug()
  path_coldplug()
  path_enter_waiting() // recheck == true
  path_check_good() // returns true
  path_enter_running()
  manager_add_job() // at this point we're fucked up
  
  So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
  because a reload should never enqueue any jobs (IIUC). So, the job is
  enqueued... remember that almost all units are inactive by now. Thus we
  end up re-starting half a system (the whole basic.target) as
  dependencies.
  
  Questions:
  - is my analysis correct?
  - if yes, then how to fix this? Maybe add a similar
if (UNIT(p)-manager-n_reloading = 0) check to
path_enter_running() to avoid calling manager_add_job() during
reloading?
 
 Hmm, how does this relate to the ALSA case? I mean, the alsa units
 don't use .path units, do they?
 
 So, in general I think .path units should trigger things on reload,
 but only those things that ar bound to level, not those to edge,
 if you follow what I mean. More specifically, I think that cups.path
 should trigger things, since its job is to make sure that cups.service
 is running as long as there's a file in /var/spool/cups/. 
 
 PathExists=/PathExistsGlob=/DirectoryNotEmpty= are all of the level
 kind. As long as the condition they express is true they should ensure
 their service is running.  PathChanged= and PathModified= OTOH are
 edge triggers, and they should only trigger something when a file is
 changed while we look at it, but not during coldplugging.
 
 During a reload, I hence believe it is OK if trigger units trigger new
 jobs.

Then maybe we can just remember (save somewhere) all new jobs as we
coldplug the units, and actually add them only after we've coldplugged
everything? This way, the transaction machinery will observe the
dependencies' state at the time it is already restored, and no extra
jobs will be created.

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCHv2 3/4] systemctl: cat, edit: further polish error messages

2015-02-04 Thread Ivan Shapovalov
---
 src/systemctl/systemctl.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 567b467..384ae02 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4578,7 +4578,7 @@ static int init_home_and_lookup_paths(char **user_home, 
char **user_runtime, Loo
 
 r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
 if (r  0)
-return log_error_errno(r, Failed to lookup unit lookup paths: 
%m);
+return log_error_errno(r, Failed to query unit lookup paths: 
%m);
 
 return 0;
 }
@@ -5725,11 +5725,11 @@ static int create_edit_temp_file(const char *new_path, 
const char *original_path
 
 r = tempfn_random(new_path, t);
 if (r  0)
-return log_error_errno(r, Failed to determine temporary 
filename for %s: %m, new_path);
+return log_error_errno(r, Failed to determine temporary 
filename for \%s\: %m, new_path);
 
 r = mkdir_parents(new_path, 0755);
 if (r  0) {
-log_error_errno(r, Failed to create directories for %s: %m, 
new_path);
+log_error_errno(r, Failed to create directories for \%s\: 
%m, new_path);
 free(t);
 return r;
 }
@@ -5738,12 +5738,12 @@ static int create_edit_temp_file(const char *new_path, 
const char *original_path
 if (r == -ENOENT) {
 r = touch(t);
 if (r  0) {
-log_error_errno(r, Failed to create temporary file 
%s: %m, t);
+log_error_errno(r, Failed to create temporary file 
\%s\: %m, t);
 free(t);
 return r;
 }
 } else if (r  0) {
-log_error_errno(r, Failed to copy %s to %s: %m, 
original_path, t);
+log_error_errno(r, Failed to copy \%s\ to \%s\: %m, 
original_path, t);
 free(t);
 return r;
 }
@@ -5851,7 +5851,7 @@ static int unit_file_create_copy(const char *unit_name,
 if (!path_equal(fragment_path, tmp_new_path)  access(tmp_new_path, 
F_OK) == 0) {
 char response;
 
-r = ask_char(response, yn, %s already exists, are you sure 
to overwrite it with %s? [(y)es, (n)o] , tmp_new_path, fragment_path);
+r = ask_char(response, yn, \%s\ already exists. 
Overwrite with \%s\? [(y)es, (n)o] , tmp_new_path, fragment_path);
 if (r  0) {
 free(tmp_new_path);
 return r;
@@ -5865,7 +5865,7 @@ static int unit_file_create_copy(const char *unit_name,
 
 r = create_edit_temp_file(tmp_new_path, fragment_path, tmp_tmp_path);
 if (r  0) {
-log_error_errno(r, Failed to create temporary file for %s: 
%m, tmp_new_path);
+log_error_errno(r, Failed to create temporary file for 
\%s\: %m, tmp_new_path);
 free(tmp_new_path);
 return r;
 }
@@ -6001,7 +6001,7 @@ static int edit(sd_bus *bus, char **args) {
 assert(args);
 
 if (!on_tty()) {
-log_error(Cannot edit units if we are not on a tty);
+log_error(Cannot edit units if not on a tty);
 return -EINVAL;
 }
 
@@ -6030,12 +6030,12 @@ static int edit(sd_bus *bus, char **args) {
  * It's useful if the user wants to cancel its modification
  */
 if (null_or_empty_path(*tmp)) {
-log_warning(Edition of %s canceled: temporary file 
empty, *original);
+log_warning(Editing \%s\ canceled: temporary file 
is empty, *original);
 continue;
 }
 r = rename(*tmp, *original);
 if (r  0) {
-r = log_error_errno(errno, Failed to rename %s to %s: 
%m, *tmp, *original);
+r = log_error_errno(errno, Failed to rename \%s\ to 
\%s\: %m, *tmp, *original);
 goto end;
 }
 }
-- 
2.2.2

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


[systemd-devel] [PATCHv2 4/4] systemctl: unit_find_paths(): unify error handling in two code pathes

2015-02-04 Thread Ivan Shapovalov
---
 src/systemctl/systemctl.c | 63 ++-
 1 file changed, 35 insertions(+), 28 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 384ae02..2d70ff1 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2293,6 +2293,9 @@ static int unit_find_paths(sd_bus *bus,
LookupPaths *lp,
char **fragment_path,
char ***dropin_paths) {
+
+_cleanup_free_ char *path = NULL;
+_cleanup_strv_free_ char **dropins = NULL;
 int r;
 
 /**
@@ -2311,8 +2314,6 @@ static int unit_find_paths(sd_bus *bus,
 _cleanup_bus_error_free_ sd_bus_error error = 
SD_BUS_ERROR_NULL;
 _cleanup_bus_message_unref_ sd_bus_message *unit_load_error = 
NULL;
 _cleanup_free_ char *unit = NULL;
-_cleanup_free_ char *path = NULL;
-_cleanup_strv_free_ char **dropins = NULL;
 _cleanup_strv_free_ char **load_error = NULL;
 char *unit_load_error_name, *unit_load_error_message;
 
@@ -2359,28 +2360,17 @@ static int unit_find_paths(sd_bus *bus,
 if (r  0)
 return log_error_errno(r, Failed to get FragmentPath: 
%s, bus_error_message(error, r));
 
-r = sd_bus_get_property_strv(
-bus,
-org.freedesktop.systemd1,
-unit,
-org.freedesktop.systemd1.Unit,
-DropInPaths,
-error,
-dropins);
-if (r  0)
-return log_error_errno(r, Failed to get DropInPaths: 
%s, bus_error_message(error, r));
-
-r = 0;
-if (!isempty(path)) {
-*fragment_path = path;
-path = NULL;
-r = 1;
-}
-
-if (dropin_paths  !strv_isempty(dropins)) {
-*dropin_paths = dropins;
-dropins = NULL;
-r = 1;
+if (dropin_paths) {
+r = sd_bus_get_property_strv(
+bus,
+org.freedesktop.systemd1,
+unit,
+org.freedesktop.systemd1.Unit,
+DropInPaths,
+error,
+dropins);
+if (r  0)
+return log_error_errno(r, Failed to get 
DropInPaths: %s, bus_error_message(error, r));
 }
 } else {
 _cleanup_set_free_ Set *names;
@@ -2393,7 +2383,7 @@ static int unit_find_paths(sd_bus *bus,
 if (r  0)
 return r;
 
-r = unit_file_find_path(lp, unit_name, fragment_path);
+r = unit_file_find_path(lp, unit_name, path);
 if (r  0)
 return r;
 
@@ -2405,14 +2395,31 @@ static int unit_find_paths(sd_bus *bus,
 return log_oom();
 
 if (!streq(template, unit_name)) {
-r = unit_file_find_path(lp, template, 
fragment_path);
+r = unit_file_find_path(lp, template, path);
 if (r  0)
 return r;
 }
 }
 
-if (dropin_paths)
-r = unit_file_find_dropin_paths(lp-unit_path, NULL, 
names, dropin_paths);
+if (dropin_paths) {
+r = unit_file_find_dropin_paths(lp-unit_path, NULL, 
names, dropins);
+if (r  0)
+return r;
+}
+}
+
+r = 0;
+
+if (!isempty(path)) {
+*fragment_path = path;
+path = NULL;
+r = 1;
+}
+
+if (dropin_paths  !strv_isempty(dropins)) {
+*dropin_paths = dropins;
+dropins = NULL;
+r = 1;
 }
 
 if (r == 0)
-- 
2.2.2

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


[systemd-devel] [PATCHv2 2/4] systemctl: cat: fix error handling

2015-02-04 Thread Ivan Shapovalov
- correctly check for local vs. remote transport
- return after receiving error from expand_names()
---
 src/systemctl/systemctl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 083b618..567b467 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4594,8 +4594,8 @@ static int cat(sd_bus *bus, char **args) {
 
 assert(args);
 
-if (arg_host) {
-log_error(Option --host cannot be used with 'cat');
+if (arg_transport != BUS_TRANSPORT_LOCAL) {
+log_error(Cannot remotely cat units);
 return -EINVAL;
 }
 
@@ -4605,7 +4605,7 @@ static int cat(sd_bus *bus, char **args) {
 
 r = expand_names(bus, args + 1, NULL, names);
 if (r  0)
-log_error_errno(r, Failed to expand names: %m);
+return log_error_errno(r, Failed to expand names: %m);
 
 avoid_bus_cache = !bus || avoid_bus();
 
-- 
2.2.2

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


[systemd-devel] [PATCHv2 1/4] systemctl: cat, edit: improve unit load error reporting

2015-02-04 Thread Ivan Shapovalov
- report actual load error for units which could not be loaded
- make unit_find_paths() report all kinds of errors it encounters
  (for consistency)
- consistently handle not-found errors in cat() and edit()
---
 src/systemctl/systemctl.c | 54 +++
 1 file changed, 40 insertions(+), 14 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 462f7fd..083b618 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2309,9 +2309,12 @@ static int unit_find_paths(sd_bus *bus,
 
 if (!avoid_bus_cache  !unit_name_is_template(unit_name)) {
 _cleanup_bus_error_free_ sd_bus_error error = 
SD_BUS_ERROR_NULL;
+_cleanup_bus_message_unref_ sd_bus_message *unit_load_error = 
NULL;
 _cleanup_free_ char *unit = NULL;
 _cleanup_free_ char *path = NULL;
 _cleanup_strv_free_ char **dropins = NULL;
+_cleanup_strv_free_ char **load_error = NULL;
+char *unit_load_error_name, *unit_load_error_message;
 
 unit = unit_dbus_path_from_name(unit_name);
 if (!unit)
@@ -2320,6 +2323,31 @@ static int unit_find_paths(sd_bus *bus,
 if (need_daemon_reload(bus, unit_name)  0)
 warn_unit_file_changed(unit_name);
 
+r = sd_bus_get_property(
+bus,
+org.freedesktop.systemd1,
+unit,
+org.freedesktop.systemd1.Unit,
+LoadError,
+error,
+unit_load_error,
+(ss));
+if (r  0)
+return log_error_errno(r, Failed to get LoadError: 
%s, bus_error_message(error, r));
+
+r = sd_bus_message_read(
+unit_load_error,
+(ss),
+unit_load_error_name,
+unit_load_error_message);
+if (r  0)
+return bus_log_parse_error(r);
+
+if (!isempty(unit_load_error_name)) {
+log_error(Unit %s is not loaded: %s, unit_name, 
unit_load_error_message);
+return 0;
+}
+
 r = sd_bus_get_property_string(
 bus,
 org.freedesktop.systemd1,
@@ -2387,6 +2415,9 @@ static int unit_find_paths(sd_bus *bus,
 r = unit_file_find_dropin_paths(lp-unit_path, NULL, 
names, dropin_paths);
 }
 
+if (r == 0)
+log_error(No files found for %s., unit_name);
+
 return r;
 }
 
@@ -4588,10 +4619,8 @@ static int cat(sd_bus *bus, char **args) {
 r = unit_find_paths(bus, *name, avoid_bus_cache, lp, 
fragment_path, dropin_paths);
 if (r  0)
 return r;
-else if (r == 0) {
-log_warning(Unit %s does not have any files on disk, 
*name);
-continue;
-}
+else if (r == 0)
+return -ENOENT;
 
 if (first)
 first = false;
@@ -5940,9 +5969,13 @@ static int find_paths_to_edit(sd_bus *bus, char **names, 
char ***paths) {
 r = unit_find_paths(bus, *name, avoid_bus_cache, lp, path, 
NULL);
 if (r  0)
 return r;
-else if (r == 0 || !path)
+else if (r == 0)
+return -ENOENT;
+else if (!path) {
 // FIXME: support units with path==NULL (no 
FragmentPath)
-return log_error_errno(ENOENT, Unit %s not found, 
cannot edit., *name);
+log_error(No fragment exists for %s., *name);
+return -ENOENT;
+}
 
 if (arg_full)
 r = unit_file_create_copy(*name, path, user_home, 
user_runtime, new_path, tmp_path);
@@ -5981,19 +6014,12 @@ static int edit(sd_bus *bus, char **args) {
 if (r  0)
 return log_error_errno(r, Failed to expand names: %m);
 
-if (!names) {
-log_error(No unit name found by expanding names);
-return -ENOENT;
-}
-
 r = find_paths_to_edit(bus, names, paths);
 if (r  0)
 return r;
 
-if (strv_isempty(paths)) {
-log_error(Cannot find any units to edit);
+if (strv_isempty(paths))
 return -ENOENT;
-}
 
 r = run_editor(paths);
 if (r  0)
-- 
2.2.2

___

Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

2015-02-04 Thread Ivan Shapovalov
On 2015-01-28 at 22:29 +0300, Ivan Shapovalov wrote:
 On 2015-01-28 at 20:15 +0100, Lennart Poettering wrote:
  On Sun, 18.01.15 04:21, Ivan Shapovalov (intelfx...@gmail.com) wrote:
  
   Hi folks,
   
   I'm trying to fix this bug:
   https://bugs.freedesktop.org/show_bug.cgi?id=88401
   
   The initial problem (as reported) looks following: performing a reload
   (maybe implicitly) re-starts alsa-restore.service if it is enabled.
   
   With a bit of debugging I've apparently found a root cause. Explanation
   following.
   
   Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
   started.
   
   We enter manager_reload(), units are serialized, reset, re-read,
   deserialized and then cold-plugged. (Note that e. g. unit_notify() has
   special protection to avoid spawning jobs when a reload is in
   progress.)
   
   So, if org.cups.cupsd.path is started, *it is almost first to be
   cold-plugged*. The call chain is:
   
   unit_coldplug()
   path_coldplug()
   path_enter_waiting() // recheck == true
   path_check_good() // returns true
   path_enter_running()
   manager_add_job() // at this point we're fucked up
   
   So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
   because a reload should never enqueue any jobs (IIUC). So, the job is
   enqueued... remember that almost all units are inactive by now. Thus we
   end up re-starting half a system (the whole basic.target) as
   dependencies.
   
   Questions:
   - is my analysis correct?
   - if yes, then how to fix this? Maybe add a similar
 if (UNIT(p)-manager-n_reloading = 0) check to
 path_enter_running() to avoid calling manager_add_job() during
 reloading?
  
  Hmm, how does this relate to the ALSA case? I mean, the alsa units
  don't use .path units, do they?
 
 The .path unit from CUPS is triggered and starts its .service unit
 *while the service unit's state has not yet been coldplugged*.
 Actually, almost nothing is coldplugged at that point. Thus the
 basic.target is effectively re-started with all its dependencies,
 ignoring all existing state (because it is not yet coldplugged). This
 is the actual bug, and it is the root cause of the reported bug.
 
 Reported bug, on the other hand, happens due to
 1) the above-described bug (not related to alsa) takes place;
 2) alsa-restore.service is Type=oneshot, RemainAfterExit=false and
WantedBy=basic.target.
 
 Hope it makes things clearer...

Ping? Lennart, do you understand what's going on, or should I try to
describe things more carefully?

// I would like to get this fixed before v219 ;)

Thanks.
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 2/4] systemctl: edit: improve error messages, report actual error for units which could not be loaded

2015-02-03 Thread Ivan Shapovalov
On 2015-02-03 at 23:05 +0100, Lennart Poettering wrote:
 On Fri, 19.12.14 17:08, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
 What happened to this patch series actually? I think only 1/4 was ever
 commited, what about the other ones? Ivan, any chance you can rebase
 the rest with Zbigniew's requested changes and post again?

Yeah, I've kinda forgotten about this series... Will do. Thanks for the
reminder!

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 3/4] systemctl: edit: further reword error messages

2015-02-03 Thread Ivan Shapovalov
On 2015-01-05 at 17:08 +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Fri, Dec 19, 2014 at 05:08:09PM +0300, Ivan Shapovalov wrote:
  ---
   src/systemctl/systemctl.c | 22 +++---
   1 file changed, 11 insertions(+), 11 deletions(-)
  
  diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
  index 658793e..20c367c 100644
  --- a/src/systemctl/systemctl.c
  +++ b/src/systemctl/systemctl.c
  @@ -4776,7 +4776,7 @@ static int init_home_and_lookup_paths(char 
  **user_home, char **user_runtime, Loo
   
   r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
   if (r  0)
  -return log_error_errno(r, Failed to lookup unit lookup 
  paths: %m);
  +return log_error_errno(r, Failed to get unit lookup 
  paths: %m);
 Maybe query? get is ugly.

OK.

 
   return 0;
   }
  @@ -5900,11 +5900,11 @@ static int create_edit_temp_file(const char 
  *new_path, const char *original_path
   
   r = tempfn_random(new_path, t);
   if (r  0)
  -return log_error_errno(r, Failed to determine temporary 
  filename for %s: %m, new_path);
  +return log_error_errno(r, Failed to determine temporary 
  filename for \%s\: %m, new_path);
   
   r = mkdir_parents(new_path, 0755);
   if (r  0) {
  -log_error_errno(r, Failed to create directories for %s: 
  %m, new_path);
  +log_error_errno(r, Failed to create directories for 
  \%s\: %m, new_path);
   free(t);
   return r;
   }
  @@ -5913,12 +5913,12 @@ static int create_edit_temp_file(const char 
  *new_path, const char *original_path
   if (r == -ENOENT) {
   r = touch(t);
   if (r  0) {
  -log_error_errno(r, Failed to create temporary 
  file %s: %m, t);
  +log_error_errno(r, Failed to create temporary 
  file \%s\: %m, t);
   free(t);
   return r;
   }
   } else if (r  0) {
  -log_error_errno(r, Failed to copy %s to %s: %m, 
  original_path, t);
  +log_error_errno(r, Failed to copy \%s\ to \%s\: %m, 
  original_path, t);
   free(t);
   return r;
   }
  @@ -6026,7 +6026,7 @@ static int unit_file_create_copy(const char 
  *unit_name,
   if (!path_equal(fragment_path, tmp_new_path)  
  access(tmp_new_path, F_OK) == 0) {
   char response;
   
  -r = ask_char(response, yn, %s already exists, are you 
  sure to overwrite it with %s? [(y)es, (n)o] , tmp_new_path, fragment_path);
  +r = ask_char(response, yn, \%s\ already exists, are 
  you sure to overwrite it with \%s\? [(y)es, (n)o] , tmp_new_path, 
  fragment_path);
 
 This is not gramatically correct. I think
 \%s\ already exists. Overwrite with \%s\?... would be better.

OK.

 
 
   if (r  0) {
   free(tmp_new_path);
   return r;
  @@ -6040,7 +6040,7 @@ static int unit_file_create_copy(const char 
  *unit_name,
   
   r = create_edit_temp_file(tmp_new_path, fragment_path, 
  tmp_tmp_path);
   if (r  0) {
  -log_error_errno(r, Failed to create temporary file for 
  %s: %m, tmp_new_path);
  +log_error_errno(r, Failed to create temporary file for 
  \%s\: %m, tmp_new_path);
   free(tmp_new_path);
   return r;
   }
  @@ -6176,12 +6176,12 @@ static int edit(sd_bus *bus, char **args) {
   assert(args);
   
   if (!on_tty()) {
  -log_error(Cannot edit units if we are not on a tty);
  +log_error(Not on a tty, refusing.);
 Why? Replacing a nice specific error message with a generic one seems to
 be a step backwards.

I've tried to follow the existing pattern of most error messages in
systemd: Condition, action + -ing.

I'll reword again to make messages more specific... unless you tell me
to stop bikeshedding and leave it as is ;)

 
   return -EINVAL;
   }
   
   if (arg_transport != BUS_TRANSPORT_LOCAL) {
  -log_error(Cannot remotely edit units);
  +log_error(Remote operation requested, refusing.);
 And the same here.
 
   return -EINVAL;
   }
   
  @@ -6205,12 +6205,12 @@ static int edit(sd_bus *bus, char **args) {
* It's useful if the user wants to cancel its modification
*/
   if (null_or_empty_path(*tmp)) {
  -log_warning(Edition of %s canceled: temporary 
  file empty, *original);
  +log_warning(Temporary file empty, not saving.);
 And here.

Here? They are equally specific; editing cancelled == file not
saved.

-- 
Ivan Shapovalov / intelfx

Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

2015-01-28 Thread Ivan Shapovalov
On 2015-01-28 at 20:15 +0100, Lennart Poettering wrote:
 On Sun, 18.01.15 04:21, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  Hi folks,
  
  I'm trying to fix this bug:
  https://bugs.freedesktop.org/show_bug.cgi?id=88401
  
  The initial problem (as reported) looks following: performing a reload
  (maybe implicitly) re-starts alsa-restore.service if it is enabled.
  
  With a bit of debugging I've apparently found a root cause. Explanation
  following.
  
  Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
  started.
  
  We enter manager_reload(), units are serialized, reset, re-read,
  deserialized and then cold-plugged. (Note that e. g. unit_notify() has
  special protection to avoid spawning jobs when a reload is in
  progress.)
  
  So, if org.cups.cupsd.path is started, *it is almost first to be
  cold-plugged*. The call chain is:
  
  unit_coldplug()
  path_coldplug()
  path_enter_waiting() // recheck == true
  path_check_good() // returns true
  path_enter_running()
  manager_add_job() // at this point we're fucked up
  
  So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
  because a reload should never enqueue any jobs (IIUC). So, the job is
  enqueued... remember that almost all units are inactive by now. Thus we
  end up re-starting half a system (the whole basic.target) as
  dependencies.
  
  Questions:
  - is my analysis correct?
  - if yes, then how to fix this? Maybe add a similar
if (UNIT(p)-manager-n_reloading = 0) check to
path_enter_running() to avoid calling manager_add_job() during
reloading?
 
 Hmm, how does this relate to the ALSA case? I mean, the alsa units
 don't use .path units, do they?

The .path unit from CUPS is triggered and starts its .service unit
*while the service unit's state has not yet been coldplugged*.
Actually, almost nothing is coldplugged at that point. Thus the
basic.target is effectively re-started with all its dependencies,
ignoring all existing state (because it is not yet coldplugged). This
is the actual bug, and it is the root cause of the reported bug.

Reported bug, on the other hand, happens due to
1) the above-described bug (not related to alsa) takes place;
2) alsa-restore.service is Type=oneshot, RemainAfterExit=false and
   WantedBy=basic.target.

Hope it makes things clearer...

-- 
Ivan Shapovalov / intelfx /

 
 So, in general I think .path units should trigger things on reload,
 but only those things that ar bound to level, not those to edge,
 if you follow what I mean. More specifically, I think that cups.path
 should trigger things, since its job is to make sure that cups.service
 is running as long as there's a file in /var/spool/cups/. 
 
 PathExists=/PathExistsGlob=/DirectoryNotEmpty= are all of the level
 kind. As long as the condition they express is true they should ensure
 their service is running.  PathChanged= and PathModified= OTOH are
 edge triggers, and they should only trigger something when a file is
 changed while we look at it, but not during coldplugging.
 
 During a reload, I hence believe it is OK if trigger units trigger new
 jobs. 
 
 Anyway, I am not really sure I grok the relation to
 alsa-restore... Can you elaborate?
 
 Lennart
 



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

2015-01-23 Thread Ivan Shapovalov
On 2015-01-18 at 04:21 +0300, Ivan Shapovalov wrote:
 Hi folks,
 
 I'm trying to fix this bug:
 https://bugs.freedesktop.org/show_bug.cgi?id=88401
 
 The initial problem (as reported) looks following: performing a reload
 (maybe implicitly) re-starts alsa-restore.service if it is enabled.
 
 With a bit of debugging I've apparently found a root cause. Explanation
 following.
 
 Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
 started.
 
 We enter manager_reload(), units are serialized, reset, re-read,
 deserialized and then cold-plugged. (Note that e. g. unit_notify() has
 special protection to avoid spawning jobs when a reload is in
 progress.)
 
 So, if org.cups.cupsd.path is started, *it is almost first to be
 cold-plugged*. The call chain is:
 
 unit_coldplug()
 path_coldplug()
 path_enter_waiting() // recheck == true
 path_check_good() // returns true
 path_enter_running()
 manager_add_job() // at this point we're fucked up
 
 So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
 because a reload should never enqueue any jobs (IIUC). So, the job is
 enqueued... remember that almost all units are inactive by now. Thus we
 end up re-starting half a system (the whole basic.target) as
 dependencies.
 
 Questions:
 - is my analysis correct?
 - if yes, then how to fix this? Maybe add a similar
   if (UNIT(p)-manager-n_reloading = 0) check to
   path_enter_running() to avoid calling manager_add_job() during
   reloading?

Anyone?

-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

2015-01-17 Thread Ivan Shapovalov
On 2015-01-18 at 04:21 +0300, Ivan Shapovalov wrote:
 [...]
 Questions:
 - is my analysis correct?
 - if yes, then how to fix this? Maybe add a similar
   if (UNIT(p)-manager-n_reloading = 0) check to
   path_enter_running() to avoid calling manager_add_job() during
   reloading?

Here's what I have in mind:

From 829c474acb861619c01e04da58ee44fa25507fd9 Mon Sep 17 00:00:00 2001
From: Ivan Shapovalov intelfx...@gmail.com
Date: Sun, 18 Jan 2015 04:27:04 +0300
Subject: [PATCH] core/path: do not add any jobs when changing state during
 reload

---
 src/core/path.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/core/path.c b/src/core/path.c
index 0fdf483..d2b35e4 100644
--- a/src/core/path.c
+++ b/src/core/path.c
@@ -477,10 +477,12 @@ static void path_enter_running(Path *p) {
 if (unit_stop_pending(UNIT(p)))
 return;
 
-r = manager_add_job(UNIT(p)-manager, JOB_START, UNIT_TRIGGER(UNIT(p)),
-JOB_REPLACE, true, error, NULL);
-if (r  0)
-goto fail;
+if (UNIT(p)-manager-n_reloading = 0) {
+r = manager_add_job(UNIT(p)-manager, JOB_START, 
UNIT_TRIGGER(UNIT(p)),
+JOB_REPLACE, true, error, NULL);
+if (r  0)
+goto fail;
+}
 
 p-inotify_triggered = false;
 
-- 
2.2.2

-- 
Ivan Shapovalov / intelfx /




signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

2015-01-17 Thread Ivan Shapovalov
Hi folks,

I'm trying to fix this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88401

The initial problem (as reported) looks following: performing a reload
(maybe implicitly) re-starts alsa-restore.service if it is enabled.

With a bit of debugging I've apparently found a root cause. Explanation
following.

Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
started.

We enter manager_reload(), units are serialized, reset, re-read,
deserialized and then cold-plugged. (Note that e. g. unit_notify() has
special protection to avoid spawning jobs when a reload is in
progress.)

So, if org.cups.cupsd.path is started, *it is almost first to be
cold-plugged*. The call chain is:

unit_coldplug()
path_coldplug()
path_enter_waiting() // recheck == true
path_check_good() // returns true
path_enter_running()
manager_add_job() // at this point we're fucked up

So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
because a reload should never enqueue any jobs (IIUC). So, the job is
enqueued... remember that almost all units are inactive by now. Thus we
end up re-starting half a system (the whole basic.target) as
dependencies.

Questions:
- is my analysis correct?
- if yes, then how to fix this? Maybe add a similar
  if (UNIT(p)-manager-n_reloading = 0) check to
  path_enter_running() to avoid calling manager_add_job() during
  reloading?

Thanks,
-- 
Ivan Shapovalov / intelfx /


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Typo fix in libabc (you missed my prev. letter?)

2015-01-08 Thread Ivan Shapovalov
On Thursday 08 January 2015 at 08:11:05, Martin Pitt wrote: 
 Hello Askar,
 
 Askar Safin [2015-01-07  1:13 +0300]:
  Hi. It seems you missed my prev. letter. So, I am sending you the patch 
  again. Typo fix in README in libabc:
  -Make your code safe for unexpected termination and any point:
  +Make your code safe for unexpected termination at any point:
 
 I (and I'm sure other people) actually did see it, but this mailing
 list is about systemd. Whatever libabc is, it's something entirely
 different, and this typo fix doesn't apply to systemd.

This seems to be a correct mailing list:
https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/tree/README#n26

However, Askar, what you have provided isn't a patch, it is just two lines of
text. You'd better send a correct git-formatted patch.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Delegate=yes and user instance's resource controlling

2015-01-06 Thread Ivan Shapovalov
On Monday 05 January 2015 at 18:32:35, Lennart Poettering wrote:
 On Thu, 25.12.14 23:38, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  Hi!
  
  Judging from commit a931ad47a8623163a29d898224d8a8c1177ffdaf,
  the systemd user instance is intentionally restricted from touching
  !systemd hierarchies. So, things like
  systemctl --user set-property foo.service MemoryLimit=XYZ
  do not work.
  
  Is this restriction going to be lifted in the future? If not, are there any
  alternative ways to achieve resource controlling per-user-service?
 
 No, this is currently not available, simply because it is not safe
 from the kernel side of things.
 
 We will open up some of the properties eventually, when the kernel
 folks consider them safe.

OK, understood, thanks!

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/4] path-lookup, systemctl: export lookup_paths_init_from_scope() from shared/install.c and use it

2015-01-02 Thread Ivan Shapovalov
On Friday 26 December 2014 at 00:27:16, Ivan Shapovalov wrote:  
 On Friday 19 December 2014 at 17:08:07, Ivan Shapovalov wrote:
  ---
   src/shared/install.c  | 16 
   src/shared/path-lookup.c  | 16 
   src/shared/path-lookup.h  |  4 
   src/systemctl/systemctl.c |  6 +-
   4 files changed, 21 insertions(+), 21 deletions(-)
  
  [...]
 
 Ping?

Ping? :-)

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] PrivateDevices=true blocks use of ttys?

2014-12-26 Thread Ivan Shapovalov
On Friday 26 December 2014 at 13:37:58, Alison Chaiken wrote:   
 On Fedora 21, I created a unit file in which I included
 'PrivateDevices=true'.When I attempt to start the unit from the text
 console, the unit fails, and 'systemctl status -l' reports:
 
 startx[2754]: (EE) xf86OpenConsole: Cannot open /dev/tty0 (No such file or
 directory)
 
 
 When I take 'PrivateDevices=true' out of the unit file, it works fine.
 The man page for systemd.exec reads
 
 PrivateDevices=
 Takes a boolean argument. If true, sets up a new /dev namespace for the
 executed processes and only adds API pseudo devices such as /dev/null,
 /dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it, but
 no physical devices such as /dev/sda.
 
 
 Isn't /dev/tty0 a pseudo TTY?   Shouldn't a service that has
 'PrivateDevices=true' be able to access /dev/tty0?   I'm willing to
 investigate further to see if there's a bug, but want to make sure that I
 understand the expected behavior first

The TTY may be a pseudo-device, but to the kernel it's still a device, and it
has its own dynamically created device node in /dev. So, if the unit has
`PrivateDevices=true`, it basically gets its own /dev with only a few files
inside, and ttys aren't among these files.
At least, that's how I understand it. Maybe you can do an mknod from 
ExecStartPre=,
if you know the major:minor (4:0 for /dev/tty0) beforehand?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Delegate=yes and user instance's resource controlling

2014-12-25 Thread Ivan Shapovalov
Hi!

Judging from commit a931ad47a8623163a29d898224d8a8c1177ffdaf,
the systemd user instance is intentionally restricted from touching
!systemd hierarchies. So, things like
systemctl --user set-property foo.service MemoryLimit=XYZ
do not work.

Is this restriction going to be lifted in the future? If not, are there any
alternative ways to achieve resource controlling per-user-service?

Thanks in advance.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/4] path-lookup, systemctl: export lookup_paths_init_from_scope() from shared/install.c and use it

2014-12-25 Thread Ivan Shapovalov
On Friday 19 December 2014 at 17:08:07, Ivan Shapovalov wrote:  
 ---
  src/shared/install.c  | 16 
  src/shared/path-lookup.c  | 16 
  src/shared/path-lookup.h  |  4 
  src/systemctl/systemctl.c |  6 +-
  4 files changed, 21 insertions(+), 21 deletions(-)
 
 [...]

Ping?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] logind, su - sessions and initscripts compatibility

2014-12-21 Thread Ivan Shapovalov
On Friday, December 19, 2014 at 07:58:11 PM, Andrei Borzenkov wrote:
 В Fri, 19 Dec 2014 11:16:58 -0500
 wor...@alum.mit.edu (Dale R. Worley) пишет:
 
  Simon McVittie simon.mcvit...@collabora.co.uk writes:
   On 18/12/14 14:10, Dale R. Worley wrote:
   Simon McVittie simon.mcvit...@collabora.co.uk writes:
   On 18/12/14 08:05, Andrei Borzenkov wrote:
   Any initscript that is using su - would [cause badness]
  
   Don't do that then? Init scripts are fairly clearly not login sessions.
   Which init scripts do that?
   
   More to the point, why would an initscript do that, since it's *already*
   running as root?
  
   su isn't just for becoming root; it can also cause transitions from root
   to a less privileged user (su -c 'my-app-clear-cache' daemon is one
   example of something that an init script might want to do).
  
  Yeah, ack, that was my mistake.  I was confusing su, su [user], and
  su - [user].  But the question is about the su - [user] form, which
  is basically intended to start a new login session (as far as I can see
  from the man page), since it gives the user's shell a - in argv[0],
  which is intended to instruct the shell to run the user's
  initializations, etc.
  
  Which means that the question I should have asked is Why would an
  initscript use 'su -', as that is intended to start a new login
  session?
  
 
 There is not a single word about login session in su man page.
 It says it starts login shell - but login session is not created by
 shell so I do not see where you draw this conclusion from.

It's indirectly so.
This version of su uses PAM for authentication, account and session 
management.

Maybe it's a problem of distro/integration? In current Arch, /etc/pam.d/su{,-l} 
say

#%PAM-1.0
authsufficient  pam_rootok.so
# Uncomment the following line to implicitly trust users in the wheel group.
#auth   sufficient  pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the wheel group.
#auth   requiredpam_wheel.so use_uid
authrequiredpam_unix.so
account requiredpam_unix.so
session requiredpam_unix.so

, and su - my user started in systemd's debug shell seems to survive the
transition to rescue.target. Which is just as expected, because in this
configuration su does not register its sessions in logind.

(Please correct me if my analysis is wrong.)

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Improving module loading

2014-12-21 Thread Ivan Shapovalov
On Sunday, December 21, 2014 at 01:03:36 PM, Hoyer, Marko wrote:
  -Original Message-
  From: Umut Tezduyar Lindskog [mailto:u...@tezduyar.com]
  Sent: Saturday, December 20, 2014 6:45 PM
  To: Hoyer, Marko (ADITG/SW2)
  Cc: systemd-devel@lists.freedesktop.org
  Subject: Re: [systemd-devel] Improving module loading
  
  [...]
   I had such a discussion earlier with some of the systemd guys. My
  intention was to introduce an additional unit for module loading for
  exactly the reason you mentioned. The following (reasonable) outcome
  was:
  
  Do you have links for the discussions, I cannot find them.
 
 Actually not, sorry. The discussion was not done via any mailing list.
 
  systemd already has a service that loads the modules.
 
 Sorry, there is a word missing in my sentence above. My idea was not to 
 introduce a unit for modules loading but an own unit type, such as 
 .kmodule. The idea was to define .kmodule units to load one or a set of 
 kernel modules each at a certain point during startup by just integrating 
 them into the startup dependency tree. This idea would require integrating 
 kind of worker threads into systemd. The outcome was as summarized below.

Why would you need a separate unit type for that?

load-module@.service:

[Unit]
Description=Load kernel module %I
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/modprobe %I

...then add a dependency like Required=load-module@foo.service and 
After=load-module@foo.service.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 1/4] path-lookup, systemctl: export lookup_paths_init_from_scope() from shared/install.c and use it

2014-12-19 Thread Ivan Shapovalov
---
 src/shared/install.c  | 16 
 src/shared/path-lookup.c  | 16 
 src/shared/path-lookup.h  |  4 
 src/systemctl/systemctl.c |  6 +-
 4 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/src/shared/install.c b/src/shared/install.c
index efbe61e..2dcdfc3 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -58,22 +58,6 @@ static int in_search_path(const char *path, char **search) {
 return strv_contains(search, parent);
 }
 
-static int lookup_paths_init_from_scope(LookupPaths *paths,
-UnitFileScope scope,
-const char *root_dir) {
-assert(paths);
-assert(scope = 0);
-assert(scope  _UNIT_FILE_SCOPE_MAX);
-
-zero(*paths);
-
-return lookup_paths_init(paths,
- scope == UNIT_FILE_SYSTEM ? SYSTEMD_SYSTEM : 
SYSTEMD_USER,
- scope == UNIT_FILE_USER,
- root_dir,
- NULL, NULL, NULL);
-}
-
 static int get_config_path(UnitFileScope scope, bool runtime, const char 
*root_dir, char **ret) {
 char *p = NULL;
 int r;
diff --git a/src/shared/path-lookup.c b/src/shared/path-lookup.c
index 8f75a8e..051f1a4 100644
--- a/src/shared/path-lookup.c
+++ b/src/shared/path-lookup.c
@@ -398,3 +398,19 @@ void lookup_paths_free(LookupPaths *p) {
 p-sysvinit_path = p-sysvrcnd_path = NULL;
 #endif
 }
+
+int lookup_paths_init_from_scope(LookupPaths *paths,
+ UnitFileScope scope,
+ const char *root_dir) {
+assert(paths);
+assert(scope = 0);
+assert(scope  _UNIT_FILE_SCOPE_MAX);
+
+zero(*paths);
+
+return lookup_paths_init(paths,
+ scope == UNIT_FILE_SYSTEM ? SYSTEMD_SYSTEM : 
SYSTEMD_USER,
+ scope == UNIT_FILE_USER,
+ root_dir,
+ NULL, NULL, NULL);
+}
diff --git a/src/shared/path-lookup.h b/src/shared/path-lookup.h
index b8a0aac..655e454 100644
--- a/src/shared/path-lookup.h
+++ b/src/shared/path-lookup.h
@@ -22,6 +22,7 @@
 ***/
 
 #include macro.h
+#include install.h
 
 typedef struct LookupPaths {
 char **unit_path;
@@ -49,5 +50,8 @@ int lookup_paths_init(LookupPaths *p,
   const char *generator_early,
   const char *generator_late);
 void lookup_paths_free(LookupPaths *p);
+int lookup_paths_init_from_scope(LookupPaths *paths,
+ UnitFileScope scope,
+ const char *root_dir);
 
 #define _cleanup_lookup_paths_free_ _cleanup_(lookup_paths_free)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 4c4648f..7af111c 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4742,11 +4742,7 @@ static int init_home_and_lookup_paths(char **user_home, 
char **user_runtime, Loo
 return log_error_errno(ENOTDIR, Cannot find units: 
$XDG_RUNTIME_DIR is not set.);
 }
 
-r = lookup_paths_init(lp,
-  arg_scope == UNIT_FILE_SYSTEM ? SYSTEMD_SYSTEM : 
SYSTEMD_USER,
-  arg_scope == UNIT_FILE_USER,
-  arg_root,
-  NULL, NULL, NULL);
+r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
 if (r  0)
 return log_error_errno(r, Failed to lookup unit lookup paths: 
%m);
 
-- 
2.2.0

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


[systemd-devel] [PATCH 4/4] systemctl: unit_find_paths(): unify error handling in two code pathes

2014-12-19 Thread Ivan Shapovalov
---
 src/systemctl/systemctl.c | 63 ++-
 1 file changed, 35 insertions(+), 28 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 20c367c..2a4e2a2 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2309,6 +2309,9 @@ static int unit_find_paths(sd_bus *bus,
LookupPaths *lp,
char **fragment_path,
char ***dropin_paths) {
+
+_cleanup_free_ char *path = NULL;
+_cleanup_strv_free_ char **dropins = NULL;
 int r;
 
 /**
@@ -2327,8 +2330,6 @@ static int unit_find_paths(sd_bus *bus,
 _cleanup_bus_error_free_ sd_bus_error error = 
SD_BUS_ERROR_NULL;
 _cleanup_bus_message_unref_ sd_bus_message *unit_load_error = 
NULL;
 _cleanup_free_ char *unit = NULL;
-_cleanup_free_ char *path = NULL;
-_cleanup_strv_free_ char **dropins = NULL;
 _cleanup_strv_free_ char **load_error = NULL;
 char *unit_load_error_name, *unit_load_error_message;
 
@@ -2375,28 +2376,17 @@ static int unit_find_paths(sd_bus *bus,
 if (r  0)
 return log_error_errno(r, Failed to get FragmentPath: 
%s, bus_error_message(error, r));
 
-r = sd_bus_get_property_strv(
-bus,
-org.freedesktop.systemd1,
-unit,
-org.freedesktop.systemd1.Unit,
-DropInPaths,
-error,
-dropins);
-if (r  0)
-return log_error_errno(r, Failed to get DropInPaths: 
%s, bus_error_message(error, r));
-
-r = 0;
-if (!isempty(path)) {
-*fragment_path = path;
-path = NULL;
-r = 1;
-}
-
-if (dropin_paths  !strv_isempty(dropins)) {
-*dropin_paths = dropins;
-dropins = NULL;
-r = 1;
+if (dropin_paths) {
+r = sd_bus_get_property_strv(
+bus,
+org.freedesktop.systemd1,
+unit,
+org.freedesktop.systemd1.Unit,
+DropInPaths,
+error,
+dropins);
+if (r  0)
+return log_error_errno(r, Failed to get 
DropInPaths: %s, bus_error_message(error, r));
 }
 } else {
 _cleanup_set_free_ Set *names;
@@ -2409,7 +2399,7 @@ static int unit_find_paths(sd_bus *bus,
 if (r  0)
 return r;
 
-r = unit_file_find_path(lp, unit_name, fragment_path);
+r = unit_file_find_path(lp, unit_name, path);
 if (r  0)
 return r;
 
@@ -2421,14 +2411,31 @@ static int unit_find_paths(sd_bus *bus,
 return log_oom();
 
 if (!streq(template, unit_name)) {
-r = unit_file_find_path(lp, template, 
fragment_path);
+r = unit_file_find_path(lp, template, path);
 if (r  0)
 return r;
 }
 }
 
-if (dropin_paths)
-r = unit_file_find_dropin_paths(lp-unit_path, NULL, 
names, dropin_paths);
+if (dropin_paths) {
+r = unit_file_find_dropin_paths(lp-unit_path, NULL, 
names, dropins);
+if (r  0)
+return r;
+}
+}
+
+r = 0;
+
+if (!isempty(path)) {
+*fragment_path = path;
+path = NULL;
+r = 1;
+}
+
+if (dropin_paths  !strv_isempty(dropins)) {
+*dropin_paths = dropins;
+dropins = NULL;
+r = 1;
 }
 
 if (r == 0) {
-- 
2.2.0

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


[systemd-devel] [PATCH 2/4] systemctl: edit: improve error messages, report actual error for units which could not be loaded

2014-12-19 Thread Ivan Shapovalov
Not found condition in find_paths_to_edit() has been made non-fatal
because the error message in edit() (Cannot find any units to edit)
suggests that.

Error messages in edit() themselves have been removed because
- result of expand_names() is not checked anywhere else
- an extra cannot find any units to edit is redundant due to error reporting
  for each unit in unit_find_paths() and find_paths_to_edit()
---
 src/systemctl/systemctl.c | 53 +++
 1 file changed, 40 insertions(+), 13 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 7af111c..658793e 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2325,9 +2325,12 @@ static int unit_find_paths(sd_bus *bus,
 
 if (!avoid_bus_cache  !unit_name_is_template(unit_name)) {
 _cleanup_bus_error_free_ sd_bus_error error = 
SD_BUS_ERROR_NULL;
+_cleanup_bus_message_unref_ sd_bus_message *unit_load_error = 
NULL;
 _cleanup_free_ char *unit = NULL;
 _cleanup_free_ char *path = NULL;
 _cleanup_strv_free_ char **dropins = NULL;
+_cleanup_strv_free_ char **load_error = NULL;
+char *unit_load_error_name, *unit_load_error_message;
 
 unit = unit_dbus_path_from_name(unit_name);
 if (!unit)
@@ -2336,6 +2339,31 @@ static int unit_find_paths(sd_bus *bus,
 if (need_daemon_reload(bus, unit_name)  0)
 warn_unit_file_changed(unit_name);
 
+r = sd_bus_get_property(
+bus,
+org.freedesktop.systemd1,
+unit,
+org.freedesktop.systemd1.Unit,
+LoadError,
+error,
+unit_load_error,
+(ss));
+if (r  0)
+return log_error_errno(r, Failed to get LoadError: 
%s, bus_error_message(error, r));
+
+r = sd_bus_message_read(
+unit_load_error,
+(ss),
+unit_load_error_name,
+unit_load_error_message);
+if (r  0)
+return bus_log_parse_error(r);
+
+if (!isempty(unit_load_error_name)) {
+log_error(Unit %s is not loaded, ignoring: %s, 
unit_name, unit_load_error_message);
+return 0;
+}
+
 r = sd_bus_get_property_string(
 bus,
 org.freedesktop.systemd1,
@@ -2403,6 +2431,10 @@ static int unit_find_paths(sd_bus *bus,
 r = unit_file_find_dropin_paths(lp-unit_path, NULL, 
names, dropin_paths);
 }
 
+if (r == 0) {
+log_error(No files found for unit %s, ignoring., unit_name);
+}
+
 return r;
 }
 
@@ -4780,10 +4812,8 @@ static int cat(sd_bus *bus, char **args) {
 r = unit_find_paths(bus, *name, avoid_bus_cache, lp, 
fragment_path, dropin_paths);
 if (r  0)
 return r;
-else if (r == 0) {
-log_warning(Unit %s does not have any files on disk, 
*name);
+else if (r == 0)
 continue;
-}
 
 if (first)
 first = false;
@@ -6114,9 +6144,13 @@ static int find_paths_to_edit(sd_bus *bus, char **names, 
char ***paths) {
 r = unit_find_paths(bus, *name, avoid_bus_cache, lp, path, 
NULL);
 if (r  0)
 return r;
-else if (r == 0 || !path)
+else if (r == 0)
+continue;
+else if (!path) {
 // FIXME: support units with path==NULL (no 
FragmentPath)
-return log_error_errno(ENOENT, Unit %s not found, 
cannot edit., *name);
+log_error(No fragment exists for unit %s, ignoring.);
+continue;
+}
 
 if (arg_full)
 r = unit_file_create_copy(*name, path, user_home, 
user_runtime, new_path, tmp_path);
@@ -6155,19 +6189,12 @@ static int edit(sd_bus *bus, char **args) {
 if (r  0)
 return log_error_errno(r, Failed to expand names: %m);
 
-if (!names) {
-log_error(No unit name found by expanding names);
-return -ENOENT;
-}
-
 r = find_paths_to_edit(bus, names, paths);
 if (r  0)
 return r;
 
-if (strv_isempty(paths)) {
-log_error(Cannot find any units to edit);

[systemd-devel] [PATCH 3/4] systemctl: edit: further reword error messages

2014-12-19 Thread Ivan Shapovalov
---
 src/systemctl/systemctl.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 658793e..20c367c 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4776,7 +4776,7 @@ static int init_home_and_lookup_paths(char **user_home, 
char **user_runtime, Loo
 
 r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
 if (r  0)
-return log_error_errno(r, Failed to lookup unit lookup paths: 
%m);
+return log_error_errno(r, Failed to get unit lookup paths: 
%m);
 
 return 0;
 }
@@ -5900,11 +5900,11 @@ static int create_edit_temp_file(const char *new_path, 
const char *original_path
 
 r = tempfn_random(new_path, t);
 if (r  0)
-return log_error_errno(r, Failed to determine temporary 
filename for %s: %m, new_path);
+return log_error_errno(r, Failed to determine temporary 
filename for \%s\: %m, new_path);
 
 r = mkdir_parents(new_path, 0755);
 if (r  0) {
-log_error_errno(r, Failed to create directories for %s: %m, 
new_path);
+log_error_errno(r, Failed to create directories for \%s\: 
%m, new_path);
 free(t);
 return r;
 }
@@ -5913,12 +5913,12 @@ static int create_edit_temp_file(const char *new_path, 
const char *original_path
 if (r == -ENOENT) {
 r = touch(t);
 if (r  0) {
-log_error_errno(r, Failed to create temporary file 
%s: %m, t);
+log_error_errno(r, Failed to create temporary file 
\%s\: %m, t);
 free(t);
 return r;
 }
 } else if (r  0) {
-log_error_errno(r, Failed to copy %s to %s: %m, 
original_path, t);
+log_error_errno(r, Failed to copy \%s\ to \%s\: %m, 
original_path, t);
 free(t);
 return r;
 }
@@ -6026,7 +6026,7 @@ static int unit_file_create_copy(const char *unit_name,
 if (!path_equal(fragment_path, tmp_new_path)  access(tmp_new_path, 
F_OK) == 0) {
 char response;
 
-r = ask_char(response, yn, %s already exists, are you sure 
to overwrite it with %s? [(y)es, (n)o] , tmp_new_path, fragment_path);
+r = ask_char(response, yn, \%s\ already exists, are you 
sure to overwrite it with \%s\? [(y)es, (n)o] , tmp_new_path, fragment_path);
 if (r  0) {
 free(tmp_new_path);
 return r;
@@ -6040,7 +6040,7 @@ static int unit_file_create_copy(const char *unit_name,
 
 r = create_edit_temp_file(tmp_new_path, fragment_path, tmp_tmp_path);
 if (r  0) {
-log_error_errno(r, Failed to create temporary file for %s: 
%m, tmp_new_path);
+log_error_errno(r, Failed to create temporary file for 
\%s\: %m, tmp_new_path);
 free(tmp_new_path);
 return r;
 }
@@ -6176,12 +6176,12 @@ static int edit(sd_bus *bus, char **args) {
 assert(args);
 
 if (!on_tty()) {
-log_error(Cannot edit units if we are not on a tty);
+log_error(Not on a tty, refusing.);
 return -EINVAL;
 }
 
 if (arg_transport != BUS_TRANSPORT_LOCAL) {
-log_error(Cannot remotely edit units);
+log_error(Remote operation requested, refusing.);
 return -EINVAL;
 }
 
@@ -6205,12 +6205,12 @@ static int edit(sd_bus *bus, char **args) {
  * It's useful if the user wants to cancel its modification
  */
 if (null_or_empty_path(*tmp)) {
-log_warning(Edition of %s canceled: temporary file 
empty, *original);
+log_warning(Temporary file empty, not saving.);
 continue;
 }
 r = rename(*tmp, *original);
 if (r  0) {
-r = log_error_errno(errno, Failed to rename %s to %s: 
%m, *tmp, *original);
+r = log_error_errno(errno, Failed to rename \%s\ to 
\%s\: %m, *tmp, *original);
 goto end;
 }
 }
-- 
2.2.0

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


Re: [systemd-devel] Using `systemctl edit` on invalid unit names

2014-12-17 Thread Ivan Shapovalov
On Tuesday, December 16, 2014 at 06:35:09 AM, Zbigniew Jędrzejewski-Szmek 
wrote:
 On Sun, Dec 14, 2014 at 04:21:32PM +0300, Ivan Shapovalov wrote:
  On Saturday 13 December 2014 at 15:34:01, Ronny Chevalier wrote:
   2014-12-13 11:33 GMT+01:00 Ivan Shapovalov intelfx...@gmail.com:
Hello all,
   
   Hi,
   
   
it seems that the newly added `systemctl edit` command requires its 
arguments
to be valid unit names.
   
This causes `edit` operation to fail in apparently valid use-cases like
   
systemctl edit getty@.service
   
   This is fixed in git now, thanks!
   
or
systemctl edit autovt@tty1.service
   
In second case, the error message is especially cryptic:
autovt@tty1.service ignored: not found.
   
   It worked before and it still works for me.
  
  Do you have getty@tty1.service explicity enabled? I do have.
  
Actually I understand what it does mean: systemctl asks the manager to 
show
unit's FragmentPath - the manager tries to load the unit - loading 
fails with
File exists because getty@tty1.service is already instantiated.
   
   I don't see why it should fail for this reason ?
   
   
(BTW, it's a separate question: is this failure valid or is it a bug?)
   
   
   systemctl edit getty@.service, should have worked before so yes this was 
   a bug.
  
  Now both `edit getty@` and `edit getty@tty1` work, but I'd expect the latter
  to honor the template parameter; i. e. create a drop-in for 
  getty@tty1.service...
  Is this possible?
 I made various unifications to the code to make it more maintainable. This
 case should be fixed too. Please test it... it's easy to miss the corner 
 cases.

Yes, that works now, thanks! Also the error messages are now a lot cleaner
and more in line with the rest of systemctl.

I still can't edit autovt@tty1.service (other instances work correctly), but
I guess that's another problem. However, the error message could be improved
by querying the manager for LoadFailed and displaying that message instead
of just saying does not have any files on disk. I'll try to come up with a 
patch
for that.

BTW, would it be good to have a LoadFailedErrno property or something in that 
line
to get an errno instead of a string? Or is it better to convert string to errno
using sd_bus_error_*() methods?

I'm sorry for too many questions :P

Thanks,
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Using `systemctl edit` on invalid unit names

2014-12-13 Thread Ivan Shapovalov
Hello all,

it seems that the newly added `systemctl edit` command requires its arguments
to be valid unit names.

This causes `edit` operation to fail in apparently valid use-cases like

systemctl edit getty@.service
or
systemctl edit autovt@tty1.service

In second case, the error message is especially cryptic:
autovt@tty1.service ignored: not found.

Actually I understand what it does mean: systemctl asks the manager to show
unit's FragmentPath - the manager tries to load the unit - loading fails with
File exists because getty@tty1.service is already instantiated.

(BTW, it's a separate question: is this failure valid or is it a bug?)

But well. I guess that `edit` operation should always work with unit files
directly, just like enable/disable commands do.

Is this all correct? Can anyone please comment on these two issues?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

2014-12-09 Thread Ivan Shapovalov
On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:  
 Hello Lennart,
 
 Thanks for answering !
 
 On 12/09/2014 02:10 PM, Lennart Poettering wrote:
  On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:
  
  Hello,
 
  I've a very weird behaviour with systemd 217:
 
  # systemctl show -p Wants multi-user.target | grep network.service
  # systemctl show -p Wants runlevel3.target | grep network.service
  Wants= ... network.service ...
  # systemctl show -p Wants multi-user.target | grep network.service
  Wants=... network.service ...
 
  So basically the network.service is not part of the multi-user target
  dependencies. But if I'm showing the state of the runlevel3 target, the
  network service magically becomes a dep of multi-user.target.
 
  The network.service is an sysv service which is started by rc[345].d and
  has in its LSB:
 
  Provide: $network
 
  Could anybody clarify what I'm facing ?
  
  systemd lazy loads services from the file system as they are
  referenced. This includes symlinked aliases, which are only loaded when
  a unit is referenced by that specific name.
  
 
 Sorry but I don't really understand.
 
 Do you mean that the network.service wasn't loaded although the
 runlevel3.target, which is an alias for multi-user target (default
 target) wants it ?
 
 I would be glad if you could enlight me because I'm confused.

Apparently, network.service gets pulled in only via runlevel3.target, i. e.
there is a symlink of kind

/{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service - 
network.service

That is, the Wants= dependency is generated for runlevel3.target only, not for
multi-user.target.

And, because systemd loads units lazily, systemd does not know about 
runlevel3.target
(and its dependencies) before anything forces systemd to load that unit.

After you issue `systemctl show runlevel3.target`, systemd loads that unit,
loads its dependencies and merges them to multi-user.target (because 
runlevel3.target
is an alias for multi-user.target).

HTHs,
-- 
Ivan Shapovalov / intelfx /

 
  Also it appears that runlevel3 target is an alias for multi-user one.
  Could anybody where this alias is done ? If that's in the source code of
  systemd I would be curious to see where exactly.
  
  The /usr/lib/systemd/system/runlevel[0-5].target symlinks create these
  alias names.
  
 
 I see now.
 
 Thanks.


signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] a way to limit restarts?

2014-12-09 Thread Ivan Shapovalov
On Tuesday 09 December 2014 at 13:11:41, Nekrasov, Alexander wrote: 
 Totally missed those. Thanks. Will OnFailure= be activated when the limit is 
 hit? The manual only directly describes StartLimitAction= which isn’t exactly 
 what’s required

OnFailure= will be activated each time the unit enters failed state, i. e.
at the same time it is restarted.

There is apparently no way to start a special unit when the start limit is 
reached.
However, I may have missed it as well...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Option fail mentioned in systemd.mount(5)

2014-12-04 Thread Ivan Shapovalov
Hi all,

The systemd.mount(5) man page mentions an inexistent mount option fail in the
following context:

nofail, fail
With nofail this mount will be only wanted, not required, by the
local-fs.target. This means that the boot will continue even if this
mount point is not mounted successfully. Option fail has the opposite
meaning and is the default.

Specifying the option fail in fstab produces following message in the log:

kernel: EXT4-fs (sdc1): Unrecognized mount option fail or missing value

So the man page contradicts actual behavior. Should this statement be removed,
or what?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] rules: rerun vconsole-setup when switching from vgacon to fbcon

2014-12-01 Thread Ivan Shapovalov
On Friday 07 November 2014 at 16:45:02, Lennart Poettering wrote:   
 On Fri, 07.11.14 17:45, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  On Thursday 06 November 2014 at 11:02:44, David Herrmann wrote: 
   Hi Ray
   
   On Thu, Nov 6, 2014 at 10:40 AM, David Herrmann dh.herrm...@gmail.com 
   wrote:
On Wed, Nov 5, 2014 at 4:11 PM, Ray Strode halfl...@gmail.com wrote:
So if you have no idea how to make that rule be generated only if
ENABLE_VCONSOLE is set by configure, then we probably should take my
patch below.
Your patch seems far better than the options above, but I think it
needs a dracut patch to make sure the new rules file gets in the
initrd too, or it won't work.
   
I will push the patch to systemd and let Harald know. I'm not really
familiar with dracut..
   
   Pushed.
  
  Isn't it ugly to re-runn systemd-vconsole-setup straight from an udev rule?
  I mean, udev has a tendency to kill long-running RUN processes, and I've 
  seen
  systemd-vconsole-setup.service to take 5 seconds on some systems...
  Also, these additional systemd-vconsole-setup instances aren't supervised by
  systemd...
 
 Is systemd-vconsole-setup really long-running? Why would it need that
 long?
 
 To me it appears to be quite OK to be run inside a udev rule.

Well, maybe it is OK to be run from an udev rule, but it is still an
inconsistency between running that binary on boot (via a unit) and
running the same binary when a framebuffer console is added (directly)...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] unit-name: fix escaping logic in unit_name_mangle_with_suffix().

2014-11-25 Thread Ivan Shapovalov
Make screened character set consistent with unit_name_mangle() by splitting off
the escaping loop into a separate function.

Before this fix, unit names such as `foo@bar.target` would get transformed
into `foo\x40bar.target` when unit_name_mangle_with_suffix() is used.

https://bugs.freedesktop.org/show_bug.cgi?id=86711
---
 src/shared/unit-name.c | 51 +-
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/src/shared/unit-name.c b/src/shared/unit-name.c
index 2ef8545..6c6d7f4 100644
--- a/src/shared/unit-name.c
+++ b/src/shared/unit-name.c
@@ -243,6 +243,30 @@ static char *do_escape(const char *f, char *t) {
 return t;
 }
 
+static char *do_escape_mangle(const char *f, enum unit_name_mangle 
allow_globs, char *t) {
+const char *valid_chars;
+
+assert(f);
+assert(IN_SET(allow_globs, MANGLE_GLOB, MANGLE_NOGLOB));
+assert(t);
+
+/* We'll only escape the obvious characters here, to play
+ * safe. */
+
+valid_chars = allow_globs == MANGLE_GLOB ? @ VALID_CHARS []!-*? : 
@ VALID_CHARS;
+
+for (; *f; f++) {
+if (*f == '/')
+*(t++) = '-';
+else if (!strchr(valid_chars, *f))
+t = do_escape_char(*f, t);
+else
+*(t++) = *f;
+}
+
+return t;
+}
+
 char *unit_name_escape(const char *f) {
 char *r, *t;
 
@@ -482,11 +506,9 @@ int unit_name_from_dbus_path(const char *path, char 
**name) {
  *  sensible unit name.
  */
 char *unit_name_mangle(const char *name, enum unit_name_mangle allow_globs) {
-const char *valid_chars, *f;
 char *r, *t;
 
 assert(name);
-assert(IN_SET(allow_globs, MANGLE_GLOB, MANGLE_NOGLOB));
 
 if (is_device_path(name))
 return unit_name_from_path(name, .device);
@@ -494,23 +516,11 @@ char *unit_name_mangle(const char *name, enum 
unit_name_mangle allow_globs) {
 if (path_is_absolute(name))
 return unit_name_from_path(name, .mount);
 
-/* We'll only escape the obvious characters here, to play
- * safe. */
-
-valid_chars = allow_globs == MANGLE_GLOB ? @ VALID_CHARS []!-*? : 
@ VALID_CHARS;
-
 r = new(char, strlen(name) * 4 + strlen(.service) + 1);
 if (!r)
 return NULL;
 
-for (f = name, t = r; *f; f++) {
-if (*f == '/')
-*(t++) = '-';
-else if (!strchr(valid_chars, *f))
-t = do_escape_char(*f, t);
-else
-*(t++) = *f;
-}
+t = do_escape_mangle(name, allow_globs, r);
 
 if (unit_name_to_type(name)  0)
 strcpy(t, .service);
@@ -526,10 +536,8 @@ char *unit_name_mangle(const char *name, enum 
unit_name_mangle allow_globs) {
  */
 char *unit_name_mangle_with_suffix(const char *name, enum unit_name_mangle 
allow_globs, const char *suffix) {
 char *r, *t;
-const char *f;
 
 assert(name);
-assert(IN_SET(allow_globs, MANGLE_GLOB, MANGLE_NOGLOB));
 assert(suffix);
 assert(suffix[0] == '.');
 
@@ -537,14 +545,7 @@ char *unit_name_mangle_with_suffix(const char *name, enum 
unit_name_mangle allow
 if (!r)
 return NULL;
 
-for (f = name, t = r; *f; f++) {
-if (*f == '/')
-*(t++) = '-';
-else if (!strchr(VALID_CHARS, *f))
-t = do_escape_char(*f, t);
-else
-*(t++) = *f;
-}
+t = do_escape_mangle(name, allow_globs, r);
 
 if (!endswith(name, suffix))
 strcpy(t, suffix);
-- 
2.1.3

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


Re: [systemd-devel] remote-fs ordering, iSCSI and _netdev

2014-11-09 Thread Ivan Shapovalov
On Tuesday 28 October 2014 at 06:41:32, Andrei Borzenkov wrote: 
 В Mon, 27 Oct 2014 14:10:47 -0700
 Chris Leech cle...@redhat.com пишет:
 
  
  At boot fstab-generator is picking up on the _netdev option in fstab,
  and the generated mount units are ordered against remote-fs properly.
  If I leave a filesystem mounted at shutdown, it will be unmounted before
  the iSCSI session is destroyed or the network is shut down and
  everything works as expected.
  
  But there are two cases that are problematic, adding entries to fstab at
  runtime and manually mounting without adding to fstab (while still using
  the _netdev option, some hint is needed).  The first case actually ends
  up being the second, with the possible work-around of always remembering
  to run a daemon-reload after editing fstab to run fstab-generator again.
 
 
 Even known network filesystems still have a problem. If network
 filesystem is mounted on boot, it pulls in network-online.target which
 (hopefully) serves as synchronization point on shutdown. If there is no
 network filesystem to mount at boot, network-online.target is not
 started. If you mount NFS manually later there is nothing to wait for
 on shutdown so network could be teared down before filesystem is
 unmounted.

Isn't this (unmount before teardown) achieved by After=network.target? That
target is passive, so it is pulled in by a provider, and all should work
even in case of manually mounted filesystems.

Am I wrong somewhere?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] rules: rerun vconsole-setup when switching from vgacon to fbcon

2014-11-07 Thread Ivan Shapovalov
On Thursday 06 November 2014 at 11:02:44, David Herrmann wrote: 
 Hi Ray
 
 On Thu, Nov 6, 2014 at 10:40 AM, David Herrmann dh.herrm...@gmail.com wrote:
  On Wed, Nov 5, 2014 at 4:11 PM, Ray Strode halfl...@gmail.com wrote:
  So if you have no idea how to make that rule be generated only if
  ENABLE_VCONSOLE is set by configure, then we probably should take my
  patch below.
  Your patch seems far better than the options above, but I think it
  needs a dracut patch to make sure the new rules file gets in the
  initrd too, or it won't work.
 
  I will push the patch to systemd and let Harald know. I'm not really
  familiar with dracut..
 
 Pushed.

Isn't it ugly to re-runn systemd-vconsole-setup straight from an udev rule?
I mean, udev has a tendency to kill long-running RUN processes, and I've seen
systemd-vconsole-setup.service to take 5 seconds on some systems...
Also, these additional systemd-vconsole-setup instances aren't supervised by
systemd...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd and power management

2014-10-29 Thread Ivan Shapovalov
On Wednesday 29 October 2014 at 13:00:42, Daniel Hollocher wrote:   
 Hey folks,
 I'm a not expert here, so please forgive the low quality/interest of my
 question.
 
 I'm curious what the ideal systemd way is to set various power management
 settings in the /sys tree.  For me personally, I'm looking to set
 sampling_down_factor as without it, ondemand has terrible performance on my
 particular computer (a 10-30% loss compared to performance or conservative).
 
 Currently, Ubuntu uses a sysv init script to set ondemand after boot, and I
 could edit that.  It would be cool to know the ideal systemd way, that
 could also be aware of power saving stuff.
 
 From googling, it seems that tempfiles or sysctrl is not the way to go,
 since those only happen at boot.  Udev?  The examples I've found seem to
 make basic usage of udev to detect power changes, and then drop to a script
 to do the bulk of the work.  Is that it?

You could write a bunch of units pulled in by a target... well, two targets,
one for power-saving and second for performance mode. And then just start the
targets from an udev rule. Just remember to use `--no-block` as udev kills
workers after some time.

I've already done something along these lines for my own purposes, see
https://github.com/intelfx/power-management

However, I still want to know if I this is OK wrt systemd spirit.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] man: fix typos in description of SELinuxContextFromNet=

2014-10-27 Thread Ivan Shapovalov
---
 man/systemd.socket.xml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index ce04b0b..57f769f 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -678,7 +678,7 @@
 varlistentry
   
termvarnameSELinuxContextFromNet=/varname/term
  listitemparaTakes a boolean
- argument. When true systemd will attempt
+ argument. When true, systemd will attempt
  to figure out the SELinux label used
  for the instantiated service from the
  information handed by the peer over the
@@ -688,9 +688,9 @@
  the resulting SELinux context originate
  from either the target binary that is
  effectively triggered by socket unit
- are taken from the value of the
+ or from the value of the
  varnameSELinuxContext=/varname
- option.This configuration option only
+ option. This configuration option only
  affects sockets with
  varnameAccept=/varname mode set to
  literaltrue/literal. Also note that
-- 
2.1.2

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


Re: [systemd-devel] [PATCH] Bootchart: allow parse LABEL, UUID, PARTUUID for svg info

2014-10-27 Thread Ivan Shapovalov
On Tuesday 28 October 2014 at 03:30:13, Timofey Titovets wrote: 
 Good time of day, list.
 I try to fix Fixme in svg.c:
 /* FIXME: this works only in the simple case */
 
 By default function try to get root=/dev/*
 I write small function to determine block device name by specified 
 LABEL, UUID, PARTUUID.
 
 Please check code, its working, but i think it can look more pretty.
 May be i missed(reimplemented) some internal functional of systemd?
 
 [...]

Hi,

there is at least function fstab_node_to_udev_node() in shared/util.c
which converts TAG=value to /dev/disk/by-tag/value,
and also function canonicalize_file_name() in glibc which resolves
symlinks and (hopefully) returns /dev/sdXY.

I'm not the one to judge, but your code seems pretty messy, esp. with
extensive use of magic constants and numbers...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd in initramfs: /etc/passwd, /etc/group, emergency.service and sulogin

2014-10-24 Thread Ivan Shapovalov
Hi,

A few questions regarding usage of systemd+udev in initramfs. Before all,
this is what I want to achieve (to prevent XY-problems): working
emergency.service in initramfs.

The questions are a bit Arch-specific and possibly lame, but well...

- is /etc/passwd still[1] needed in initramfs due to libdbus1?
- how to pass '--resolve-names=never' to udevd in initramfs, will it work this
  way and will it allow to exclude /etc/group[2] from initramfs?
- is it possible to use 'sulogin -e' instead of 'sulogin'[3] security-wise?

[1]: 
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/initcpio-install-systemd?h=packages/systemd#n141
[2]: 
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/initcpio-install-systemd?h=packages/systemd#n147
[3]: 
http://cgit.freedesktop.org/systemd/systemd/tree/units/emergency.service.in#n21

Thanks,
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] rpcbind static, want enabled

2014-10-24 Thread Ivan Shapovalov
On Thursday 23 October 2014 at 16:19:28, Felix Miata wrote: 

[cut]
 
 Those are not things I know how or wish to pursue. I found a workaround, no 
 thanks
 to the systemctl 216-10.fc22 man page, which says:
 
   enable NAME...
 
 Enable one or more unit files or unit file instances, as specified on the 
 command line
 
 That's invalid WRT rpcbind. In order to enable rpcbind I found the following
 produces satisfactory results:
 
   systemctl add-wants multi-user.target rpcbind
 
 The question remains how and why 13 of 26 (I miscounted in my original thread 
 post)
 installations were set to static instead of enabled in the first place, and 
 whether
 the workaround amounts to an optimal solution.

Because rpcbind.service is designed by the upstream to be static, not 
enabled.
It is designed to be socket-activatable and so it should not be enabled in the
sense of unconditionally started on boot. The man-page isn't wrong or invalid.

What you are experiencing seems to be a bug in rpcbind and/or statd, and what 
you
have done is a workaround. If you have done this, then you should also disable
rpcbind.socket and make sure everything that needs rpcbind is ordered after
rpcbind.service.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

2014-10-23 Thread Ivan Shapovalov
On Thursday 23 October 2014 at 07:06:18, Mantas Mikulėnas wrote:
 On Oct 23, 2014 1:54 AM, Lennart Poettering lenn...@poettering.net
 wrote:
 
  On Wed, 22.10.14 12:44, Damien Robert (
 damien.olivier.robert+gm...@gmail.com) wrote:
 
  [...]
 
  policykit really should get fixed there. it shouldn't try to do access
  control for individual sessions but for users on specific
  sessions.
 
 Wasn't this already fixed in polkit.git recently?

Oh, if this indeed was, then... does it mean that the last significant
blocker for widely using `systemd --user` has gone away?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-cron: retrigger generator after /var is mounted

2014-10-22 Thread Ivan Shapovalov
On Wednesday 22 October 2014 at 10:26:49, Jóhann B. Guðmundsson wrote:  
 
 On 10/22/2014 09:44 AM, Lennart Poettering wrote:
  So, I thought myself a couple of times about adding a cron generator
  upstream
 
 As far as I can tell generators serve only one purpose and that is to 
 bridge an gap to allow users of consumers of systemd to migrate to it's 
 native format

I don't think this is correct. Take, for example, gpt-auto-generator,
efi-boot-generator, hibernate-resume-generator...

Also, systemd.mount(5) page states: In general, configuring mount points
through /etc/fstab is the preferred approach.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Timers without matching units?

2014-10-22 Thread Ivan Shapovalov
Hi,

The systemd.timer(5) manpage states:

For each timer file, a matching unit file must exist, describing the unit to
activate when the timer elapses.

However, if I need the timer unit just to wake up the machine (e. g. I have a
GUI alarm which does everything except configuring the wakealarm), I don't
need the timer unit to start something else. Does this sound like a valid
reason to make timers' Unit= optional?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Unicode support in console after boot

2014-10-21 Thread Ivan Shapovalov
On Tuesday 21 October 2014 at 19:03:17, Michal Sekletar wrote:  
 On Tue, Oct 14, 2014 at 09:04:56AM +0200, Jan Synacek wrote:
  Michal Sekletar msekl...@redhat.com writes:
   On Mon, Oct 13, 2014 at 09:36:16AM +0200, Jan Synacek wrote:
   Hello,
   
   currently, unicode characters are not correctly displayed in the
   console. After login, when I run /usr/bin/unicode_start, unicode works
   fine. I tried to create a service file that runs this script, linking
   tty to stdout and stderr, but that didn't work. Is there a way how to
   turn on unicode support in console after boot using a service file? Or
   any other type of unit? Or is this something that has to be patched in
   the source (logind perhaps?)?
  
   Please try editing /usr/lib/systemd/system/systemd-vconsole-setup.service 
   and
   remove RemainAfterExit=yes, then regenerate your initramfs image by 
   running
   dracut command. Add back RemainAfterExit=yes to service file. Reboot.
  
  Yep, this helped. Could you please explain why? Also, I believe this
  should be fixed in all Fedora versions.
 
 I must admit I'm not sure why this workaround works. Maybe there is some race
 condition with some kernel initialization or settings get unapplied because of
 switch-root.
 
 Also, if we go with workaround in Fedora I think dracut needs to fixed to
 include version on unit file *without* RemainAfterExit=yes.

IIUC, this makes unit to be re-run outside of initramfs, so the VT is set up 
twice,
second time after switching the framebuffer driver.

And the latter condition is not mandated by anything, it's just a coincidence...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Unicode support in console after boot

2014-10-21 Thread Ivan Shapovalov
On Tuesday 21 October 2014 at 21:57:09, Michal Sekletar wrote:  
 On Tue, Oct 21, 2014 at 09:39:46PM +0400, Ivan Shapovalov wrote:
  On Tuesday 21 October 2014 at 19:03:17, Michal Sekletar wrote:  
   On Tue, Oct 14, 2014 at 09:04:56AM +0200, Jan Synacek wrote:
Michal Sekletar msekl...@redhat.com writes:
 On Mon, Oct 13, 2014 at 09:36:16AM +0200, Jan Synacek wrote:
 Hello,
 
 currently, unicode characters are not correctly displayed in the
 console. After login, when I run /usr/bin/unicode_start, unicode 
 works
 fine. I tried to create a service file that runs this script, linking
 tty to stdout and stderr, but that didn't work. Is there a way how to
 turn on unicode support in console after boot using a service file? 
 Or
 any other type of unit? Or is this something that has to be patched 
 in
 the source (logind perhaps?)?

 Please try editing 
 /usr/lib/systemd/system/systemd-vconsole-setup.service and
 remove RemainAfterExit=yes, then regenerate your initramfs image by 
 running
 dracut command. Add back RemainAfterExit=yes to service file. Reboot.

Yep, this helped. Could you please explain why? Also, I believe this
should be fixed in all Fedora versions.
   
   I must admit I'm not sure why this workaround works. Maybe there is some 
   race
   condition with some kernel initialization or settings get unapplied 
   because of
   switch-root.
   
   Also, if we go with workaround in Fedora I think dracut needs to fixed to
   include version on unit file *without* RemainAfterExit=yes.
  
  IIUC, this makes unit to be re-run outside of initramfs, so the VT is set 
  up twice,
  second time after switching the framebuffer driver.
  
  And the latter condition is not mandated by anything, it's just a
  coincidence...
 
 I guess that what you are saying pretty much summarizes the situation here. 
 Can
 we make something about framebuffer driver, thus settings applied in initramfs
 are not thrashed?

I don't know if there is a valid solution. Maybe someone familiar with the VT
subsystem knows...

Personally I've worked around this problem as follows: the fb driver
(i915) is included into the initramfs, while systemd-vconsole-setup is ran
only in the real root.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH v2] udev hwdb: Support shipping pre-compiled database in system images

2014-10-19 Thread Ivan Shapovalov
On Sunday 19 October 2014 at 05:42:28, Ivan Shapovalov wrote:   
 On Friday 17 October 2014 at 15:44:51, Martin Pitt wrote: 
  Hello again,
  
  the previous patch had a typo in the manpage (it said /lib/udev
  instead of /usr/lib/udev at one place), and also forgot to adjust
  systemd-udev-hwdb-update.service.in. Both done now.
  
  However, the latter currently has a gotcha:
  
+ConditionPathExists=!@udevlibexecdir@/hwdb.bin
  
  This works correctly if you use this with the factory reset
  semantics, i. e. start with an empty /etc. But it would not work if
  you update /usr and have an already existing /etc/udev/hwdb.d/*. So
  ideally the condition would be
  
ConditionPathExists=!@udevlibexecdir@/hwdb.bin OR
ConditionDirectoryNotEmpty=/etc/udev/hwdb.d/
 
  
  but this isn't possible AFAIK. The alternative would be to change the
  Exec= to call hdwb --update --vendor iff /etc/udev/hwdb.d/ is empty.
 
 I'm just an innocent bystander, but isn't it possible with these two
 lines?
 
 ConditionPathExists=|!@udevlibexecdir@/hwdb.bin
 ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d/
 
 This will succeed if EITHER @udevlibexecdir@/hwdb.bin does not exist
 OR /etc/udev/hwdb.d/ is not empty.
 
 Or have I misunderstood you?

Ugh, I haven't seen your second message. There's something strange with
mail delivery -- I could swear that I've fetched everything before replying...

Sorry for the noise.
-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH v2] udev hwdb: Support shipping pre-compiled database in system images

2014-10-18 Thread Ivan Shapovalov
On Friday 17 October 2014 at 15:44:51, Martin Pitt wrote:   
 Hello again,
 
 the previous patch had a typo in the manpage (it said /lib/udev
 instead of /usr/lib/udev at one place), and also forgot to adjust
 systemd-udev-hwdb-update.service.in. Both done now.
 
 However, the latter currently has a gotcha:
 
   +ConditionPathExists=!@udevlibexecdir@/hwdb.bin
 
 This works correctly if you use this with the factory reset
 semantics, i. e. start with an empty /etc. But it would not work if
 you update /usr and have an already existing /etc/udev/hwdb.d/*. So
 ideally the condition would be
 
   ConditionPathExists=!@udevlibexecdir@/hwdb.bin OR
   ConditionDirectoryNotEmpty=/etc/udev/hwdb.d/

 
 but this isn't possible AFAIK. The alternative would be to change the
 Exec= to call hdwb --update --vendor iff /etc/udev/hwdb.d/ is empty.

I'm just an innocent bystander, but isn't it possible with these two
lines?

ConditionPathExists=|!@udevlibexecdir@/hwdb.bin
ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d/

This will succeed if EITHER @udevlibexecdir@/hwdb.bin does not exist
OR /etc/udev/hwdb.d/ is not empty.

Or have I misunderstood you?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Unicode support in console after boot

2014-10-13 Thread Ivan Shapovalov
On Monday 13 October 2014 at 15:36:00, Zbigniew Jędrzejewski-Szmek wrote:   
 On Mon, Oct 13, 2014 at 03:13:50PM +0200, Jan Synacek wrote:
  Andrei Borzenkov arvidj...@gmail.com writes:
   [...]
  
   Does booting with plymouth.enable=0 change anything?
  
  Nope, that doesn't help. After loadkeys cz, I still see white
  rectangles instead of proper characters.
 Could be a kernel bug too, don't rule this out. IIRC, some settings do
 not get propagated from the foreground console to other consoles, or they
 get reset at some point, or something like that (should be the ML archives).

It is also possible that settings get reset after the framebuffer driver is 
changed
(e. g. i915 module is loaded)... BTW, I'm still seeking for a correct method to
handle this.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] journalctl: allow customizable output formats

2014-09-22 Thread Ivan Shapovalov
On Monday 22 September 2014 at 12:43:28, Daurnimator wrote: 
 On 22 September 2014 11:33, Daniel P. Berrange berra...@redhat.com wrote:
 
  The current '--output FORMAT' argument defines a number of
  common output formats, but there are some useful cases it
  does cover. In particular when reading application logs it
  is often desirable to display the code file name, line number
  and function name. Rather than defining yet more fixed output
  formats, this patch introduces user defined output formats.
 
  The format string is an arbitrary string which contains a
  mixture of literal text and variable subsistitions. Each
  variable name corresponds to a journal field name. A variable
  name can be optionally followed by a data type, and in the
  case of string types, a length limit.
 
 
 As an opposing point of view, I've been accomplishing this by piping output
 through a script that parses and displays JSON.
 I rather this style of composability than passing format strings to
 journalctl itself.

I think that using dedicated ad-hoc JSON parser for customizing output
is an overkill. For that matter, Git has support for custom output format
in its log command, and I've found it useful many times.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] build-sys: make hibernation support configure option also handle hybrid-sleep; fix indentation

2014-09-11 Thread Ivan Shapovalov
On Tuesday 09 September 2014 at 01:40:51, Ivan Shapovalov wrote:
 ---
 The patch by Umut did miss at least hybrid-sleep -- it involves hibernation
 as well (hybrid sleep is a hibernation followed by S3 rather than S4 
 powerdown).
 
 Also, it messed up indentation a bit (Makefile.am seems to use tabs), which I
 fixed as well.
 
 And I wonder, maybe it makes sense to conditionalize sleep (suspend) support 
 as well
 as hibernation? Or are there use-cases when suspend is possible, but not 
 hibernation?
 
  Makefile.am | 27 +--
  1 file changed, 13 insertions(+), 14 deletions(-)
 
 diff --git a/Makefile.am b/Makefile.am
 [...]

Ping.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] build-sys: make hibernation support configure option also handle hybrid-sleep; fix indentation

2014-09-08 Thread Ivan Shapovalov
---
The patch by Umut did miss at least hybrid-sleep -- it involves hibernation
as well (hybrid sleep is a hibernation followed by S3 rather than S4 powerdown).

Also, it messed up indentation a bit (Makefile.am seems to use tabs), which I
fixed as well.

And I wonder, maybe it makes sense to conditionalize sleep (suspend) support as 
well
as hibernation? Or are there use-cases when suspend is possible, but not 
hibernation?

 Makefile.am | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 35c877f..de40043 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -459,7 +459,6 @@ dist_systemunit_DATA = \
units/network-online.target \
units/nss-lookup.target \
units/nss-user-lookup.target \
-   units/hybrid-sleep.target \
units/poweroff.target \
units/reboot.target \
units/rescue.target \
@@ -523,7 +522,6 @@ nodist_systemunit_DATA = \
units/emergency.service \
units/rescue.service \
units/user@.service \
-   units/systemd-hybrid-sleep.service \
units/systemd-suspend.service \
units/systemd-halt.service \
units/systemd-poweroff.service \
@@ -579,7 +577,6 @@ EXTRA_DIST += \
units/systemd-fsck-root.service.in \
units/u...@.service.in \
units/debug-shell.service.in \
-   units/systemd-hybrid-sleep.service.in \
units/systemd-suspend.service.in \
units/quotaon.service.in \
units/initrd-parse-etc.service.in \
@@ -2159,17 +2156,17 @@ systemd_system_update_generator_LDADD = \
 # 
--
 if ENABLE_HIBERNATE
 systemgenerator_PROGRAMS += \
-systemd-hibernate-resume-generator
+   systemd-hibernate-resume-generator
 
 rootlibexec_PROGRAMS += \
-systemd-hibernate-resume
+   systemd-hibernate-resume
 
 systemd_hibernate_resume_SOURCES = \
-src/hibernate-resume/hibernate-resume.c
+   src/hibernate-resume/hibernate-resume.c
 
 systemd_hibernate_resume_LDADD = \
-libsystemd-internal.la \
-libsystemd-shared.la
+   libsystemd-internal.la \
+   libsystemd-shared.la
 
 systemd_hibernate_resume_generator_SOURCES = \
src/hibernate-resume/hibernate-resume-generator.c
@@ -2179,16 +2176,18 @@ systemd_hibernate_resume_generator_LDADD = \
libsystemd-shared.la
 
 EXTRA_DIST += \
-units/systemd-hibernate.service.in \
-units/systemd-hibernate-res...@.service.in
+   units/systemd-hibernate.service.in \
+   units/systemd-hibernate-res...@.service.in \
+   units/systemd-hybrid-sleep.service.in
 
 dist_systemunit_DATA += \
-units/hibernate.target
+   units/hibernate.target \
+   units/hybrid-sleep.target
 
 nodist_systemunit_DATA += \
-units/systemd-hibernate.service \
-units/systemd-hibernate-resume@.service
-
+   units/systemd-hibernate.service \
+   units/systemd-hibernate-resume@.service \
+   units/systemd-hybrid-sleep.service
 endif
 
 # 
--
-- 
2.1.0

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


Re: [systemd-devel] [PATCH] build: configure option to disable hibernation

2014-09-07 Thread Ivan Shapovalov
On Tuesday 02 September 2014 at 12:31:49, Umut Tezduyar Lindskog wrote: 
 ---
  Makefile.am  |   52 
  configure.ac |6 ++
  2 files changed, 38 insertions(+), 20 deletions(-)

Hi,

thanks for doing this (I'm very unfamiliar with autotools).

However, I think that the name you've picked for the switch (and commit msg) is
too broad. We're configuring support for hibernation resume, not hibernation 
itself.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

2014-08-28 Thread Ivan Shapovalov
On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote:  
 Ivan Shapovalov intelfx100 at gmail.com writes:
 
  
  On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: 
   On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:
On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) 
wrote:
 This patchset allows systemd to parse resume= kernel command line
 parameter
 and initiate resume from the specified device.
   What about swap files with the resume_offset= parameter? Are they still
   being used?
  
  I don't know if somebody uses that, but for now it's missing functionality.
  
  After a cursory search, I could not find a mechanism to initiate a resume 
  with
  offset from userspace. In Arch, it was never implemented even if possible.
  
 
 I'm a heavy user of this myself. It's especially useful because you can just
 have a single luks encrypted ext4 without a lvm in between for a swap
 partition or (even more yuck) using a separate (encrypted) swap partition.
 
 Arch does support this, mostly because as far as I know, the resume_offset=
 is consumed by the kernel, while resume= has to refer to the (unencrypted)
 filesystem (/dev/mapper/root in my case). So, as long as this solution waits
 for the device to show up in /dev/ (and especially /dev/mapper/ for my
 case), this should work out.
 
 Here's information to set this up. Imho more people should be aware this is
 possible:
 https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file
 
 Jan

Hmm, so is resume_offset= parsed independently of resume=? If that's the
case, and resume_offset= can be parsed by kernel while resume= is parsed
by userspace, then yes, I was wrong and this should work.

Actually, it should work _just like before_, sans tuxonice support.

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv6 2/3] hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume.

2014-08-27 Thread Ivan Shapovalov
On Wednesday 27 August 2014 at 08:18:38, Thomas Bächler wrote:  
 Am 26.08.2014 um 22:17 schrieb Ivan Shapovalov:
  This can be used to initiate a resume from hibernation by path to a swap
  device containing the hibernation image.
  
  The respective templated unit is also added. It is instantiated using
  path to the desired resume device.
 
 Really great stuff, this was really missing from systemd initrd. I only
 saw this because of your posting to the arch-projects list, so I am late
 to the party. Anyway, although this is commited to systemd.git, there's
 no reason it can't still be improved.
 
  diff --git a/units/systemd-hibernate-res...@.service.in 
  b/units/systemd-hibernate-res...@.service.in
  new file mode 100644
  index 000..6db584d
  --- /dev/null
  +++ b/units/systemd-hibernate-res...@.service.in
  @@ -0,0 +1,20 @@
  +#  This file is part of systemd.
  +#
  +#  systemd is free software; you can redistribute it and/or modify it
  +#  under the terms of the GNU Lesser General Public License as published by
  +#  the Free Software Foundation; either version 2.1 of the License, or
  +#  (at your option) any later version.
  +
  +[Unit]
  +Description=Resume from hibernation using device %f
  +Documentation=man:systemd-hibernate-resume@.service(8)
  +DefaultDependencies=no
  +BindsTo=%i.device
 
 What's the purpose of BindsTo= as opposed to Requires= here. They are
 both the same for a oneshot service, but the former is more confusing.

This is just because systemd-fsck@.service does the same. Seems like it's
the established usage, as Andrei says.

 
  +Wants=local-fs-pre.target
  +After=%i.device
  +Before=local-fs-pre.target systemd-remount-fs.service 
  systemd-fsck-root.service
 
 The part of ordering this Before=local-fs-pre.target is so crucial, it
 can't be stressed enough. If _anything_ writes to _any_ file system
 before this service runs, your system is broken and your data is lost.
 That said, are you sure that all services are properly ordered against
 the target?

I've spent quite some time verifying this. The only thing not covered
is usr.mount (not sysroot-usr.mount), but Lennart says any configuration
with initramfs's /usr split off is broken.

(Yes, I assume that lvm2, mdadm/mdmon, dm-event and so on don't write
to filesystems. If I'm wrong -- this needs to be fixed...)

 
 What's the purpose of ordering this against systemd-fsck-root.service?
 This service is not run in initrd ever, because it checks
 'ConditionPathIsReadWrite=!/', which always fails in initrd.

Just a leftover, indeed. These services do not exist in initramfs.
They probably should be removed in a separate commit.

 
  +ConditionPathExists=/etc/initrd-release
 
 We should have and use ConditionInitrd=. I am surprised that this
 doesn't exist, but it really should.

Would you accept a patch adding that (using in_initrd()) and converting
all uses of ConditionPathExists=/etc/initrd-release to this new
condition statement?

Thanks for review!

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

2014-08-27 Thread Ivan Shapovalov
On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: 
 On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:
  On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx...@gmail.com) wrote:
   This patchset allows systemd to parse resume= kernel command line 
   parameter
   and initiate resume from the specified device.
 What about swap files with the resume_offset= parameter? Are they still
 being used?

I don't know if somebody uses that, but for now it's missing functionality.

After a cursory search, I could not find a mechanism to initiate a resume with
offset from userspace. In Arch, it was never implemented even if possible.

--
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 1/2] units: add ConditionInitrd=

2014-08-27 Thread Ivan Shapovalov
---
 man/systemd.unit.xml  | 13 +
 src/core/condition.c  | 17 +
 src/core/load-fragment-gperf.gperf.m4 |  1 +
 src/shared/condition-util.c   |  1 +
 src/shared/condition-util.h   |  1 +
 5 files changed, 33 insertions(+)

diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index c8d9300..4cd5201 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -919,6 +919,7 @@
 
termvarnameConditionACPower=/varname/term
 
termvarnameConditionNeedsUpdate=/varname/term
 
termvarnameConditionFirstBoot=/varname/term
+
termvarnameConditionInitrd=/varname/term
 
termvarnameConditionPathExists=/varname/term
 
termvarnameConditionPathExistsGlob=/varname/term
 
termvarnameConditionPathIsDirectory=/varname/term
@@ -1132,6 +1133,18 @@
 when a new system instances boots up
 for the first time./para
 
+paravarnameConditionInitrd=/varname
+may be used to check whether the root
+filesystem is an initramfs at the time
+of activation of the unit. It takes a
+boolean argument. If set to
+varnametrue/varname, the condition
+will hold only if the system runs from
+an initramfs. Conversely, if set to
+varnamefalse/varname, the condition
+will hold only if the system runs from
+the real root./para
+
 paraWith
 varnameConditionPathExists=/varname
 a file existence condition is
diff --git a/src/core/condition.c b/src/core/condition.c
index 353e0c9..6be3d58 100644
--- a/src/core/condition.c
+++ b/src/core/condition.c
@@ -134,6 +134,20 @@ static bool condition_test_first_boot(Condition *c) {
 return ((access(/run/systemd/first-boot, F_OK) = 0) == !!r) == 
!c-negate;
 }
 
+static bool condition_test_initrd(Condition *c) {
+int r;
+
+assert(c);
+assert(c-parameter);
+assert(c-type == CONDITION_INITRD);
+
+r = parse_boolean(c-parameter);
+if (r  0)
+return c-negate;
+
+return (in_initrd() == !!r) == !c-negate;
+}
+
 static bool condition_test(Condition *c) {
 assert(c);
 
@@ -219,6 +233,9 @@ static bool condition_test(Condition *c) {
 case CONDITION_FIRST_BOOT:
 return condition_test_first_boot(c);
 
+case CONDITION_INITRD:
+return condition_test_initrd(c);
+
 case CONDITION_NULL:
 return !c-negate;
 
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index 24aa80d..698f81f 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -170,6 +170,7 @@ Unit.ConditionSecurity,  
config_parse_unit_condition_string, CONDITION_S
 Unit.ConditionCapability,config_parse_unit_condition_string, 
CONDITION_CAPABILITY,  0
 Unit.ConditionHost,  config_parse_unit_condition_string, 
CONDITION_HOST,0
 Unit.ConditionACPower,   config_parse_unit_condition_string, 
CONDITION_AC_POWER,0
+Unit.ConditionInitrd,config_parse_unit_condition_string, 
CONDITION_INITRD,  0
 Unit.ConditionNull,  config_parse_unit_condition_null,   0,
 0
 m4_dnl
 Service.PIDFile, config_parse_unit_path_printf,  0,
 offsetof(Service, pid_file)
diff --git a/src/shared/condition-util.c b/src/shared/condition-util.c
index ff4a8ec..e5779ce 100644
--- a/src/shared/condition-util.c
+++ b/src/shared/condition-util.c
@@ -261,6 +261,7 @@ static const char* const 
condition_type_table[_CONDITION_TYPE_MAX] = {
 [CONDITION_ARCHITECTURE] = ConditionArchitecture,
 [CONDITION_NEEDS_UPDATE] = ConditionNeedsUpdate,
 [CONDITION_FIRST_BOOT] = ConditionFirstBoot,
+[CONDITION_INITRD] = ConditionInitrd,
 [CONDITION_NULL] = ConditionNull
 };
 
diff --git a/src/shared/condition-util.h b/src/shared/condition-util.h
index 047fdbf..a78fcd9 100644
--- a/src/shared/condition-util.h
+++ b/src/shared/condition-util.h
@@ -46,6 +46,7 @@ typedef enum ConditionType {
 CONDITION_ARCHITECTURE,
 CONDITION_NEEDS_UPDATE,
 CONDITION_FIRST_BOOT,
+CONDITION_INITRD,
 CONDITION_NULL,
 _CONDITION_TYPE_MAX,
 

[systemd-devel] [PATCH 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.

2014-08-27 Thread Ivan Shapovalov
This is as proposed by Thomas in review of my hibernate-resume patchset.

The objective benefit of this change is that in_initrd() function is used
for checking, which not only checks for /etc/initrd-release, but also verifies
that the rootfs is on a virtual device.

Ivan Shapovalov (2):
  units: add ConditionInitrd=
  units: use ConditionInitrd=true instead of 
ConditionPathExists=/etc/initrd-release

 man/systemd.unit.xml   | 13 +
 src/core/condition.c   | 17 +
 src/core/load-fragment-gperf.gperf.m4  |  1 +
 src/shared/condition-util.c|  1 +
 src/shared/condition-util.h|  1 +
 units/initrd-cleanup.service.in|  2 +-
 units/initrd-fs.target |  2 +-
 units/initrd-parse-etc.service.in  |  2 +-
 units/initrd-root-fs.target|  2 +-
 units/initrd-switch-root.service.in|  2 +-
 units/initrd-switch-root.target|  2 +-
 units/initrd-udevadm-cleanup-db.service.in |  2 +-
 units/initrd.target|  2 +-
 units/systemd-hibernate-res...@.service.in |  2 +-
 14 files changed, 42 insertions(+), 9 deletions(-)

-- 
2.1.0

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


[systemd-devel] [PATCH 2/2] units: use ConditionInitrd=true instead of ConditionPathExists=/etc/initrd-release

2014-08-27 Thread Ivan Shapovalov
---
 units/initrd-cleanup.service.in| 2 +-
 units/initrd-fs.target | 2 +-
 units/initrd-parse-etc.service.in  | 2 +-
 units/initrd-root-fs.target| 2 +-
 units/initrd-switch-root.service.in| 2 +-
 units/initrd-switch-root.target| 2 +-
 units/initrd-udevadm-cleanup-db.service.in | 2 +-
 units/initrd.target| 2 +-
 units/systemd-hibernate-res...@.service.in | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/units/initrd-cleanup.service.in b/units/initrd-cleanup.service.in
index b1dda16..833c59d 100644
--- a/units/initrd-cleanup.service.in
+++ b/units/initrd-cleanup.service.in
@@ -8,7 +8,7 @@
 [Unit]
 Description=Cleaning Up and Shutting Down Daemons
 DefaultDependencies=no
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
 After=initrd-root-fs.target initrd-fs.target initrd.target
diff --git a/units/initrd-fs.target b/units/initrd-fs.target
index 7ec838a..a02a3b4 100644
--- a/units/initrd-fs.target
+++ b/units/initrd-fs.target
@@ -10,7 +10,7 @@ Description=Initrd File Systems
 Documentation=man:systemd.special(7)
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 After=initrd-parse-etc.service
 DefaultDependencies=no
 Conflicts=shutdown.target
diff --git a/units/initrd-parse-etc.service.in 
b/units/initrd-parse-etc.service.in
index c0b2543..22fe8cc 100644
--- a/units/initrd-parse-etc.service.in
+++ b/units/initrd-parse-etc.service.in
@@ -12,7 +12,7 @@ Requires=initrd-root-fs.target
 After=initrd-root-fs.target
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 
 [Service]
 Type=oneshot
diff --git a/units/initrd-root-fs.target b/units/initrd-root-fs.target
index 64f0a92..cabba13 100644
--- a/units/initrd-root-fs.target
+++ b/units/initrd-root-fs.target
@@ -8,7 +8,7 @@
 [Unit]
 Description=Initrd Root File System
 Documentation=man:systemd.special(7)
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
 DefaultDependencies=no
diff --git a/units/initrd-switch-root.service.in 
b/units/initrd-switch-root.service.in
index 82893da..b4475aa 100644
--- a/units/initrd-switch-root.service.in
+++ b/units/initrd-switch-root.service.in
@@ -8,7 +8,7 @@
 [Unit]
 Description=Switch Root
 DefaultDependencies=no
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
 AllowIsolate=yes
diff --git a/units/initrd-switch-root.target b/units/initrd-switch-root.target
index f347687..fbee5c2 100644
--- a/units/initrd-switch-root.target
+++ b/units/initrd-switch-root.target
@@ -7,7 +7,7 @@
 
 [Unit]
 Description=Switch Root
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 DefaultDependencies=no
 Requires=initrd-switch-root.service
 Before=initrd-switch-root.service
diff --git a/units/initrd-udevadm-cleanup-db.service.in 
b/units/initrd-udevadm-cleanup-db.service.in
index 5c6654e..6b97425 100644
--- a/units/initrd-udevadm-cleanup-db.service.in
+++ b/units/initrd-udevadm-cleanup-db.service.in
@@ -8,7 +8,7 @@
 [Unit]
 Description=Cleanup udevd DB
 DefaultDependencies=no
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 Conflicts=systemd-udevd.service systemd-udevd-control.socket 
systemd-udevd-kernel.socket
 After=systemd-udevd.service systemd-udevd-control.socket 
systemd-udevd-kernel.socket
 Before=initrd-switch-root.target
diff --git a/units/initrd.target b/units/initrd.target
index eae7c70..81af69e 100644
--- a/units/initrd.target
+++ b/units/initrd.target
@@ -10,7 +10,7 @@ Description=Initrd Default Target
 Documentation=man:systemd.special(7)
 OnFailure=emergency.target
 OnFailureJobMode=replace-irreversibly
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 Requires=basic.target
 Wants=initrd-root-fs.target initrd-fs.target initrd-parse-etc.service
 After=initrd-root-fs.target initrd-fs.target basic.target rescue.service 
rescue.target
diff --git a/units/systemd-hibernate-res...@.service.in 
b/units/systemd-hibernate-res...@.service.in
index 6db584d..3e8c2ef 100644
--- a/units/systemd-hibernate-res...@.service.in
+++ b/units/systemd-hibernate-res...@.service.in
@@ -13,7 +13,7 @@ BindsTo=%i.device
 Wants=local-fs-pre.target
 After=%i.device
 Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service
-ConditionPathExists=/etc/initrd-release
+ConditionInitrd=true
 
 [Service]
 Type=oneshot
-- 
2.1.0

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


[systemd-devel] [PATCH] units: remove unnecessary ordering dependencies in systemd-hibernate-resume@.service

2014-08-27 Thread Ivan Shapovalov
They were left from an early review iteration, when hibernate-resume
functionality was intended to work also outside of initramfs.
Now this is not the case, and these dependencies became redundant
as systemd-fsck-root.service can never be part of initramfs, and
systemd-remount-fs.service makes little sense in it.
---

This is per Thomas's post-commit review.

 units/systemd-hibernate-res...@.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/units/systemd-hibernate-res...@.service.in 
b/units/systemd-hibernate-res...@.service.in
index 3e8c2ef..1a4269b 100644
--- a/units/systemd-hibernate-res...@.service.in
+++ b/units/systemd-hibernate-res...@.service.in
@@ -12,7 +12,7 @@ DefaultDependencies=no
 BindsTo=%i.device
 Wants=local-fs-pre.target
 After=%i.device
-Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service
+Before=local-fs-pre.target
 ConditionInitrd=true
 
 [Service]
-- 
2.1.0

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


Re: [systemd-devel] [PATCH 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.

2014-08-27 Thread Ivan Shapovalov
On Wednesday 27 August 2014 at 20:19:45, Lennart Poettering wrote:  
 On Wed, 27.08.14 20:26, Ivan Shapovalov (intelfx...@gmail.com) wrote:
 
  This is as proposed by Thomas in review of my hibernate-resume patchset.
  
  The objective benefit of this change is that in_initrd() function is used
  for checking, which not only checks for /etc/initrd-release, but also 
  verifies
  that the rootfs is on a virtual device.
 
 If we add a new condition then I want to hear a strong case for it. I
 mean, what's wrong with checking for initrd-release? Why would that not
 suffice?
 
 We should be really careful when it comes to an inflation of conditions...

Let's just cc Thomas Bächler who proposed this. Personally I see only one
benefit (which is described in cover letter)...

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


  1   2   >