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.
Zbyszek > > run.c calls find_binary() [1] which doesn't take the container argument into > > account. So it does what the code tells it to do, I'm just not sure > > whether it is a bug or intended behaviour and I misunderstood something. > > Not a bug in particular, but definitely odd behavior. If you use -M > with systemd-run, it's clear that the passed binary has to reside in > the container, otherwise, the newly created transient unit inside of > the container will not find the binary. So yeah, we should make it > work. > > I see 2 "easy" solutions for this: > > 1) If the binary is given as full path but we cannot find it, print a > warning but proceed. > > 2) If "-M" is given, read "ROOT=" from /run/systemd/machine/* (similar > to our container_get_leader() helper in src/shared/util.c). Then > prepend this as prefix to any absolute path. > > The find_binary() helper also searches $PATH if the given binary is > not a path itself. I'm not sure how to implement that for containers. > We cannot easily get the $PATH variable of the container (we'd have to > open a new session). Furthermore, it sounds wrong to read PATH from > something outside the context of the caller (similarly, we don't want > hacks like prepending ROOT to the current PATH of the caller). > I'd say we only support find_binary() if -M is not given. Otherwise, > we go with option 2) and try to resolve the whole path. And, maybe, if > we cannot resolve the path (like ROOT= is not given), we print a > warning if -M was passed and still proceed. > > CC'ing Lennart, he might have more insight. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel