<div dir="ltr"><div><div><div>On the one hand, I understand your point. On the other hand, there are three other ways of doing this: systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/<uid> --uid=<uid> systemctl --user ... su -l <username> -c "XDG_RUNTIME_DIR=/run/user/<uid> systemctl --user" machinectl --uid=<uid> shell /bin/systemctl --user ... </div>(I'm assuming the last way actually works. Does it?) </div>So I thought that my suggestion was an even cleaner way to accomplish the same thing. I get that you don't want priv code to depend on unpriv code but systemctl is a command line tool. It's up to the user if they want to run it that way. </div><div> </div><div> <div> </div></div></div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Nov 24, 2017 at 5:05 AM, Lennart Poettering <<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Do, 23.11.17 22:56, Jeff Solomon (<a href="mailto:jsolomon8080@gmail.com">jsolomon8080@gmail.com</a>) wrote: > Hi, > > More questions about the systemd user service. > > Inside a script running as root, I want to control another user's service. > > I have found two ways to do this: > > systemd-run -t --setenv=XDG_RUNTIME_DIR=/run/user/<uid> --uid=<uid> > systemctl --user ... > > or: > > su -l <username> -c "XDG_RUNTIME_DIR=/run/user/<uid> systemctl --user > ..." > > Both work. > > If there a better way to do this? > > My distros aren't recent enough to include "machinectl shell" but is that > the recommended way now? > > machinectl --uid=<uid> shell /bin/systemctl --user ... > > Perhaps there is not enough demand to justify it, but I would love if the > systemctl command itself had a way to specify that it should communicate > with a different user's service rather than system service or the calling > user's service. Something like: > > systemctl --uid=<uid> --user .. > > would be awesome. Hmm, sorry, but this is something we'll are unlikely to support in any special way. Making privileged code a client of unpriveled user code like this makes me feel very uncomfortable. Privileged code really should not transition and block on unprivileged user code likes this. Philosophically it has this feeling of being the wrong way round: the unpriv code should ask the priv code what it should do, it shouldn't be the priv code that asks the unpriv code, in any blocking way... I mean, the unpriv code can ultimately do whatever it wants, and priv code should not block on that for good. It's simply the wrong way round to design such a system, if you follow what i mean. Usually most usecase like that are better solved by making things asynchronous notifier based, and make the unpriv code just react to notifications, instead of synchronous call-ins... Lennart -- Lennart Poettering, Red Hat </blockquote></div> </div>