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 <https://freedesktop.org/wiki/Software/systemd/dbus/>. 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
<https://unix.stackexchange.com/a/310775/5132>. 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/
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221>. 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
<http://jdebp.eu./FGA/dont-abuse-su-for-dropping-privileges.html>, 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
<http://jdebp.eu./FGA/dont-abuse-nobody-for-daemons.html>, 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|.
