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

[Dave Sherohman]

On Thu, Aug 31, 2017 at 07:40:50PM +0100, Jonathan de Boyne Pollard wrote:
> That said, it does sound like, from the scant description given, you are
> mis-using |su|. Do 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|.

Thank you.  This lecture, though misplaced, proved to be useful.

While checking /etc/cron.daily to confirm that it's a Debian package,
not anything I wrote, which uses `su nobody`, I found that
/etc/cron.daily/locate calls updatedb.findutils with $LOCALUSER set to
"nobody".  updatedb.findutils then calls `su $LOCALUSER` multiple times,
matching the multiple attempts to su from root to nobody that I see in
auth.log.

For my part, I suppose I'll resolve this by switching from locate to
mlocate, which does its database updates as root, so it should have no
reason to drop privileges, regardless of the method.

In the larger picture, I suppose this qualifies as a bug in the locate
package.  But I will not file a bug against the package because,
honestly, I don't believe that I understand the pieces in play well
enough to make a convincing argument to the maintainer that it should be
changed, much less what it should be changed *to*.

-- 
Dave Sherohman

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

[Jonathan de Boyne Pollard]

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 |su|. Do 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|.

systemd says "org.freedesktop.systemd1.TransactionIsDestructive"

[Dave Sherohman]

Since being upgraded from jessie to stretch, several of my machines have
started emitting the following messages while processing cron.daily:

(in /var/log/syslog)
Aug 31 06:30:48 HOSTNAME systemd[1]: Requested transaction contradicts existing 
jobs: Transaction is destructive.

(in /var/log/auth.log)
Aug 31 06:30:48 HOSTNAME su[32025]: pam_systemd(su:session): Failed to create 
session: Input/output error
Aug 31 06:30:48 HOSTNAME systemd-logind[1301]: Failed to start session scope 
session-11179.scope: Transaction is destructive.  
org.freedesktop.systemd1.TransactionIsDestructive

The mention of freedesktop in one of the messages suggests that this may
be somehow X/GUI related, but all machines which are doing this are
headless servers with no X server installed, so they shouldn't be
touching anything obviously related to freedektop.org.

Googling "org.freedesktop.systemd1.TransactionIsDestructive" just gets
me a handful of people having system startup/shutdown problems, which
would seem to support the "it's GUI desktop related" assumption, but
doesn't really provide any explanation of what's actually going wrong
(if anything - systemd is rather chatty even when everything is just
fine).

Looking at the larger context in auth.log, this comes in the middle of
starting up and shutting down several su sessions from root to nobody,
all of which succeed aside from the one which generates these errors.


So, in practical terms, what do these messages actually mean, beyond
just "a su session failed to start"?  Is it anything to be concerned
about?

-- 
Dave Sherohman