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.hutte...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
