You are not logged in.

#1 2016-12-28 16:30:46

jwhendy
Member
Registered: 2010-04-01
Posts: 621

[SOLVED] Proper enabling of bumblebeed; does not start at boot

I have intel/nvidia graphics and checking the wiki find these instructions (abbreviated):
- install bumblebee, mesa, xf86-video-intel, nvidia
- add user to the bumblebee group
- enable the bumblebeed service

I've met the above criteria (minus no xf86-video-intel as I had issues and use the kernel modesetting driver) but bumblebeed doesn't seem to start on boot for me.

$ groups
lp wheel uucp bumblebee audio input jwhendy

$ sudo systemctl is-enabled bumblebeed
enabled

Upon fresh boot:

$ sudo systemctl status bumblebeed
[sudo] password for jwhendy: 
  bumblebeed.service - Bumblebee C Daemon
   Loaded: loaded (/usr/lib/systemd/system/bumblebeed.service; enabled; vendor preset: disabled)
   Active: inactive (dead)

$ dmesg |grep bb
[    7.026481] pci 0000:00:1f.2: reg 0x1c: [io  0x70b8-0x70bb]

Then I manually start bumblebeed and check again:

$ sudo systemctl start bumblebeed

$ sudo systemctl status bumblebeed
  bumblebeed.service - Bumblebee C Daemon
   Loaded: loaded (/usr/lib/systemd/system/bumblebeed.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2016-12-28 10:21:36 CST; 5min ago
 Main PID: 782 (bumblebeed)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/bumblebeed.service
           └─782 /usr/bin/bumblebeed

Dec 28 10:21:36 arch_zbook systemd[1]: Started Bumblebee C Daemon.
Dec 28 10:21:36 arch_zbook bumblebeed[782]: [   97.324065] [INFO]/usr/bin/bumblebeed 3.2.1 started

$ dmesg |grep bb
[    7.026481] pci 0000:00:1f.2: reg 0x1c: [io  0x70b8-0x70bb]
[   97.338190] bbswitch: version 0.8
[   97.338193] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
[   97.338197] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEGP.DGFX
[   97.338854] bbswitch: detected an Optimus _DSM function
[   97.338913] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on
[   97.339836] bbswitch: disabling discrete graphics

Am I doing something incorrectly?

Last edited by jwhendy (2017-01-11 20:37:54)

Offline

#2 2017-01-07 09:42:16

lahwaacz
Wiki Admin
From: Czech Republic
Registered: 2012-05-29
Posts: 699

Re: [SOLVED] Proper enabling of bumblebeed; does not start at boot

bumblebeed.service is pulled in by graphical.target, which is usually started by display managers.

Offline

#3 2017-01-07 15:56:35

jwhendy
Member
Registered: 2010-04-01
Posts: 621

Re: [SOLVED] Proper enabling of bumblebeed; does not start at boot

@lahwaacz: gotcha. This isn't specified in the wiki, and given that this is Arch, my suspicion is that a lot of users (including myself) just login and startx manually. What would be the recommended way in this case?

Should I symlink something else as the graphical.target to represent that X has started? If you point me in the right direction, I'd be happy to add this information to the wiki. For example, as sub-section like "For users manually starting X..."? From my own digging, this thread might indicate that I should make bumblebeed dependent on multi-user.target, not graphical.target? Then again, if multi-user.target is the login prompt in TTY, I'm not sure that's when bumblebee should start as there would be no X yet. It seems like systemd would account for not everyone using a display manager? I've just always rolled old school.

Add the systemctl start command in .xinitrc?

Thanks for the input; this already makes much more sense (even if I don't know the solution quite yet)!

Offline

#4 2017-01-07 16:59:21

lahwaacz
Wiki Admin
From: Czech Republic
Registered: 2012-05-29
Posts: 699

Re: [SOLVED] Proper enabling of bumblebeed; does not start at boot

jwhendy wrote:

Should I symlink something else as the graphical.target to represent that X has started?

That would have to be X itself, which itself is not that simple, but the real problem is doing a system-wide action from the user instance.

Looking at the systemd.special man page, I see that graphical.target is intended "for setting up a graphical login screen". I wonder what bumblebee has to do with that? Logically that should be just multi-user.target, assuming that bumblebeed can start without the connection to X. You can try to start bumblebeed.service from the console to see if there is a chance for this to work.

Offline

#5 2017-01-07 17:03:54

lahwaacz
Wiki Admin
From: Czech Republic
Registered: 2012-05-29
Posts: 699

Re: [SOLVED] Proper enabling of bumblebeed; does not start at boot

Actually, you've got that confirmed from here. That fix seems to be sitting in the develop branch for couple of years now...

Offline

#6 2017-01-07 19:45:35

jwhendy
Member
Registered: 2010-04-01
Posts: 621

Re: [SOLVED] Proper enabling of bumblebeed; does not start at boot

Ha! Bizarre. Thanks for the hunting. Marking as solved. Going to try bumblebee-git from AUR as it calls for the develop branch.

Offline

#7 2017-01-11 20:27:15

jwhendy
Member
Registered: 2010-04-01
Posts: 621

Re: [SOLVED] Proper enabling of bumblebeed; does not start at boot

Edit: Bah. I'm leaving the below, but found out the conundrum. This post mentioned replacing graphical.target with multi-user.target in the original service file and enabling... out of curiosity I tried disabling and re-enabling bumblebeed.service now that I've replaced the Community package with bumblebee-git from AUR.

$ sudo systemctl disable bumblebeed
Removed /etc/systemd/system/graphical.target.wants/bumblebeed.service.
[jwhendy@arch_zbook ~]$ sudo systemctl enable bumblebeed
Created symlink /etc/systemd/system/multi-user.target.wants/bumblebeed.service → /usr/lib/systemd/system/bumblebeed.service.

So a couple of learnings (for me):
- removing/replacing a package would appear not to replace the enabled symlinks
- I dind't realize that enabling a unit always meant putting a link to it *inside* a target of some sort.

Tl;dr: you have to redo the enabling to get the changed target to correct itself.

----------
Spoke too soon. Here's the status:

- switched to bumblebee-git from AUR which contains the following unit:

$ cat /lib/systemd/system/bumblebeed.service 
[Unit]
Description=Bumblebee C Daemon

[Service]
Type=simple
ExecStart=/usr/bin/bumblebeed --use-syslog
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target

So far so good, as it depends on multi-user.target.

- next, I checked on default targets, having never messed with them before. The wiki on targets says the default is graphical.target. Indeed I find:

$ ls -l /lib/systemd/system/default.target 
lrwxrwxrwx 1 root root 16 Dec  7 14:33 /lib/systemd/system/default.target -> graphical.target

The wiki also provides a command to set it... which I did:

$ history |grep target
480  sudo systemctl set-default -f multi-user.target

My default.target is still symlinked to graphical.target. I realize I can replace it, I'm just pointing out my experience.

- bumblebeed is still not starting at boot/startx, though.

$ sudo systemctl status bumblebeed
bumblebeed.service - Bumblebee C Daemon
   Loaded: loaded (/usr/lib/systemd/system/bumblebeed.service; enabled; vendor preset: disabled)
   Active: inactive (dead)

I looked in my journal and appear to have reached the multi-user target from what I see:

$ journalctl -b
Jan 11 14:09:13 arch_zbook systemd[1]: Reached target Login Prompts.
Jan 11 14:09:13 arch_zbook systemd[1]: Reached target Multi-User System.

My questions:
- does the last finding indeed indicate I reached the multi-user.target?
- is the unit correctly depending on the multi-user.target?
- if so, why is bumblebeed still not starting?

As an aside:
- why does the set-default target command not replace the symlink of default.target -> graphical.target?

Offline

Board footer

Powered by FluxBB