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
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
&g
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.
>>>
>>
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
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
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 i
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 fina
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
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
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
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
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
12 matches
Mail list logo
