Re: trying to run tightvnc as a systemd service on Debian/Bookworm

I've been using TightVNC for some time without issue, but then I've 
rarely had a need to connect to a Linux workstation. Usually I use ssh 
and work from the command line for servers. I use ssh tunnelling to 
provide a secure connection for VNC. However, I'm now looking at vino 
rather than TightVNC because the TightVNC issues seem to be related to 
launching a new instance of the desktop.

The change in TightVNC licensing may (or may not) be why Raspberry Pi OS 
now defaults to RealVNC. However, thanks the old licence, TightVNC could 
be forked and continued as a FLOSS project if there is interest. At this 
point, it doesn't look like it will be from me.

The advantage of Vino is that it operates more like the Windows TIghtVNC 
server, showing you the current desktop instead of launching a new one. 
This is a double-edged sword in my case, because my primary workstation 
has a 4k screen while the laptop I'd be using to remote-in can't even do HD.

re. multiple NICs. You describe one situation where you have, if I 
understand it correctly, a server with multiple addresses (such as a web 
server). However there is also the case where you want just one address 
for both NICs. This kind of situation demands that you go through the 
same subnet with the switch doing the bonding. This requires the switch 
to understand bond-mode 802.3ad. It works on the server in question 
using Network Manager but not with systemD networking (at least when I 
tried it a couple of years ago - I haven't gone back to revisit the 
situation).

I do use systemD networking on my laptop and it automatically uses the 
wired connection if available but fails over to the wifi. However the 
ecosystem still isn't well developed, so this can involve pulling of 
hair and gnashing of teeth at times (e.g. when connecting to new wifi 
network). That's probably why Network Manager remains the most popular 
option. It simply works these days.


