I've been trying to find the cause of a 'transaction is destructive' error
from systemd. I'm testing systemd-219-67.el7_7.4 with the following patch
applied:
https://github.com/systemd/systemd/commit/cf99f8eacf1c864b19a6a02edea78c43f3185cb7
One of the error messages I've been trying to explain
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
> On Mon, 2020-04-27 at 11:40 +0100, Mark Bannister wrote:
> > One of the error messages I've been trying to explain is reported like this:
> > 2020-04-22T00:45:47.047710-04:00 jupiter systemd[1]: Requested transaction
> > contradicts existing jobs: Transaction for sessi
On Wed May 6 17:49:02 UTC 2020, Kumar Kartikeya Dwivedi wrote:
> This issue is NOT reproducible with the version you reported
> originally. The stock CentOS image on my cloud provider comes with the
> same version (219-67.el7_7.4) that you said you see this issue with,
> but that can't be, as it
> On Tue, 5 May 2020 at 16:27, Mark Bannister wrote:
> > Perhaps I'm missing something or oversimplifying, but I tried to
> > reproduce the problem as follows: I created a script that ignores INT,
> > TERM and HUP and then loops indefinitely writing the time every second
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
At Thu May 7 15:13:14 UTC 2020, Kumar Kartikeya Dwivedi wrote:
> Well, maybe you're mixing two issues into one. The original report was
> about session scopes failing due to a conflict of job types, which you
> should not be seeing on 219-67
Sorry if I confused the thread by mentioning
