Web lists-archives.com

Re: systemd says "org.freedesktop.systemd1.TransactionIsDestructive"

Dave Sherohman:

The mention of freedesktop in one of the messages suggests that this may be somehow X/GUI related,

No, it does not.  That is not the only place where one finds such names.  Or, rather, the mechanism that uses such names is not only used for graphical user interfaces.

It is, of course, D-Bus.  The systemd-logind dæmon is communicating with the systemd dæmon, in order to start a service, via its D-Bus interface.  And the org.freedesktop.systemd1.TransactionIsDestructive error code is what the systemd dæmon is communicating back.  You are witnessing the undocumented interface between systemd-logind and systemd.

The problem that it indicates is that when systemd is trying to start the service, which is actually a so-called scope named session-11179.scope, it has encountered a contradiction.  As the user manual explains, when systemd comes to start a service, it breaks it down into a collection of jobs, which are individual actions to take in order to achieve the overall goal.  What has happened here is that the set of jobs necessary to start session-11179.scope is self-contradictory, or contradicts existing jobs running at the time.  It involves both starting/checking/restarting/reloading something and stopping it, simultaneously.

The people who hit this at shutdown have systems with a similar configuration problem to yours.  On yours and theirs, there's some configured contradiction, a unit that both is wanted by and conflicts with another unit; somewhere.  That might be down a long chain connected from the unit that you think that you are dealing with.  Or there's a contradiction with something else executing concurrently within systemd.

The scope unit is not something that you can do without; if you are doing things within login sessions, that is.  As you note, the failure to start it stops su from working.  Scope units are used by systemd-logind to create user-mode login sessions.  It arranges, in conjunction with PAM extension modules, that all of the processes inside such a login session run within such a scope.  It uses the scope to place resource usage constraints upon the login session, such as a maximum number of processes.

Unfortunately, you have a hard task ahead. You can run things like systemctl list-jobs, but it is a good bet that what you are seeing is timing-dependent because it is a contradiction between two concurrent things.  You will likely find that you have to run systemctl list-jobs at just the right time, too.

That said, it does sound like, from the scant description given, you are mis-using suDo not abuse su to drop privileges, from root to nobody.  There are proper tools for the job of dropping privileges, which do not involve PAM and which will thus not hit this problem.  Moreover: do not abuse nobody for running dæmons, if you are doing that.  Set up a proper rôle account.  And, indeed, give the cron job (whatever it is) directly to that rôle account's crontab.