On Fri, Sep 18, 2015 at 11:51:37AM +0100, Riku Voipio wrote: > On 17 September 2015 at 18:53, Will Deacon <will.deacon@xxxxxxx> wrote: > > On Thu, Sep 17, 2015 at 03:03:15PM +0100, Alban Crequy wrote: > >> kvm__set_dir() called in main() and kvm__get_dir() rely on $HOME. But in > >> some environments (such as starting lkvm through systemd-run), $HOME is > >> undefined. This causes bind() to use a socket path containing "(null)" > >> and this fails. The current code does not check errors returned by > >> realpath(). > >> > >> Symptoms: > >> > >> | bind: No such file or directory > >> | Error: Failed adding socket to epoll > >> | Warning: Failed init: kvm_ipc__init > >> | > >> | Fatal: Initialisation failed > >> > >> This bug was first reported on https://github.com/coreos/rkt/issues/1393 > >> > >> Instead of using "$HOME/.lkvm/" (i.e. "/root/.lkvm/"), this patch uses > >> "/var/lib/lkvm/". This also improve the error reporting by printing the > >> socket filename. > > > > Hmm, but that requires lkvm to be run with sufficient privileges to > > write to /var/lib, which I don't think is generally the case. I think we > > have a few options: > > > > (1) Try /var/lib/lkvm if $HOME is NULL > > (2) Use an alternative environment variable for the pid prefix > > (3) Add a --pid command line option for the pidfile > > (4) ??? > > > > Any preferences? What do other projects do? > > The right place to put a pid file would be $XDG_RUNTIME_DIR aka > /run/user/$UID/. System services write their pidfiles and sockets to > plain /run Ok, that certainly sounds like the right things to do for temporary structures then. Thanks. > The place where to put the rootfs structure created in builtin-setup.c > is more complicated. Is the created rootfs epheremal? Then sticking > under /run(user/UID) is fine. Currently, the filesystem persists across multiple invocations of lkvm, so I can imagine somebody being surprised if what they thought was persistent was lost over something like a reboot. Will -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
