On 18 September 2015 at 13:56, Will Deacon <will.deacon@xxxxxxx> wrote: > 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) ???ow >> > >> > 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. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html In that case that data could go into XDG_DATA_HOME, XDG_CONFIG_HOME, or XDG_CACHE_HOME depending on what semantic meaning it has. -- Regards, Dimitri. 98 sleeps till Christmas https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. -- 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
