Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 640744 - x11-misc/x11vnc init script is incompatible with x11-misc/sddm display manager
Summary: x11-misc/x11vnc init script is incompatible with x11-misc/sddm display manager
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Alexander Tsoy
Keywords: NeedPatch
Depends on:
Reported: 2017-12-11 19:45 UTC by Paul VG
Modified: 2019-06-01 06:26 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Paul VG 2017-12-11 19:45:33 UTC
The SDDM display manager apparently randomizes the filename of the Xauthority file on each boot, placing it in /var/run/sddm

The current openrc init script packaged with gentoo's x11-misc/x11vnc cannot "guess" where Xauthority is when the display manager is SDDM, and so fails to run on boot.

Upstream, SDDM has no plans to alter this "feature" and instead recommends that x11vnc be executed from within the file:

Their discussion is here:

I currently have the init script working by deleting all the lines that test for xauth and check if a file exists in '/var/run/sddm/' but that doesn't seem to me to be good practice.  Neither is good practice, I think, to edit startup scripts in unique program locations that I'll forget about in two weeks.

I could start up the vnc server through the wm's application autostart menu, but I would rather vnc's execution be independent of any logins.

Any ideas? Maybe an alteration in the init script to test for SDDM's Xauthority file? I tried, but the scripting logic in '/etc/init.d/x11vnc.init.d' was making me seasick. I'm too new at this. Still, I will provide the init I edited if requested.

Comment 1 Paul VG 2018-02-08 23:37:59 UTC
I experimented with the solution of using the Xsetup file to launch x11vnc.  It was documented in the link I provided.  It works as expected, but the Xsetup file is quietly overwritten with a blank file each time sddm is emerged, such as in an update.  The helper program etc-config does not alert the user about this change either, supposedly because the location of Xsetup is outside etc-config's sphere.
Comment 2 Pacho Ramos gentoo-dev 2019-02-24 10:25:06 UTC
please retry with 0.9.16
Comment 3 Remy Blank 2019-04-18 10:07:55 UTC
This issue still exists with 0.9.16-r1.
Comment 4 Wilson M. Michaels 2019-04-29 17:25:11 UTC
My experience trying to update the x11-.../... packages marked stable a few days ago may provide a clue to resolving this problem.
My temporary solution is to:
   package.mask =x11-base/xorg-server-1.20.4 (The newly stable version)
   unmerge the driver modules my system uses (x11-drivers/xf86-...)
   emerge -1uvd x11-base/xorg-server which will pull in:
       =x11-base/xorg-server-1.20.3 (The previous version that works)
       x11-drivers/xf86-... used by my system
The remaining x11-.../... remain the recently stablized packages.

Description of problem solved by above:
Version x11-base/xorg-server-1.20.4 was marked stable in the past few days (along with additional x11-.../... packages). I emerged @world which installed stable x11-.../... packages. I rebooted to a black screen and working mouse pointer. Xorg.log stalls trying to start sddm with "Failed to open authorization file: /var/run/sddm/<random name>". The file actually exists, contains a Magic Cookie, and is owned by ssdm:ssdm.

Trying to update the world again with:
emerge -avu --newuse --deep --autounmask-backtrack=y --autounmask-write  @world
Emerge wants to remove my mask of =x11-base/xorg-server-1.20.4 so I didn't do something exactly right.

Bottom line:
  =x11-base/xorg-server-1.20.4 broke my system
  =x11-base/xorg-server-1.20.3 fixed it.  
  The changes made between the 2 may help find a solution. 
  Stable x11-misc/sddm-0.18.0 is installed.
Comment 5 Wilson M. Michaels 2019-04-30 18:41:55 UTC
Solved my bug when downgrading xorg-server:
  add --autounmask-keep-masks to the emerge options
That will take care of emerging the x11-drivers/xf86-... use by the downgraded version of xorg-server.

I did:
  edit file package.mask to add =x11-base/xorg-server-1.20.4

  emerge -av --update --newuse --deep --autounmask-backtrack=y --autounmask-write --autounmask-keep-masks --keep-going @world