Magic Castle triggering usage of dbus-launch from compatability layer

[ocaisa]

One of things that Magic Castle does is allow you to start a Desktop session via JupyterHub. This triggers the command

dbus-launch websockify -v --web /opt/jupyterhub/lib64/python3.6/site-packages/jupyter_desktop/share/web/noVNC-1.1.0 --heartbeat 30 --unix-target /tmp/tmpmkuclos5/vnc-socket 38569 -- /bin/sh -c cd /home/ocaisa && vncserver -verbose -xstartup /opt/jupyterhub/lib64/python3.6/site-packages/jupyter_desktop/share/xstartup -SecurityTypes None -rfbunixpath /tmp/tmpmkuclos5/vnc-socket -fg -nolisten tcp

but for our compatability layer this command is failing with a bomb of /cvmfs/pilot.eessi-hpc.org/2021.03/compat/linux/x86_64/usr/bin/dbus-daemon processes and lots of errors in the logs about

Apr  8 14:37:15 gpu-node1 dbus-daemon[11779]: Cannot initialize inotify

[ocaisa]

From https://bbs.archlinux.org/viewtopic.php?pid=1709269#p1709269 it looks like we are triggering some kind of recursive inclusion, which I guess must come from our init scripts?

[bedroge]

I have no idea if this is related to your issue, but I did just see that the list with host symlinks that Bart provided (and which they use at CC) a while ago also contains run/dbus:
#15 (comment)
We don't have that one.