Can't use bumblebee from 32bit subsystem anymore

[microcz]

I am using 64bit system with 32bit bundled subsystem. In both I have bumblebee installed, but I have only one 64bit kernel.
I used to start daemon on 64bit system and do:

optirun 64bit_application
schroot -p -- optirun 32bit_application

for 64bit/32bit application and everything worked perfectly up to bumblebee 3.0.

Now the 64bit optirun is OK, but the 32bit one works no more. Always when I want to use optirun in 32 bit I'll receive following error.

schroot -p -- optirun glxinfo

ERROR]The Bumblebee daemon has not been started yet or the socket path /var/run/bumblebee.socket was incorrect.
[ERROR]Could not connect to bumblebee daemon - is it running?

I am in the group bumblebee and even when I hard link subsystem's /var/run to main system's /var/run...so bumblebee.socket can be seen in 32bit subsystem, the error remains the same :(.

[Lekensteyn]

Please run it with -vv for more debugging information. Does /var/run/bumblebee.socket exist in the chroot? Hardlinking directories won't work btw.

[Thulinma]

As a workaround I would suggest changing the socket path to be inside the subsystem. You should use seperate bumblebee.conf files to make this all work correctly, and make sure they use the same socket. (And you should only run one daemon, from outside of the subsystem!)

[microcz]

Thank you for quick response, this is output of optirun -vv in 32bit subsystem:

DEBUG]Reading file: /etc/bumblebee/bumblebee.conf
[DEBUG]Process /sbin/modinfo started, PID 4165.
[DEBUG]Hiding stderr for execution of /sbin/modinfo
[DEBUG]SIGCHILD received, but wait failed with No child processes
[DEBUG]Process /sbin/modinfo started, PID 4166.
[DEBUG]Hiding stderr for execution of /sbin/modinfo
[DEBUG]SIGCHILD received, but wait failed with No child processes
[DEBUG]Active configuration:
[DEBUG] bumblebeed config file: /etc/bumblebee/bumblebee.conf
[DEBUG] X display: :8
[DEBUG] LD_LIBRARY_PATH: /usr/lib/nvidia-bumblebee:/usr/lib32/nvidia-bumblebee
[DEBUG] Socket path: /var/run/bumblebee.socket
[DEBUG] VGL Compression: proxy
[DEBUG]optirun version 3.0 starting...
[ERROR]The Bumblebee daemon has not been started yet or the socket path /var/run/bumblebee.socket was incorrect.
[DEBUG]Socket closed.
[ERROR]Could not connect to bumblebee daemon - is it running?

The /var/run is hardlinked from 64bit system into the subsystem and..

ls /opt/arch32/var/run | grep bumblebee.socket

shows:

bumblebee.socket

BUT

sudo chroot /opt/arch32
ls /var/run | grep bumblebee.socket

shows nothing :(.

I don't know if it is correct to hardlink /var/run from 64bit to 32bit but before Bumblebee 3.0 I didn't have to do that and optirun worked with only 64bit deamon running.

[microcz]

Thank you Thulinma, but how can I tell to bumblebee where it should store the socket? In my /etc/bumblebee/bumblebee.conf I haven't found such a section.

[Lekensteyn]

@microcz Use the --socket option of bumblebeed

[microcz]

I'll give it a try and when I come home from work I'll inform you whether it helped or not. I thank you both very much.

[microcz]

I've tried start bumblebee in x86_64 with:

sudo bumblebeed --socket /opt/arch32/var/run

but following error has occured:

[ERROR]Cannot open or write pidfile /var/run/bumblebeed.pid.

When I run bumblebee with:

sudo bumblebeed --socket /var/run

theres is no problem. It seems that it cannot find pid file, in both cases pid file is created in /var/run.

[Lekensteyn]

If you're running in a chroot, use --pidfile /your/chroot/var/run/bumblebee.pid

[Lekensteyn]

I don't believe that --socket /some/directory works, you must use a path to a file, i.e. --socket /var/run/bumblebee.pid (create dirs first)

[microcz]

Thank you, now bumblebee started:

sudo bumblebeed --socket /opt/arch32/var/run/bumblebee.pid
[INFO]bumblebeed 3.0 started

And pid file is located correctly in 32bit subsystem, but after:

schroot -p -- optirun glxinfo

There is following error again :(

[ERROR]The Bumblebee daemon has not been started yet or the socket path /var/run/bumblebee.socket was incorrect.
[ERROR]Could not connect to bumblebee daemon - is it running?

[microcz]

I found it, with your help of cause, IT WORKS NOW :))...

Bumblebeed creates two files:

1. bumblebee.pid
2. bumblebee.socket

with command --socket can be location of socket file changed, but the pid file remains in default directory /var/run/pid, all i needed was to do:

sudo bumblebeed --socket /opt/arch32/var/run/bumblebee.socket

THANK YOU VERY MUCH, the problem seems to be SOLVED.

I want to ask one more question, how to instruct bumblebeed to use --socket parameter, when starting it as a daemon during system startup, because there only the names of daemons can be specified in arch's rc.conf.

[Lekensteyn]

bumblebeed in DAEMONS just starts /etc/rd.d/bumblebeed. You can edit options in that file. It will get overwritten with each update though.

[Thulinma]

@Lekensteyn Maybe we should make this a config option, as well?

[Lekensteyn]

In that case it should be a [bumblebeed] option. At the moment, optirun still reads some settings from the [bumblebeed] section (driver/ldpath). Those settings can be read through the protocol, but how are we adding this option to the client then? Use two SocketPath settings for the optirun and bumblebeed section?

[Thulinma]

Technically this would be the only option that really applies to both server and client side... the rest would, in theory, go through the new protocol we have planned.

[Lekensteyn]

In cases like this chroot thing, we can use separatate socket paths. It appears more natural to me.

[Thulinma]

Not really. The daemon would never "see" the config of the chrooted client, after all :-)

[Lekensteyn]

What about hardlinks?

[Thulinma]

Does that work? The above posts seem to indicate "no".

[microcz]

The hardlinks not worked for me, but that does not mean that I was doing it right, i did:

su root
cd /opt/arch32/var
rm -r run
ln -f /var/run* .

But somehow I couldn't see the content of var/run when chrooted. Maybe the parameter should be part of the client, with this it will be possible to tell 64bit optirun where to search for socket, while the jailed 32bit will use the default path.

[Lekensteyn]

You cannot hardlink directories, but I now get it why it would be nonsensible. The only way to justify that SocketPath is only defined in the bumblebeed section and not optirun is by saying that the socket path is used for communication with bumblebeed.