Re: [systemd-devel] systemd user sessions?

2016-02-24 Thread Krzysztof Kotlenga
Jon Stanley wrote:

> I'd like a systemd unit (and only that unit) to be controlled by a
> specific user. The unit runs as this user, so I thought about user
> instances of systemd. This service should be started when the system
> starts, so you'd have to enable linger in systemd-logind for that to
> work.
>
> The question is how to make the systemd user *service* start at boot?

[Install]
WantedBy=default.target

$ systemctl --user enable foo.service
Created symlink
from /home/user/.config/systemd/user/default.target.wants/foo.service
to /home/user/.config/systemd/user/foo.service.
$

That's pretty much it.

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


Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

2015-09-29 Thread Krzysztof Kotlenga
David Herrmann wrote:

> Krzysztof Kotlenga wrote:
>> David Herrmann wrote:
>>> Krzysztof Kotlenga wrote:
>>
>> Some more or less minor points still stand though:
>>
>> - errored/disabled bus-inputs are never freed, even after client
>>   disconnect (!)
> 
> What's a "bus-input"?

sd_bus.input_io_event_source sd_event_sources have a description set to
"bus-input" to aid debugging:
https://github.com/systemd/systemd/blob/v226/src/libsystemd/sd-bus/sd-bus.c#L3180

For example this return path:
https://github.com/systemd/systemd/blob/v226/src/libsystemd/sd-bus/sd-bus.c#L2782

It's easy to "exercise" it with netcat (generate -EIO there), as I
wrote before. Such sd_event_source gets disabled but it doesn't go
anywhere, even after client disconnect.

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


Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

2015-09-26 Thread Krzysztof Kotlenga
David Herrmann wrote:

> Krzysztof Kotlenga wrote:
>> Krzysztof Kotlenga wrote:
>>
>>> 2. Maybe I don't get something right - please enlighten me if
>>> that's the case - but prioq_put or rather shuffle_up function is
>>> buggy.
>>>
>>> (...)
>>>
>>> Am I wrong to believe that it should have swapped 2 and 1, not 2
>>> and 0?
>>
>> OK, I've finally realised that I'm a moron iterating over a
>> heap-like structure...
> 
> For the archives: Is this fixed with the prioq-compare fix?

The point quoted above was bogus, but otherwise yes - the main issue
here is fixed with the said fix.

Some more or less minor points still stand though:

- errored/disabled bus-inputs are never freed, even after client
  disconnect (!)

- data pointer comparison instead of index comparison for prioq
  stability. Is this _really_ correct? Anyway, I made a pull
  request...

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


Re: [systemd-devel] What's mounting this partition?

2015-09-26 Thread Krzysztof Kotlenga
Paul D. DeRocco wrote:

> I have a Yocto-built x86 system (...)

Do you have udev-extraconf package installed? It contains such a gem:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/udev/udev-extraconf/automount.rules

HTH.

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


Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

2015-09-23 Thread Krzysztof Kotlenga
Krzysztof Kotlenga wrote:

> I recommend the following gdb script, because it provides some
> possibly interesting output:

Slightly fixed version:
https://gist.github.com/pocek/709d8c098d632ed1f21e

The first one was incorrectly printing pending_iteration instead of
prepare_iteration field. Nothing major.

> What's going on with order in that "prepare" Prioq?

I've debugged this a bit more. Two things:

1. I think prepare_prioq_compare function is wrong: "enabled" field
should be the first one to compare.

2. Maybe I don't get something right - please enlighten me if that's the
case - but prioq_put or rather shuffle_up function is buggy. 

Let's start with prepare Prioq like this:
bus-input e=1 pri=0 pi=8 fd=12
bus-input e=1 pri=0 pi=9 fd=18 <- netcat

Now we enter some garbage in netcat:
bus-input e=1 pri=0 pi=9 fd=12
bus-input e=0 pri=0 pi=9 fd=18 <- netcat

BTW, some loop iterations later it is still OK if we have fixed the
order in prepare_prioq_compare (see 1):

bus-input e=1 pri=0 pi=10 fd=12
bus-input e=0 pri=0 pi=9 fd=18 <- netcat

