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