[SOLVED] Starting x11vnc server at boot in Mint19

[xGuy]

I'm trying to access my Mint 19 PC from a client PC running Mint 17.3 with both using x11vnc.

On the Mint 19 system if I run the following command in a root shell it works perfectly :-

exec /usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /home/guy/.vnc/passwd -rfbport 5900 -shared

But when I include this call in the file /etc/init/x11vnc.conf as follows :-

# description "Start x11vnc at boot"
description "x11vnc"
start on runlevel [2345]
stop on runlevel [^2345]

console log

respawn
respawn limit 20 5

exec /usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /home/guy/.vnc/passwd -rfbport 5900 -shared

and reboot, no x11vnc processes are automatically started.

In the reverse direction from Mint 19 to 17.3 everything works perfectly and the x11vnc processes are automatically started at boot time..

Something must have changed in the init system I would think but I don't know where to start looking! I would really appreciate some help with this.

[thx-1138]

.......................................
Something must have changed in the init system I would think but I don't know where to start looking! I would really appreciate some help with this.

Yeap. Have a look here...

[xGuy]

Many thanks - I followed all the steps and after manually starting the service all was fine.
But on reboot there was no joy.
I made a call of systemctl -t service --state failed and the output was :-

UNIT LOAD ACTIVE SUB DESCRIPTION
x11vnc.service loaded failed failed start x11vnc at startup

Is there perhaps something recorded in a log or journal file somewhere that might give a clue to the failure?

If only I was more familiar with the system!

Thanks again for the help. Mint 19/Ubuntu 18.04 is not easy going for me.

[xGuy]

This is not a solution so I am not going to mark my post as solved.

However it is a workaround - perhaps not very elegant but I'll post it in case it helps anyone else with the same issue.

The task is to get the x11vncserver running on the remote Mint19 PC so that the Mint 17.3 PC can run an x11vnc client session.

I have OpenSSH Server and OpenSSH Client running on both machines.

On the Mint 17.3 system from a non-root terminal session I enter :-

ssh -t guy@192.168.0.35 'sudo systemctl start x11vnc.service'

It prompts first for user guy's password and then for the sudo password

After which the x11vnc server service is started on the MInt 19 PC and a subsequent vnc connection attempt from Mint 17.3 to Mint 19 works as expected.

[thx-1138]

.....................................

...i don't have a 2nd system here to actually test such, but have you further googled at how to do it under systemd?
http://www.lueckdatasystems.com/Success ... nial-Xerus
https://unlockforus.com/remotely-contro ... vnc-setup/
I find it kinda hard that none of those would work...

[xGuy]

Thanks - there seem to be some subtle variances in all those approaches. I think I'll take a break from this for a while as I can move forward using my workaround. I've set up a desktop launcher for the ssc command so the first time I need to make a vnc connection (on any particular load of the server) I have to click first on that launcher and then on the launcher for the vnc command. Any subsequent connections only need the vnc command. So it's not too onerous.

However, I get the feeling that what works on Ubuntu 16.04/Mint 18 doesn't on Ubuntu 18.04/Mint 19.

This post :- http://c-nergy.be/blog/?p=8984 says right at the end :-

In a few weeks, we will post something about VNC and Ubuntu 18.04, if you can wait till there…this might be a acceptable solution for you

Although the date of that was getting in for three months ago!

[thx-1138]

...thing is, the init changed from 17 to 18, not from 18 to 19, and thereby the solution should be the same under both of those 2...
(the 'subtle variances' are exactly what will make the difference, systemd is rather picky...)
I'd try the unlockforus variant above myself...

[smurphos]

Another approach if you have SSH access is to not have x11vnc run as a service at all but just start it on demand for that particular session and tunnel it back to the client.

E.g. ssh xxx.xxx.xxx.xxxx -L 5900:localhost:5900 "x11vnc -safer -localhost -once -timeout 60 -nopw -auth guess -display :0 -noxdamage"

Having run the command from the client you just direct your VNC client software to link to Localhost:5900.

As written this command will start x11vnc, then if no Client connects within 60 seconds it will terminate, and will also terminate as and when the remote session is ended.

At the moment I use this regularly to connect to an 18.3 machine. I've not tested it with the server running on 19.

[xGuy]

I went through the steps in the unlockforus post and it worked!

Many thanks indeed.

I did have one heartstopping moment at the very last command before rebooting which was :-

sudo systemctl enable graphical.target

Although the result in $? was 0, there was a lot of output as follows :-

The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified.

Should I be concerned about this?

Thanks again.

[thx-1138]

Really glad it was sorted eventually - was really curious if something extra had changed even further under 19 compared to 18...
Don't ask me for the rest though, lol - i'm also trying (very) slowly to adapt to systemd's nuances...

[xGuy]

Well, you are streets ahead of me. When I get some time I must try to delve more into the Linux internals. Trouble is it can take nearly half a lifetime to really get to understand the inner workings of an OS and that's if it is your full time job. Unfortunately I don't have that much time left! Plus it's a moving target.

Thanks again and also to smurphos for the suggestion.

I'll mark the thread as SOLVED.