Good! Now let's make another connection. We have a breakpoint in
prepare_prioq_compare.

bus-input e=1 pri=0 pi=11 fd=12
bus-input e=0 pri=0 pi=9 fd=18
(null) e=1 pri=0 pi=0 fd=19 <- new connection, it doesn't have a
   description set yet.

Backtrace for some context (shortened):
#0  prepare_prioq_compare (a=0x81466e18, b=0x81477490) 
#1  shuffle_up (q=0x81466ee8, idx=2)
#2  prioq_put (q=0x81466ee8, data=0x81477490, idx=0x814774b8)
#3  sd_event_source_set_prepare (s=0x81477490, callback=0x80181f81 
)
#4  attach_io_events (bus=0x81476d20)
#5  sd_bus_attach_event (bus=0x81476d20, event=0x8140e6e0, priority=0)
#6  bus_on_connection (s=0x81471680, fd=14, revents=1, userdata=0x8140e318)
#7  source_dispatch (s=0x81471680)
#8  sd_event_dispatch (e=0x8140e6e0)
#9  sd_event_run (e=0x8140e6e0, timeout=18446744073709551615)
#10 manager_loop (m=0x8140e318)
#11 main (argc=4, argv=0xbfb1b254)

OK, let's see what we have got here:
(gdb) p x->prepare_index
$2 = 0
(gdb) p y->prepare_index
$3 = 2

So we are comparing the new sd_event_source with the first one in the
queue. This is bad. Let's move to shuffle_up first.

(gdb) frame 1
(gdb) p k
$4 = 0

Right. So shuffle_up doesn't iterate more than once here. It has only
swapped item 0 and 2. The prepare queue looks like this now:

(null) e=1 pri=0 pi=0 fd=19
bus-input e=0 pri=0 pi=9 fd=18
bus-input e=1 pri=0 pi=11 fd=12

It doesn't look like a correct order judging by how prepare_event
(sd-event.c) works. The last bus-input above is pretty much broken
because s->prepare callback won't be called anymore.

Am I wrong to believe that it should have swapped 2 and 1, not 2 and 0?

Lennart, can you fix Prioq or correct me if I'm wrong, please?

> This has been debugged on v225, but AFAICS master has the same issues.

I'm debugging this now on v226 now.

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


Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

2015-09-23 Thread Krzysztof Kotlenga
Krzysztof Kotlenga wrote:

> Two things:
> (...)

One more. Prioq compare functions in sd-event.c contain this:

/* Stability for the rest */
if (x < y)
return -1;
if (x > y)
return 1;


How comparing prioq_item.data pointers is going to ensure stability?
Shouldn't it be:

if (x->prepare_index < y->prepare_index)
...

and so on?

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


Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

2015-09-23 Thread Krzysztof Kotlenga
Krzysztof Kotlenga wrote:

> 2. Maybe I don't get something right - please enlighten me if that's
> the case - but prioq_put or rather shuffle_up function is buggy. 
> 
> (...)
> 
> Am I wrong to believe that it should have swapped 2 and 1, not 2 and
> 0?

OK, I've finally realised that I'm a moron iterating over a heap-like
structure...

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


[systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

2015-09-22 Thread Krzysztof Kotlenga
Hi.

There were many reports of "Looping too fast. Throttling execution a
little" behavior but they never got anywhere. Not this time. At least
for this particular case.

Initially I was able to reproduce this issue just by calling `systemctl
restart some_specific_service` - then most of further `systemctl`
actions (except status) caused systemd to enter an infinite event loop.

Long story short, I found out that entering some garbage
on /run/systemd/private with netcat breaks systemd equally well.
`systemctl daemon-reexec` fixes it. But before you decide to break
yours PID 1 event loop, I recommend the following gdb script, because
it provides some possibly interesting output:

#v+
b event_prepare
commands 1
set $size = e->prepare->n_items
set $enabled_after_disabled = 0
set $i = 0
while $i < $size
set $s = (sd_event_source*)e->prepare->items[$i].data
if $s->type == SOURCE_IO
printf "%s e=%d pri=%d pi=%u fd=%d\n", \
$s->description, $s->enabled, $s->priority, \
$s->pending_iteration, $s->io.fd
else
printf "%s e=%d\n", $s->description, $s->enabled
end

if $i++ > 0
if $s->enabled == SD_EVENT_ON && $previous->enabled == SD_EVENT_OFF
set $enabled_after_disabled = 1
end
end

set $previous = $s
end

if $enabled_after_disabled
print "XXX shouldn't happen?"
else
continue
end
end
#v-

Now let's follow this. Output shortened for brevity.

1. Attach to systemd and let it run. You will most likely see some
event source, not of particular interest, like this:

bus-input e=1 pri=0 pi=0 fd=12

2.  All is good. Run `nc -U /run/systemd/private`

bus-input e=1 pri=0 pi=0 fd=18
bus-input e=1 pri=0 pi=0 fd=12

3. We are here too. Enter a newline.

bus-input e=1 pri=0 pi=0 fd=12
bus-input e=0 pri=0 pi=15 fd=18

4. This bus-input event source got disabled by source_dispatch, because
bus_socket_auth_verify_server returned -EIO. Now wait, hit Ctrl+C,
generate some events with systemctl - whatever.

bus-input e=0 pri=0 pi=15 fd=18
bus-input e=1 pri=0 pi=0 fd=12
$1 = "XXX shouldn't happen?"

5. The event loop is broken now. It haven't entered an infinite loop
*yet* but calls like `systemctl restart whatever` will cause it. The
reason is that prepare callbacks in event_prepare (sd-event.c) aren't
called anymore - the for loop there breaks on the first disabled source.

The prepare callback of the bus that systemctl talks on (most
importantly sd_bus_get_events) is called only once and sets
POLLIN|POLLOUT flags. That POLLOUT is left there as long as the client
is on the bus and causes an infinite event loop.

When we exit that hanging systemctl, systemd quits looping but the
event loop is still broken. That disabled bus-input from point 4 is
left there forever and prevents prepare callbacks of the enabled event
sources to run.

So, how many bugs are here?

It seems that there are other errors than can happen in sd-bus /
bus-socket, which bus_process_internal (sd-bus.c) doesn't handle and
leaves the disabled event source sitting there forever. Those disabled
event sources are:
- a memory leak?
- very good at breaking event_prepare (sd-event.c).

What's going on with order in that "prepare" Prioq?

This has been debugged on v225, but AFAICS master has the same issues.

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


Re: [systemd-devel] How to properly write an umbrella unit

2015-07-24 Thread Krzysztof Kotlenga
Lennart Poettering wrote:
 Daurnimator wrote:
 Lennart Poettering wrote:

 Maybe we can change the manager core to propagate Reload() calls
 for unit type that do not support it natively to other units
 listed in PropagateReloadsTo= and then become a NOP.

 Or in other words: invoking reload on a target that knows no
 PropagateReloadsTo= should continue to return an error. But if
 such deps are defined, it should become a silent NOP and
 propagate the event.

 Could you file an RFP issue on github asking for this? [or even
 better, send a PR with a patch...  ;-) ]
 
 ReloadPropagatedFrom= would seem to be more useful here.
 
 Well, ReloadPropagateFrom= is the inverse of PropagateReloadsTo=. If
 there is a dep of the first kind from A to B, there's always a dep of
 the second kind from B to A, and vice versa.
 
 Why should reloading a target error in the first place? == why not
 just a NOP?
 
 Hides bugs? reloading a target makes no sense, unless you use it for
 reload propagation.

But stopping and restarting a target already makes sense if you use
PartOf=foo.target.

Unfortunately one cannot specify ConsistsOf in a unit file, which
is a really annoying limitation.

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


Re: [systemd-devel] How to properly write an umbrella unit

2015-07-24 Thread Krzysztof Kotlenga
Lennart Poettering wrote:

 On Fri, 24.07.15 11:07, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote:
 
 Unfortunately one cannot specify ConsistsOf in a unit file, which
 is a really annoying limitation.
 
 That limitation exists for a reason: systemd loads unit files lazily:
 only units that are referenced by some other unit are loaded.

