On Mo, 04.05.20 15:51, Andy Pieters (syst...@andypieters.me.uk) wrote:
> Hi
>
> I'm trying to accomplish the following:
>
> An event happens -> I start a systemd service in response
> after RuntimeMaxSec is reached service terminates and cleans up event
>
> Should a second event happen whilst Ru
On Mon, 4 May 2020 at 23:11, Mantas Mikulėnas wrote:
>
>
> So this is basically for implementing sudo-like caching for 2FA?
>
>
Yes that's exactly it.
> What authentication methods are involved here?
>
Using yubikey + password when 2F is active, using hostkey when not
> Seems like there are
On Mon, May 4, 2020, 23:31 Andy Pieters wrote:
> On Mon, 4 May 2020 at 15:51, Andy Pieters
> wrote:
>
>> Hi
>>
>> I'm trying to accomplish the following:
>>
>> An event happens -> I start a systemd service in response
>> after RuntimeMaxSec is reached service terminates and cleans up event
>>
On Mon, 4 May 2020 at 15:51, Andy Pieters wrote:
> Hi
>
> I'm trying to accomplish the following:
>
> An event happens -> I start a systemd service in response
> after RuntimeMaxSec is reached service terminates and cleans up event
>
> Should a second event happen whilst RuntimeMaxSec is not ye
Hi
I'm trying to accomplish the following:
An event happens -> I start a systemd service in response
after RuntimeMaxSec is reached service terminates and cleans up event
Should a second event happen whilst RuntimeMaxSec is not yet reached the
preference would be to reset RuntimeMaxSec of the
On 4/30/20 10:43 AM, Zbigniew Jędrzejewski-Szmek wrote:
Lennart opened a PR to remove the caching:
https://github.com/systemd/systemd/pull/15624.
Great!
The documentation is wrong. The code in hostnamed sets the kernel
hostname when setting the static one. This was changed in
https://github
On Mon, 4 May 2020 at 16:02, Mark Bannister wrote:
>
> ...
>
> When you say the session slice is taking time to clean up, please
> excuse my ignorance as
> I'm not really up to speed on how session slices are being managed by
> systemd, but why
> would it matter if a slice takes time to clean up?
On Thu Apr 30 19:01:51 UTC 2020, Kumar Kartikeya Dwivedi wrote:
> My educated guess is that the session slice is taking time to clean up
> because of the default stop timeout due to processes in the session
> not responding to SIGTERM (it is waiting for dependent units to stop
> before stopping it
