Short Linux Guides

All things Linux that don't deserve more than one page each!

X11VNC SystemD Service XUbuntu 18.04 (LightDM)

Have you always wanted to remote into your Linux both with VNC on the same XServer as the desktop is current running on? It's a common issue that most VNC software start new XSessions when all you want to see is what is currently displaying on the screen. 

That's where X11VNC comes in.

X11VNC allows you to VNC into an existing XSession so that you can see what is currently being displayed on your Linux box's output. The only issue is that if you want the VNC server running all the time you'll have implement your own script to start it up on boot.

Looking around I found a few guides here and there for setting X11VNC up correctly for Ubuntu 18.04 as a SystemD service however most were outdated or had annoying issues such as the SystemD unit hanging.

Note: if you have not done so already you'll need a password for your VNC server: x11vnc -storepasswd

Using an amalgamation of knowledge from a lot of different places I came up with my own Unit script. 

  1. Use your favourite editor and create a new file: sudo nano /etc/systemd/system/x11vnc-h.service (I called my service x11vnc-h just to be different from the existing script)
Description=x11vnc VNC Server for X11

ExecStart=/usr/bin/x11vnc -auth /var/run/lightdm/root/:0 -display WAIT:0 -forever -shared -rfbauth /home/user/.vnc/passwd -rfbport 5900
ExecStop=/usr/bin/killall x11vnc


Now the magic here is Type=simple. This little type switch will stop the unit hanging when you go to start it using the normal forking mode. Another useful part of the unit are the restart switches which make sure that the VNC server is always up and restarts if it crashes.

Note: -rfbauth is the path to the VNC password file that you generated earlier.

Note: If you're an Arch user running LightDM you might not have anything inside the /var/run/lightdm/ folder to which I have not found a fix for just yet.

Update 22/Dec/2018: On further testing the path may not exist on Manjaro / Arch based systems correctly but the same path still seems to work.

After you've saved your unit script reload SystemD with systemctl daemon-reload and fire it up with systemctl start x11vnc-h.

If all went well you should have an output like this: systemctl status x11vnc-h

● x11vnc-h.service - x11vnc VNC Server for X11
   Loaded: loaded (/etc/systemd/system/x11vnc-h.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-12-21 21:12:29 GMT; 3s ago
  Process: 23528 ExecStop=/usr/bin/killall x11vnc (code=exited, status=0/SUCCESS)
 Main PID: 23530 (x11vnc)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/x11vnc-h.service
           └─23530 /usr/bin/x11vnc -auth /var/run/lightdm/root/:0 -display WAIT:0 -forever -shared -rfbauth /home/user/.vnc/passwd -rfbport 5900

Dec 21 21:12:29 xee x11vnc[23530]: 21/12/2018 21:12:29
Dec 21 21:12:29 xee x11vnc[23530]: 21/12/2018 21:12:29 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/2560
Dec 21 21:12:29 xee x11vnc[23530]: 21/12/2018 21:12:29
Dec 21 21:12:29 xee x11vnc[23530]: 21/12/2018 21:12:29 Listening for VNC connections on TCP port 5900
Dec 21 21:12:29 xee x11vnc[23530]: 21/12/2018 21:12:29 Listening for VNC connections on TCP6 port 5900
Dec 21 21:12:29 xee x11vnc[23530]: 21/12/2018 21:12:29 listen6: bind: Address already in use
Dec 21 21:12:29 xee x11vnc[23530]: 21/12/2018 21:12:29 Not listening on IPv6 interface.
Dec 21 21:12:29 xee x11vnc[23530]: 21/12/2018 21:12:29
Dec 21 21:12:29 xee x11vnc[23530]: The VNC desktop is:      xee:0
Dec 21 21:12:29 xee x11vnc[23530]: PORT=5900

Manjaro i3 - GitKraken failing due to unset SSH_AUTH_SOCK

I came across on an annoying issue with the SSH_AUTH_SOCK variable not being set correctly on my Manjaro i3wm work machine. This is an issue as the variable needs to be set in order to use GitKraken properly. It turns out that the software wasn't even being correctly loaded in the first place on the community i3 version of Manjaro probably due to the minimalist intended design so I set out to fix that.

First of all we actually need gnome-keyring so using a terminal run pacman -S gnome-keyring to install it.

Next up we need to make some PAM changes so following this guide on the Arch Linux forums I changed the following file:

# /etc/pam.d/login

auth       required
auth       requisite
auth       include      system-local-login
auth       optional              #<-- Add this line
account    include      system-local-login
session    include      system-local-login      
session    optional auto_start   #<-- Add this line

The two important lines highlighted in the file load the gnome keyring pam libraries.

Next we need to add a few lines to the .xinitrc file which can be found in your user's home.

# /home/user/.xinitrc

# get_session(){
#   ... bla ...
# }

# Start Gnome keyring
dbus-update-activation-environment --systemd DISPLAY
eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)