By reference you mean a reference that causes a unit file to be loaded
like Wants? I understand that ConsistsOf is not (would not be) such
a reference, but TBH I don't quite understand why.

Is this something to do with positive and inverse dependencies and
PartOf being already a positive one? (I'm staring at the UnitDependency
enum).

I kinda understand it was made this way mainly or even only with
instance units in mind. Correct?

 Thus, just sticking a unit file somewhere, and writing ConsistsOf=
 into it, would generally not work, since the dep would never be
 considered unless you also have a dep from something else on it. To
 avoid this confusion we simply don't support it at all.

What I've actually tried after learning about PartOf some time ago:

# foo.target
[Unit]
Wants=a.service b.service c.service
ConsistsOf=a.service b.service c.service

so I can start/stop/restart a bunch of services with systemctl. Both
lists in one place, so it would be hard to forget about something while
making changes. Single file to edit - neat. Just perfect - that's what
I thought until a moment later.

 (Only way to make this work would be by allowing ConsistsOf= deps via
 .consistsof subdirs with symlinks like we support it for .wants, and
 then have ConsistsOf= in the [Install] section, if you follow what I
 mean).

.consistsof and [Install]/PartOf would sound reasonable, just
like .wants and [Install]/WantedBy. [Install]/ConsistsOf seems wrong.

But how will this solve anything? Is .wants different from Wants?

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


Re: [systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)

2014-12-10 Thread Krzysztof Kotlenga
On Tue, 2014-12-09 at 17:28 +0100, Lennart Poettering wrote:
 On Tue, 09.12.14 16:24, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote:
 
 Currently notify socket is unavailable in chrooted services (again)
 unless you bind mount it there. Is there perhaps another, less
 cumbersome way?
 
 So far notify socket was:
 [snip change history]
 
 So... would it be acceptable to have two notify sockets, one
 abstract and one normal, the latter only set for services with
 PrivateNetwork or - better maybe - explicitly selectable? Any other
 ideas?
 
 Hmm, but what would you do for a service that has both
 PrivateNetwork and chroot enabled?

Well, PrivateNetwork is clearly asking for trouble... A socket doesn't
really look like a right tool for the job in this case. I know Unix
signals were previously discarded in

https://bugzilla.redhat.com/show_bug.cgi?id=833105

Dunno what's left.

 Ideas?
 
 I figure we could open a new mount namespace and mount the file
 system socket into the chroot, but not sure I like the idea...

I don't know what else is possible, sorry. Anyone?

-- 
K.


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


[systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)

2014-12-09 Thread Krzysztof Kotlenga
Hi.

Currently notify socket is unavailable in chrooted services (again)
unless you bind mount it there. Is there perhaps another, less
cumbersome way?

So far notify socket was:
1. abstract socket

   commit 8c47c7325fa1ab72febf807f8831ff24c75fbf45
   notify: add minimal readiness/status protocol for spawned daemons

2. file-system socket

   commit 91b22f21f3824c1766d34f622c5bbb70cbe881a8
   core: move abstract namespace sockets to /dev/.run

   Now that we have /dev/.run there's no need to use abstract
   namespace sockets. So, let's move things to /dev/.run, to make
   things more easily discoverable and improve compat with chroot()
   and fs namespacing.

3. abstract socket again

   commit 29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da
   manager: turn notify socket into abstract namespace socket again

   sd_notify() should work for daemons that chroot() as part of their
   initilization, hence it's a good idea to use an abstract namespace
   socket which is not affected by chroot.

4. file-system socket again

   commit 7181dbdb2e3112858d62bdaea4f0ad2ed685ccba
   core: move notify sockets to /run and $XDG_RUNTIME_DIR

   A service with PrivateNetwork= cannot access abstract namespace
   sockets of the host anymore, hence let's better not use abstract
   namespace sockets for this, since we want to make sure that
   PrivateNetwork= is useful and doesn't break sd_notify().


So... would it be acceptable to have two notify sockets, one abstract
and one normal, the latter only set for services with PrivateNetwork
or - better maybe - explicitly selectable? Any other ideas?

-- 
K.

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