[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packaging Slurm
Re: Packaging Slurm
Fri, 18 Mar 2022 18:16:40 +0100
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Jean-Christophe HAESSIG <email@example.com> skribis:
> # strace -f -E GUIX_EXECUTION_ENGINE=fakechroot -E
> /opt/slurm/sbin/slurmdbd -D
> The program hangs from there and is inoperative. The socket to the
> database, which is in mode ugo+rwx is successfully used once, then the
> program fiddles with its groups, gid, uid and then can't open it
> anymore. I see that the /tmp/guix-exec-xxxx directory is created with
> 0700 rights, which means it cannot be traversed anymore when the uid of
> the program has changed.
Woow, interesting. Clearly relocatable packs were primarily intended
for “regular” programs (not daemons), which is why you’re making these
interesting discoveries. :-)
Off the top of my head, I’m not sure what the solution could be. If you
feel so inclined, you can take a look at run-in-namespace.c in Guix,
which implements those execution engines.
>> Where “battle from /gnu/store” is the chicken-and-egg when booting,
>> right? (That is, if /gnu/store is on NFS, then how do you boot.)
> Sure, it is even a problem with guix on a foreign distro, if you need
> some of the software to be managed locally and the rest by shared nfs.
> My best bet would be to have guix recompiled to use an alternate
> location as the store and the statedir, have it manage the local system
> and let regular users take advantage of substitutes. I don't feel this
> would be straightforward however.
Indeed; in general, using a non-standard store directory is a bad idea,
for many reasons (no substitutes, risks of failing builds just because
of the different store directory length, etc.).
I wonder if there might be a solution where you’d overlay the local
/gnu/store on top of the NFS-mounted store, something like that. But I
don’t have the full picture of the setup you have.