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.