On 2022-09-14 02:32, Tony Su wrote:
> This is from the TightVNC website and doesn't look promising
> https://www.tightvnc.com/licensing-server-x11.php
>
> Based on that, I wouldn't recommend building a future on TightVNC.
> Apparently they're forking and closing source. The TightVNC available
> for free use is apparently outdated and unsupported.
> Do you have any reason to prefer TightVNC? Is there any other flavor
> you might consider?
> TigerVNC is considered the most suitable for business and serious use
> because it implements security options business use requires like
> support for better encryption,
>
> I have no idea what flavors the Debian community prefers but if you
> want just a brief taste of what TigerVNC is about without actually
> installing openSUSE
> The following is the VNC documentation on openSUSE
> https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-vnc.html
>
> I found that the official openSUSE documentation was only adequate for
> basic VNC use, I wrote the following which is a collection of
> additional TigerVNC features, procedures and technical info I felt was
> necessary to really use it
> https://en.opensuse.org/User:Tsu2/remote_administration_VNC
>
> Bottom line, TigerVNC is a good choice but it can get complicated. It
> helps to learn how to set up VNC correctly, but some people prefer old
> setups and if they ever need help would need to find someone who knows
> the old ways or have to figure out everything on their own. And,
> there's lots of good TigerVNC documentation but you may have to study
> it all to really understand it properly.
>
> Re setting up multiple NICs, there may be a lot that's misleading in
> what you set up.
> That's another topic altogether, but you should know
> NICs can be bonded so both can be used to enhance throughput but has
> to be done properly. This requires advanced network configuration.
> The NICs must be on separate networks. On ethernet networks only one
> data packet can be on the wire at a time so multiple NICs on the same
> network won't improve throughput although it might enhance redundancy.
> Be careful setting up multiple NICs, particularly if they're not
> bonded. If a network connection leaves the machine using one NIC and
> the response arrives on the other NIC the packets may be rejected and
> cause resending until the response returns to the correct NIC.
>
> BTW - You should know that systemd is never spelled with any capital
> letters, no matter the situation (like at the beginning of a
> sentence).
> And, if a systemd unit file exists for a particular functionality
> that's generally the main reason to prefer not invoking a SysVinit
> file. In general, it's not considered a particularly bad sin to invoke
> SysVinit processes so go ahead and don't feel guilty about it.
>
> Tony
>
> On Tue, Sep 13, 2022 at 9:20 PM Gary Dale <[email protected]> wrote:
>> On 2022-09-11 23:24, Tony Su wrote:
>>> Since no one has answered, although I am more familiar with TigerVNC
>>> running on openSUSE, I'll answer as best I can acknowledging there are
>>> differences but enough that's the same to put you on the right path.
>>> I'll try to avoid any landmines that I know exist when recommending
>>> something that is not likely the same on your setup.
>>>
>>> First,
>>> You're working on a pre-release version of Debian. Know that if you
>>> want to be that far ahead of the main Debian community (current is 2
>>> versions earlier), there won't be much documentation specific to your
>>> version of Debian so you'll be on your own a lot. If you prefer more
>>> help and a less buggy version of Linux, you should be instead working
>>> on Debian 10 which is the current official release or Debian 11 which
>>> is the next release... Not on Debian 12 (bookworm) which is 'way out
>>> there ahead of everyone. But, if you're adventurous and want to learn,
>>> keep doing what you're doing...
>> Actually, Debian 11 is the current (stable) release. Debian 10 is Old
>> Stable. Debian 12 isn't that far in advance because Testing is intended
>> to be the next Stable. Things have to get through Unstable before they
>> make it into Testing. Debian is built for stability.
>>> Usually when someone posts their problem and attempted solution, my
>>> first reaction is always to ask what guide or reference they're
>>> following. Even most experienced geeks know that no matter how skilled
>>> you are, if there is a ready solution is published somewhere that
>>> works, it's a slam dunk to copy and paste your way to success. Even if
>>> you're a genius, creating stuff from scratch is always going to be
>>> subject to simple or surprising mistakes.
>> Except that I've found in this case it doesn't work. I've had a similar
>> problem with my Raspberry Pi where I took the official release and
>> applied a SystemD .service file that supposedly works from a recent
>> Raspberry Pi howto that even used tightvnc server rather than Real VNC
>> which Raspberry Pi OS now uses and I got the same problem.
>>> I usually recommend a User try to look up the documentation for their
>>> distro as a main reference so that what you configure will be similar
>>> to other Users in that community. VNC in particular is particularly
>>> susceptible to being setup in numerous ways, some very old and
>>> sometimes crazy that would make your system look very different than
>>> other systems people normally build. If you want to live a solitary
>>> life of not benefiting from community help, go ahead and build your
>>> very unique creation. But, if you think you might want to ask the
>>> Debian community for help on something in the future, you're better
>>> advised to follow whatever is in the Debian User Manual if the topic
>>> exists... Even if the documentation is for an older version of Debian.
>> There are various guides telling you how to do this with Debian going
>> back decades. What I find disappointing is how little documentation the
>> tightvnc team provides. They've got a brilliant setup for Windows
>> machines but they seem to think us *nix users can figure it out.
>>
>> The Debian documentation on this is written for Gnome, not Plasma 5. And
>> while I'd be willing to try a Gnome desktop, it also doesn't work. I
>> went to the TightVNC list because the Debian lists are more general.
>>
>>> My last comment is that if you have a SysVinit command that works, you
>>> can always embed that command in a systemd service unit file, and it
>>> will work. systemd is designed that way, to be 100% (yes 100%)
>>> backwards compatible with SysVinit so all old scripts and commands
>>> should work just fine in systemd unless that function is for some
>>> reason removed which is fairly rare. Yes, add a few additional
>>> parameters to make sure that the service you're creating starts only
>>> when dependencies have been loaded and possibly are running and if
>>> there is anything you want to execute after your VNC service starts,
>>> insert those parameters, too. But note that this is a method of last
>>> resort.
>> It should but... SystemD will work with init.d scripts as a fallback but
>> I want an actual SystemD recipe. At this point this should be possible.
>> What seems to be the sticking point actually is the ~/.vnc/xstartup file
>> more than the vncserver.service. However, I note that you are actually
>> expected to use [email protected] (something to do with per-user
>> invocation?).
>>
>>   From what I've been reading, people using XFCE seem to have the most
>> luck. Gnome and Plasma 5 seem to be nightmares.
>>
>>> Oh, and I guess one more "last-last" comment... If this is your first
>>> time creating a systemd service, do you know how to do this properly?
>>> Although I wouldn't know the specifics without investigation because I
>>> use a different distro, I do know that on any distro there is one
>>> place where the default systemd units are located and there is another
>>> location where the User can add and modify systemd units. This is so
>>> that the User can confine his actions to a specific file location and
>>> not endanger the system by making some disastrous mistake that would
>>> be difficult to recover. Done properly, if a User creation could cause
>>> potential damage, if systemd recognizes the danger then the User
>>> creation is not activated. If the User wants to undo a creation, it
>>> only requires deleting the User unit file. No default unit files
>>> should be touched which means that no files should be accidentally
>>> deleted. The User is protected from making mistakes. But, only if the
>>> User creates new systemd Unit files the correct way.
>> I've previously worked with SystemD/Network and even contributed to the
>> documentation. That was when I learned that just because something
>> should work, doesn't mean it does work. In particular, I wanted to set
>> up two NICs to work together for double the throughput. This worked
>> under Network Manager but when I tried it under SystemD, it looked like
>> it worked (no errors) but the connection was slow and unreliable. I had
>> to revert to Network Manager. Same hardware, same drivers, just
>> different init systems.
>>
>>
>>> HTH,
>>> Tony
>>>
>>> On Sun, Sep 11, 2022 at 8:26 AM Gary Dale <[email protected]> wrote:
>>>> While I agree that systemd isn't perfect, there doesn't seem to be a lot of point in fighting it. While System V Init worked, it had some significant problems too. The current hybrid startup (using systemd to run init scripts) isn't going to be around forever.
>>>>
>>>> I'm not at the point of trying to use XFCE instead of KDE. I'd just like to be able to get it running first. I'm using sddm, not gdm.
>>>>
>>>> I'm pretty sure the tightvncserver allocates the next available port automatically unless you specify something else. In my case, that would be port 5901. Indeed, I can run the vncserver command multiple times and it ups the port number by 1 for each new instance.
>>>>
>>>>
>>>>
>>>> On 2022-09-10 23:45, Michael D. Setzer II wrote:
>>>>
>>>> Don't know the stuff they are trying to do with systemd??
>>>> Took something that worked fine, and trying to replace it with something that has issues.
>>>> I start my vncserver with rc.local in /etc/rc.d/rc.local
>>>> runuser -l msetzerii -c 'vncserver :79 -geometry 1600x845'
>>>> And it creates this process that works perfectly.
>>>> msetzer+    1389       1  0 09:37 ?        00:00:07 /usr/bin/Xvnc :79 -auth /home/msetzerii/.Xauthority -desktop setzco.dyndns.org:79 (msetzerii) -fp catalogue:/etc/X11/fontpath.d -geometry 1600x845 -pn -rfbauth /home/msetzerii/.vnc/passwd -rfbport 5979
>>>> ~/.vnc/xstartup has
>>>> #!/bin/sh
>>>> # Uncomment the following two lines for normal desktop:
>>>> unset SESSION_MANAGER
>>>> unset DBUS_SESSION_BUS_ADDRESS
>>>> exec  /bin/sh /etc/xdg/xfce4/xinitrc #   X11/xinit/xinitrc
>>>> [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
>>>> [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
>>>> xsetroot -solid grey
>>>> #vncconfig -iconic &
>>>> xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
>>>> startxfce4 &
>>>> #twm &
>>>> Didn't see your info specifying a port to use for the vnc?
>>>> I tried to do the systemd stuff, but never was able to get it to work. Have 5 machines in home that have vnc running on various ports on each, and have no isses with anything between them. Do use xfce instead of gnome options, since it didn't work with a local login and a vnc long at same time. tried various options for the gnome, but no luck. Old method has worked since Redhat 9 for me, and current machines running fc35 and one with fc36..
>>>> Well, Good Luck, Maybe someone else has had better luck, or knows the secrets.
>>>> On 10 Sep 2022 at 21:53, Gary Dale wrote:
>>>> Date sent:       Sat, 10 Sep 2022 21:53:19 -0400
>>>> To:              [email protected]
>>>> From:            Gary Dale <[email protected]>
>>>> Subject:         trying to run tightvnc as a systemd service on Debian/Bookworm
>>>>> Here's my vncserver.service file:
>>>>>
>>>>> [Unit]
>>>>> Description=Start TightVNC server at startup
>>>>> After=syslog.target network.target
>>>>>
>>>>> [Service]
>>>>> Type=forking
>>>>> User=garydale
>>>>> Group=garydale
>>>>> WorkingDirectory=/home/garydale
>>>>>
>>>>> PIDFile=/home/garydale/.vnc/%H:%i.pid
>>>>> ExecStartPre=-/usr/bin/vncserver -kill :%i > /dev/null 2>&1
>>>>> ExecStart=/usr/bin/vncserver -depth 24 -geometry 1024x768 :%i
>>>>> ExecStop=/usr/bin/vncserver -kill :%i
>>>>>
>>>>> [Install]
>>>>> WantedBy=multi-user.target
>>>>>
>>>>>
>>>>> When I try to start the service I get this:
>>>>>
>>>>> # systemctl start vncserver
>>>>> Job for vncserver.service failed because the control process exited with
>>>>> error code.
>>>>> See "systemctl status vncserver.service" and "journalctl -xeu
>>>>> vncserver.service" for details.
>>>>>
>>>>> # systemctl status vncserver.service
>>>>> × vncserver.service - Start TightVNC server at startup
>>>>>         Loaded: loaded (/etc/systemd/system/vncserver.service; enabled;
>>>>> preset: enabled)
>>>>>         Active: failed (Result: exit-code) since Sat 2022-09-10 21:44:28
>>>>> EDT; 29s ago
>>>>>        Process: 9180 ExecStartPre=/usr/bin/vncserver -kill : > /dev/null
>>>>> 2>&1 (code=exited, status=255/EXCEPTION)
>>>>>        Process: 9184 ExecStart=/usr/bin/vncserver -depth 24 -geometry
>>>>> 1024x768 : (code=exited, status=255/EXCEPTION)
>>>>>            CPU: 37ms
>>>>>
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -httpport number
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -basehttpport number
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -alwaysshared
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -nevershared
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -pixelformat rgb<NNN>
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -pixelformat bgr<NNN>
>>>>> Sep 10 21:44:28 transponder vncserver[9184]: See vncserver and Xtightvnc
>>>>> manual pages for more information.
>>>>> Sep 10 21:44:28 transponder systemd[1]: vncserver.service: Control
>>>>> process exited, code=exited, status=255/EXCEPTION
>>>>> Sep 10 21:44:28 transponder systemd[1]: vncserver.service: Failed with
>>>>> result 'exit-code'.
>>>>> Sep 10 21:44:28 transponder systemd[1]: Failed to start Start TightVNC
>>>>> server at startup.
>>>>>
>>>>> # journalctl -xeu vncserver.service
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -httpport number
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -basehttpport number
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -alwaysshared
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -nevershared
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -pixelformat rgb<NNN>
>>>>> Sep 10 21:44:28 transponder vncserver[9184]:         -pixelformat bgr<NNN>
>>>>> Sep 10 21:44:28 transponder vncserver[9184]: See vncserver and Xtightvnc
>>>>> manual pages for more information.
>>>>> Sep 10 21:44:28 transponder systemd[1]: vncserver.service: Control
>>>>> process exited, code=exited, status=255/EXCEPTION
>>>>> ░░ Subject: Unit process exited
>>>>> ░░ Defined-By: systemd
>>>>> ░░ Support: https://www.debian.org/support
>>>>> ░░
>>>>> ░░ An ExecStart= process belonging to unit vncserver.service has exited.
>>>>> ░░
>>>>> ░░ The process' exit code is 'exited' and its exit status is 255.
>>>>> Sep 10 21:44:28 transponder systemd[1]: vncserver.service: Failed with
>>>>> result 'exit-code'.
>>>>> ░░ Subject: Unit failed
>>>>> ░░ Defined-By: systemd
>>>>> ░░ Support: https://www.debian.org/support
>>>>> ░░
>>>>> ░░ The unit vncserver.service has entered the 'failed' state with result
>>>>> 'exit-code'.
>>>>> Sep 10 21:44:28 transponder systemd[1]: Failed to start Start TightVNC
>>>>> server at startup.
>>>>> ░░ Subject: A start job for unit vncserver.service has failed
>>>>> ░░ Defined-By: systemd
>>>>> ░░ Support: https://www.debian.org/support
>>>>> ░░
>>>>> ░░ A start job for unit vncserver.service has finished with a failure.
>>>>> ░░
>>>>> ░░ The job identifier is 11431 and the job result is failed.
>>>>> lines 64-92/92 (END)
>>>>>
>>>>>
>>>>> However:
>>>>> $ vncserver
>>>>> Couldn't start Xtightvnc; trying default font path.
>>>>> Please set correct fontPath in the vncserver script.
>>>>>
>>>>> New 'X' desktop is transponder:1
>>>>>
>>>>> Starting applications specified in /home/garydale/.vnc/xstartup
>>>>> Log file is /home/garydale/.vnc/transponder:1.log
>>>>>
>>>>> garydale@transponder:~$ ps aux | grep vnc
>>>>> garydale    9959  0.0  0.0   9932  7276 pts/3    S    21:49   0:00
>>>>> Xtightvnc :1 -desktop X -auth /home/garydale/.Xauthority -geometry
>>>>> 1024x768 -depth 24 -rfbwait 120000 -rfbauth /home/garydale/.vnc/passwd
>>>>> -rfbport 5901 -co /etc/X11/rgb
>>>>> garydale    9981  0.0  0.0  11412  2168 pts/3    S+   21:50   0:00 grep vnc
>>>>>
>>>>>
>>>>> I'm trying to figure out what I'm doing wrong that is preventing it from
>>>>> starting as a systemd service. Any ideas?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>> ___________________________________________________________
>>>>> TightVNC mailing list, [email protected]
>>>>> To change your subscription or to UNSUBSCRIBE, please visit
>>>>> https://lists.sourceforge.net/lists/listinfo/vnc-tight-list
>>>> +------------------------------------------------------------+
>>>>    Michael D. Setzer II - Computer Science Instructor (Retired)
>>>>    mailto:[email protected]
>>>>    mailto:[email protected]
>>>>    Guam - Where America's Day Begins
>>>>    G4L Disk Imaging Project maintainer
>>>>    http://sourceforge.net/projects/g4l/
>>>> +------------------------------------------------------------+
>>>>
>>>> ___________________________________________________________
>>>> TightVNC mailing list, [email protected]
>>>> To change your subscription or to UNSUBSCRIBE, please visit
>>>> https://lists.sourceforge.net/lists/listinfo/vnc-tight-list
>>
>> ___________________________________________________________
>> TightVNC mailing list, [email protected]
>> To change your subscription or to UNSUBSCRIBE, please visit
>> https://lists.sourceforge.net/lists/listinfo/vnc-tight-list


___________________________________________________________
TightVNC mailing list, [email protected]
To change your subscription or to UNSUBSCRIBE, please visit
https://lists.sourceforge.net/lists/listinfo/vnc-tight-list