On Mon, 24 Sep 2018 15:20:47 +0200
Lennart Poettering wrote:
> On So, 23.09.18 10:38, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
> > Dracut /shutdown script first tries to kill all processes still
> > running off old root. Unfortunately this fails for special user
> > process that runs bpfi
On 02/11/15 21:13, Lennart Poettering wrote:
> On Thu, 05.02.15 19:20, Olivier Brunel (j...@jjacky.com) wrote:
>
>> On 02/03/15 22:17, Lennart Poettering wrote:
>>> On Fri, 12.12.14 16:06, Olivier Brunel (j...@jjacky.com) wrote:
>>>
>>> Sorry for resurrec
On 02/03/15 22:17, Lennart Poettering wrote:
> On Fri, 12.12.14 16:06, Olivier Brunel (j...@jjacky.com) wrote:
>
> Sorry for resurrecting this old thread this late. Is this still an
> issue? Does this work on current git?
Still an issue w/ 218 yes, haven't actually had time to
Hi,
Today I had one unit in failed state, and after taking care of things I
wanted to simply reset its state (to inactive) w/out having to start it.
Looking up the man page, I see there's a command reset-failed for this
exact purpose, awesome. So I go:
% systemctl reset-failed backups2.service
F
With DIRECTION_UP (i.e. navigating backwards) in generic_array_bisect() when the
needle was found as the last item in the array, it wasn't actually processed as
match, resulting in entries being missed.
https://bugs.freedesktop.org/show_bug.cgi?id=86855
---
This was a good excuse for me to dive in
On 08/11/14 18:21, David Herrmann wrote:
> sd-event does not allow multiple handlers for a single signal. However,
> logind sets up signal handlers for each session with VT_PROCESS set (that
> is, it has an active controller). Therefore, registering multiple such
> controllers will fail.
>
> Lets
On 08/11/14 17:12, David Herrmann wrote:
> Hi
>
> On Mon, Aug 11, 2014 at 5:05 PM, Olivier Brunel wrote:
>> On 08/11/14 16:54, Lennart Poettering wrote:
>>> On Mon, 11.08.14 16:39, Olivier Brunel (j...@jjacky.com) wrote:
>>>
>>>>
>>>>
On 08/11/14 16:54, Lennart Poettering wrote:
> On Mon, 11.08.14 16:39, Olivier Brunel (j...@jjacky.com) wrote:
>
>>
>> On 08/11/14 16:25, Lennart Poettering wrote:
>>> On Fri, 08.08.14 20:45, Olivier Brunel (j...@jjacky.com) wrote:
>>>
>>>> In sessi
On 08/11/14 16:34, Lennart Poettering wrote:
> On Fri, 08.08.14 20:45, Olivier Brunel (j...@jjacky.com) wrote:
>
>> While a session can only ever have one controller, there can be more than
>> one session with a controller at a time. However, because of the handling
>> of
On 08/11/14 16:25, Lennart Poettering wrote:
> On Fri, 08.08.14 20:45, Olivier Brunel (j...@jjacky.com) wrote:
>
>> In session_prepare_vt() we set owner of /dev/ttyX to the user, as that is
>> needed for things to work. However, we shouldn't "reset" it to root on
While a session can only ever have one controller, there can be more than
one session with a controller at a time. However, because of the handling
of SIGUSR1 for handling VT switch, trying to set a controller on a session
while another session had a controller would fail.
E.g. trying to start a r
In session_prepare_vt() we set owner of /dev/ttyX to the user, as that is
needed for things to work. However, we shouldn't "reset" it to root on
session_restore_vt() since it could have in fact already been set to the user.
---
src/login/logind-session.c | 2 --
1 file changed, 2 deletions(-)
dif
If controllers can expect logind to have "prepared" the VT (e.g. set it to
graphics mode, etc) then TakeControl() should fail if said preparation
failed (and session_restore_vt() was called).
---
src/login/logind-session.c | 15 +--
src/login/logind-session.h | 2 +-
2 files changed,
When a service exits succesfully and has RemainAfterExit set, its hold
on the console (in m->n_on_console) wasn't released since the unit state
didn't change.
---
TODO | 2 --
src/core/service.c | 16
src/core/unit.c| 3 +++
3 files changed, 19 insertions(+), 2
On 11/14/13 05:40, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Sep 20, 2013 at 10:18:27PM +0200, Olivier Brunel wrote:
>> Hi,
>>
>> I'm running Arch Linux, have been using systemd-204, and recently tried the
>> new
>> 207 release, and I have been having so
On 10/10/13 12:38, Carlos Silva wrote:
> On Thu, Oct 10, 2013 at 5:14 AM, Tero Roponen
> wrote:
>
>> Testing for y > x is the same as testing for x < y.
>>
>
>
>> -if (y > x)
>> +if (x > y)
>>
>
>
> I thing you forgot to change the signs ;)
No, I believe that was the point o
On 10/01/13 05:08, Lennart Poettering wrote:
> On Fri, 20.09.13 22:53, Olivier Brunel (j...@jjacky.com) wrote:
>
>> Since 41efeaec a call to service_unwatch_main_pid() is done from
>> service_set_main_pid(), which is called upon receiving message MAINPID=
>>
>> T
Since 31a7eb86 the output on console can be disabled to avoid colliding with
gettys. However, it could also lead to a lack of messages during
shutdown/reboot.
---
src/core/job.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/core/job.c b/src/core/job.c
index 85f77e8..fd22184 100644
---
If there are no more jobs on console, no need/we shouldn't disable output.
---
src/core/manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index 669af15..a48d711 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -1757,7 +
a
small usecase hence not worth the trouble, so I've simply "undone" it using a
.conf file on my end, figured I should mention it though.
-jjacky
Olivier Brunel (3):
Resolve /dev/console to the active tty instead of just "tty0"
Only disable output on console during bo
Since 41efeaec a call to service_unwatch_main_pid() is done from
service_set_main_pid(), which is called upon receiving message MAINPID=
This had the side effect of not watching pid anymore, and would result in a
useless timeout when stopping the service, as the unit wouldn't be identified
from th
When resolving /dev/console one would often get "tty0" meaning the active VT.
Resolving to the actual tty (e.g. "tty1") will notably help on boot when
determining whether or not PID1 can output to the console.
---
src/shared/util.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/sr
Can help since the journal requires /etc/machine-id to exists in order to start,
and will simply silently exit when it does not.
---
Not sure if the behavior is known/expected or a bug, but when e.g. booting a
system with a read-only rootfs where /etc/machine-id doesn't exist, the journal
would jus
ff-by: Olivier Brunel
---
src/core/transaction.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/core/transaction.c b/src/core/transaction.c
index 4bce942..ee6992a 100644
--- a/src/core/transaction.c
+++ b/src/core/transaction.c
@@ -374,7 +374,8 @@ stati
Swap units will now be following the unit of the devnode when the swap is off
(and usual following therefore not in place), thus allowing things to work
even in cases such as:
systemctl start 'dev-disk-by\x2dlabel-SWAP.swap' dev-sda3.swap
This first will load and redirect the request to the un
Make sure swap_add_one is only called once per unit also for symlinks
---
If, as Lennart indicated was possible, symlinks can be used in /proc/swaps then
the check must be done for symlinks as well.
src/core/swap.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/sr
uld follow/redirect to it,
and it is seen inactive, nothing would be done (swapoff never called).
This is because this unit would be treated twice in
swap_process_new_swap, the second call to swap_add_one causing it to
eventually be marked inactive.
Signed-off-by: Olivier Brunel
---
The patch remove
27 matches
Mail list logo
