Re: [systemd-devel] systemd service fails to start rhel7.8

2020-05-05 Thread Tomasz Torcz
On Tue, May 05, 2020 at 08:48:17AM +, Aviram, Nimrod wrote: > After upgrading OS to RHEL 7.8 , the service fails to start. > I'm usually creating a basic user (cfrm) to run Catalina but I've also tried > with root and received the same exception. > > [Unit] > Description=cfrmic > [Service] >

[systemd-devel] systemd service fails to start rhel7.8

2020-05-05 Thread Aviram, Nimrod
HI, I've been using the following service to control our catalane server for the past few years now. After upgrading OS to RHEL 7.8 , the service fails to start. I'm usually creating a basic user (cfrm) to run Catalina but I've also tried with root and received the same exception. I know that

Re: [systemd-devel] local-fs and remote-fs targets / passive active units

2020-05-05 Thread Thomas HUMMEL
On 5/5/20 7:41 PM, Andrei Borzenkov wrote: a) Before= does not pull anything anywhere. Yes I know sorry I did not use the correct term. I did not mean that. b) as you already found, by default every service is ordered after local-fs.target. You need DefalutDependencies=no if you want to

[systemd-devel] systemd.network vs. ifupdown vs. netplan?

2020-05-05 Thread John Ioannidis
Is there a document somewhere that details what the interactions/conflicts/etc are between systemd.{link,netdev,network} and the ifupdown mechanisms? I have read the manual pages, of course, but I feel I'm missing something fundamental. I finally got around to moving to Debian 10, and in the

Re: [systemd-devel] local-fs and remote-fs targets / passive active units

2020-05-05 Thread Andrei Borzenkov
05.05.2020 18:15, Thomas HUMMEL пишет: > On 4/28/20 5:36 PM, Thomas HUMMEL wrote: > >> 3) regarding local-fs dans remote-fs targets : I'm not really sure if >> any fits in either passive or active units. > > Hello again, > > regarding local-fs.target : is it legit for a custom service unit to >

Re: [systemd-devel] local-fs and remote-fs targets / passive active units

2020-05-05 Thread Thomas HUMMEL
On 5/5/20 5:27 PM, Thomas HUMMEL wrote: On 5/5/20 5:15 PM, Thomas HUMMEL wrote: -> this seems to be like an actual run and not only the queuing of a job into the transaction which would be discarded afterwards when the cycle is discovered ? Ok I figure out this one : I was confusing the

Re: [systemd-devel] local-fs and remote-fs targets / passive active units

2020-05-05 Thread Thomas HUMMEL
On 5/5/20 5:15 PM, Thomas HUMMEL wrote: -> this seems to be like an actual run and not only the queuing of a job into the transaction which would be discarded afterwards when the cycle is discovered ? Ok I figure out this one : I was confusing the systemd-tmpfiles-setup.service from initrd

Re: [systemd-devel] local-fs and remote-fs targets / passive active units

2020-05-05 Thread Thomas HUMMEL
On 4/28/20 5:36 PM, Thomas HUMMEL wrote: 3) regarding local-fs dans remote-fs targets : I'm not really sure if any fits in either passive or active units. Hello again, regarding local-fs.target : is it legit for a custom service unit to pull it in with a Before=local-fs.target (no Wants or

Re: [systemd-devel] Requested transaction contradicts existing jobs: start is destructive

2020-05-05 Thread Kumar Kartikeya Dwivedi
On Tue, 5 May 2020 at 16:27, Mark Bannister wrote: > > So if I'm understanding correctly, your suggestion is that if an SSH > session runs a process that ignores SIGTERM and the session is closed > and then within 90 seconds the same user attempts to open a new SSH > session, it should trigger

Re: [systemd-devel] Extend service runtime

2020-05-05 Thread Mantas Mikulėnas
On Tue, May 5, 2020 at 1:19 AM Andy Pieters wrote: > > > 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 +

[systemd-devel] Requested transaction contradicts existing jobs: start is destructive

2020-05-05 Thread Mark Bannister
On Mon May 4 12:44:12 UTC 2020, Kumar Kartikeya Dwivedi wrote: > For your case, it could be that some process running under > session-N.scope is not responding to SIGTERM, and this in turn is > making session-N.scope take time to stop (it has a default timeout of > 90s), because it has to wait

Re: [systemd-devel] Extend service runtime

2020-05-05 Thread Andy Pieters
On Tue, 5 May 2020 at 07:56, Lennart Poettering wrote: > A service for which sd_notify() is enabled can send > an EXTEND_TIMEOUT_USEC= message to the service manager, in order to > extend its timeouts. Wouldn't that work for you? > > That sounds perfect, thank you :)

Re: [systemd-devel] Extend service runtime

2020-05-05 Thread Lennart Poettering
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