# exec ...

The lines between the dots are added just after the get_session() function but before the exec call to start i3wm. An extra line is also needed in the form of a dbus-update call for i3wm specific reasoning.

After that is sorted we need to add a few lines to the Bash .profile file in order to export the variable for Bash sessions.

# /home/user/.profile

# At the bottom of the file
# ...

# Start gnome ssh keyring daemon
if [ -n "$DESKTOP_SESSION" ];then
    eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
    export SSH_AUTH_SOCK

At the bottom of the file add the above 5 lines which makes sure that the keyring daemon is actually running and exports the variable we require for GitKraken (and various other programs).

You can now safely restart the system or logout and back in again to load everything up and we should be good to go. We can of course test this by echoing out the variable in the terminal like so:

[user@machine ~]$ echo $SSH_AUTH_SOCK


Node 13 / 12 pgk terminal-kit error cannot find module xterm.generic.js

Have you ever tried to build a terminal-kit app in Node using pkg to generate a nice easy application binary but instead face this error?

Error: Cannot find module './termconfig/xterm.generic.js'
Require stack:
- /snapshot/remotecow/node_modules/terminal-kit/lib/Terminal.js
- /snapshot/remotecow/node_modules/terminal-kit/lib/termkit.js
- /snapshot/remotecow/app/term.js
- /snapshot/remotecow/app/commands.js
- /snapshot/remotecow/app/app.js
1) If you want to compile the package/file into executable, please pay attention to compilation warnings and specify a literal in 'require' call. 2) If you don't want to compile the package/file into executable and want to 'require' it from filesystem (likely plugin), specify an absolute path in 'require' call using process.cwd() or process.execPath.
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:795:15)
    at Function.Module._resolveFilename (pkg/prelude/bootstrap.js:1287:46)
    at Function.Module._load (internal/modules/cjs/loader.js:688:27)
    at Module.require (internal/modules/cjs/loader.js:850:19)
    at Module.require (pkg/prelude/bootstrap.js:1166:31)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.createTerminal (/snapshot/remotecow/node_modules/terminal-kit/lib/Terminal.js:159:18)
    at terminal (/snapshot/remotecow/node_modules/terminal-kit/lib/termkit.js:103:18)
    at Object.get [as terminal] (/snapshot/remotecow/node_modules/lazyness/lib/Lazyness.js:48:16)
    at new Term (/snapshot/remotecow/app/term.js)

I did today! And after a bunch of Googling I still couldn't find the answer instead one vague reference to some requires that Terminal-Kit is doing in a not so great to parse way.

Luckily after much experimenting I managed to fix it.

Simply add the following to your package.json and also remember to add it to your pkg build command so you end up with something like this: pkg package.json -t node12-linux

  "pkg": {
    "assets": "node_modules/terminal-kit/**/*"

And there you have it, headache over and your executable should now stop throwing errors.