[systemd-devel] systemd-run checks path on host before running on container

[Peter Hutterer]

On Sun, Nov 23, 2014 at 02:40:29AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Nov 23, 2014 at 12:14:32AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sat, Nov 22, 2014 at 02:47:49PM +0100, David Herrmann wrote:
> > > Hi
> > > 
> > > On Fri, Nov 21, 2014 at 5:00 AM, Peter Hutterer
> > > <peter.hutterer at who-t.net> wrote:
> > > > I was playing around with systemd-nspawn and systemd-run. The latter doesn't
> > > > seem to let me run a command that solely exists on the container.
> > > > simple way of reproducing: drop a file foo into the container, then on the
> > > > host run
> > > >
> > > >     systemd-run -M mycontainer /path/to/foo
> > > >
> > > > I expected this to run foo on the container. It does, but checks for the
> > > > command to exist locally first and fails. A simple touch /path/to/foo; chmod
> > > > +x $_ is sufficient to bypass that check, but that feels somewhat odd.
> > I pushed a partial fix which makes find_binary() ignore errors for
> > non-local absolute paths. Something which checks the path remotely
> > might be nicer, but I'm not sure if it's worth the hassle.
> 
> Looking at this again, I think we should resolve the paths remotely.
> We could redefine the dbus call to do $PATH resolution on paths without any
> slashes, or we could a new call. I like redefining the existing one more.
> I don't think anyone will care.
> 
> See also https://bugs.freedesktop.org/show_bug.cgi?id=86555, which is a similar
> problem with systemd-nspawn.

from a user's perspective having systemd-run fail if the remote path doesn't
exist would certainly be nice. Except it'd be a change in behaviour and may
break scripts, but that's something you'd have to decide - I'm not affected
here :)

thanks for the quick fix

Cheers,
   Peter