Ungraded my notebook to Fedora 32 and tried the new vncserver setup and it SUCKS...

[Michael D. Setzer II]

Followed the instructions, and set session=xfce in the
config in the .vnc directory and tried to start it.
It fails with a message of bad option -session??

So tried the same thing with session=gnome and that failed exactly the
same.

Then commented out the session completely, and this time it started a
session, but it was using gnome.

Killed the process, and run the vncserver :port and it worked perfectly
and gave me the xfce session.

So, it appears to me the session= is suppose to go in the ~/.vnc/config
file, but it seems to not like that? Am I missing something??


+------------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor (Retired)
mailto:mi...@guam.net
mailto:mset...@gmail.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[Pierre Ossman]

On 02/12/2020 10:56, 'Michael D. Setzer II' via TigerVNC User

Discussion/Support wrote:
> Followed the instructions, and set session=xfce in the
> config in the .vnc directory and tried to start it.
> It fails with a message of bad option -session??
>
> So tried the same thing with session=gnome and that failed exactly the
> same.
>
> Then commented out the session completely, and this time it started a
> session, but it was using gnome.
>
> Killed the process, and run the vncserver :port and it worked perfectly
> and gave me the xfce session.
>
> So, it appears to me the session= is suppose to go in the ~/.vnc/config
> file, but it seems to not like that? Am I missing something??
>

The session argument is new for TigerVNC 1.11.0 and is supposed to be
used together with the vncserver@.service. Fedora are unfortunately also
including the old TigerVNC 1.10.0 vncserver _command_, which doesn't
handle this setting. So there is some risk for confusion.

So please try using the service instead of the command. You should find
the basic steps to get it running documented in the .service file.

Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Michael D. Setzer II]

On 3 Dec 2020 at 16:37, Pierre Ossman wrote:

Subject:               Re: [tigervnc-users] Ungraded my notebook to Fedora 32 and tried the

                             new vncserver setup and it SUCKS...

To:                       "Michael D. Setzer II" <mi...@guam.net>, tigervn...@googlegroups.com

From:                   Pierre Ossman <oss...@cendio.com>

Date sent:            Thu, 3 Dec 2020 16:37:56 +0100

> On 02/12/2020 10:56, 'Michael D. Setzer II' via TigerVNC User

> Discussion/Support wrote:

> > Followed the instructions, and set session=xfce in the

> > config in the .vnc directory and tried to start it.

> > It fails with a message of bad option -session??

> >

> > So tried the same thing with session=gnome and that failed exactly the

> > same.

> >

> > Then commented out the session completely, and this time it started a

> > session, but it was using gnome.

> >

> > Killed  the process, and run the vncserver :port and it worked perfectly

> > and gave me the xfce session.

> >

> > So, it appears to me the session= is suppose to go in the ~/.vnc/config

> > file, but it seems to not like that? Am I missing something??

> >

>

> The session argument is new for TigerVNC 1.11.0 and is supposed to be

> used together with the vncserver@.service. Fedora are unfortunately also

> including the old TigerVNC 1.10.0 vncserver _command_, which doesn't

> handle this setting. So there is some risk for confusion.

>

> So please try using the service instead of the command. You should find

> the basic steps to get it running documented in the .service file.

Perhaps I wasn't clear...

the service is what is broken if you include as session=gnome or session=xfce in the config file. In both cases the service is what reports the error about it not understanding -session??

If I comment out the line in the config file (the file doesn't show a session line in the original one at all).

Then the service option does work, and it creates the vnc session with gnome??

The vncserver :xx works just fine and uses the current xstartup and creates a vnc option that works with the vncviewer.

So, it is the service vnc that doesn't seem to support the session= in the config file. So, something isn't working??

With nothing in config, it seems to work fine with gnome, but again putting in either gnome or xfce it fails.

· vncs...@79.service - Remote desktop service (VNC)

     Loaded: loaded (/usr/lib/systemd/system/vncserver@.service; disabled; vendor preset: disabled)

     Active: failed (Result: exit-code) since Wed 2020-12-02 19:31:46 ChST; 1 day 7h ago

        CPU: 13ms

Dec 02 19:32:01 setzconote.dyndns.org vncsession-start[902]: Syntax:

Dec 02 19:32:01 setzconote.dyndns.org vncsession-start[902]:     /usr/sbin/vncsession <username> <display>

Dec 02 19:31:45 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 19:31:46 setzconote.dyndns.org systemd[1]: vncs...@79.service: Control process exited, code=exited, status=64/>

Dec 02 19:31:46 setzconote.dyndns.org systemd[1]: vncs...@79.service: Failed with result 'exit-code'.

Dec 02 19:31:46 setzconote.dyndns.org systemd[1]: Failed to start Remote desktop service (VNC).

lines 1-11/11 (END)

Just now tried running the /usr/sbin/vncsession command from command line, and it seems to work with all 3 options??

With no session option, it loads with gnome.

With session=gnome it does the same

With session=xfce it works with xfce

So manually doing it works, but with the systemd starting it get the error above??

Here is what ps -ef | grep vnc reports.

root      207244       1  0 03:02 ?        00:00:00 /usr/sbin/vncsession msetzerii :79

root      207245  207244  0 03:02 ?        00:00:00 [vncsession] <defunct>

msetzer+  207246  207244  0 03:02 ?        00:00:00 xinit /etc/X11/xinit/Xsession startxfce4 -- /usr/bin/Xvnc :79 -geometry 1270x900 -auth /root/.xauthOqXP8U -desktop setzconote.dyndns.org:79 (msetzerii) -fp catalogue:/etc/X11/fontpath.d -pn -rfbauth /home/msetzerii/.vnc/passwd -rfbport 5979 -rfbwait 30000

msetzer+  207259  207246  0 03:02 ?        00:00:01 /usr/bin/Xvnc :79 -geometry 1270x900 -auth /root/.xauthOqXP8U -desktop setzconote.dyndns.org:79 (msetzerii) -fp catalogue:/etc/X11/fontpath.d -pn -rfbauth /home/msetzerii/.vnc/passwd -rfbport 5979 -rfbwait 30000

I'm currently logged into the machine locally, and

vncviewer 127.0.0.1:79 opens a vnc session..

So, not sure why it doesn't work if run from systemd??

>

> Regards

> --

> Pierre Ossman           Software Development

> Cendio AB               https://cendio.com

> Teknikringen 8          https://twitter.com/ThinLinc

> 583 30 Linköping        https://facebook.com/ThinLinc

> Phone: +46-13-214600

>

> A: Because it messes up the order in which people normally read text.

> Q: Why is top-posting such a bad thing?

>

> --

> You received this message because you are subscribed to the Google Groups "TigerVNC User Discussion/Support" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to tigervnc-user...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/df6a43a1-36fc-b314-cd72-ee6ac23c8fe8%40cendio.com.

  

[Pierre Ossman]

On 03/12/2020 18:09, 'Michael D. Setzer II' via TigerVNC User

Discussion/Support wrote:
>
> Perhaps I wasn't clear...
> the service is what is broken if you include as session=gnome or
> session=xfce in the config file. In both cases the service is what reports
> the error about it not understanding -session??
>

Oh? That's very odd. Could you share the entire log output for us? Both
"journalctl --unit vncs...@79.service" and the file in ~/.vnc.

>
> Just now tried running the /usr/sbin/vncsession command from command
> line, and it seems to work with all 3 options??
> With no session option, it loads with gnome.
> With session=gnome it does the same
> With session=xfce it works with xfce
> So manually doing it works, but with the systemd starting it get the error
> above??
>

Even more odd. So we'll have to look at those logs and see if that gives
us any clues.

[Michael D. Setzer II]

On 7 Dec 2020 at 11:18, Pierre Ossman wrote:

Subject:               Re: [tigervnc-users] Ungraded my notebook to Fedora 32 and tried the

                             new vncserver setup and it SUCKS...

To:                       "Michael D. Setzer II" <mi...@guam.net>, tigervn...@googlegroups.com

From:                   Pierre Ossman <oss...@cendio.com>

Date sent:            Mon, 7 Dec 2020 11:18:02 +0100

> On 03/12/2020 18:09, 'Michael D. Setzer II' via TigerVNC User

> Discussion/Support wrote:

> >

> > Perhaps I wasn't clear...

> > the service is what is broken if you include as session=gnome or

> > session=xfce in the config file. In both cases the service is what reports

> > the error about it not understanding -session??

> >

>

Tried to do some testing, and got locked out of local login with userid.

If config doesn't have a session option, it appears a reboot starts the vnc session, but then an attempt to login locally fails.

Have to go to a root terminal, and completely disable the vnc options, and then reboot to be able to login.

If it has session=gnone or session=xfce it fails to start the vnc, and I can login locally.

After loging in I can as root run vncsession msetzerii :79 and it loads the vnc with either the xfce or gnome session options.

ps -ef | grep vnc

root        3942       1  0 22:53 ?        00:00:00 vncsession msetzerii :79

root        3943    3942  0 22:53 ?        00:00:00 [vncsession] <defunct>

msetzer+    3944    3942  0 22:53 ?        00:00:00 /usr/bin/perl /usr/libexec/vncserver :79

At this point, I have the local session and the vnc session running as before.

In previous version, I used the rc.local to use runas to start the vncserver :79 and would then be able to vnc into the machines.

I'm thinking that putting a vncsession user :port  would do the same but it appears that is actually running vncserver as the user??

This is what journalctl shows.

-- Logs begin at Thu 2020-11-12 14:48:39 ChST, end at Mon 2020-12-07 23:03:41 ChST. --

Dec 02 18:33:15 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 18:33:15 setzconote.dyndns.org vncsession-start[151665]: Syntax:

Dec 02 18:33:15 setzconote.dyndns.org vncsession-start[151665]:     /usr/sbin/vncsession <username> <display>

Dec 02 18:33:15 setzconote.dyndns.org systemd[1]: vncserver@.79.service: Control process exited, code=exited, status=64/USAGE

Dec 02 18:33:15 setzconote.dyndns.org systemd[1]: vncserver@.79.service: Failed with result 'exit-code'.

Dec 02 18:33:15 setzconote.dyndns.org systemd[1]: Failed to start Remote desktop service (VNC).

Dec 02 18:33:56 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 18:33:56 setzconote.dyndns.org vncsession-start[151700]: Syntax:

Dec 02 18:33:56 setzconote.dyndns.org vncsession-start[151700]:     /usr/sbin/vncsession <username> <display>

Dec 02 18:33:56 setzconote.dyndns.org systemd[1]: vncserver@.79.service: Control process exited, code=exited, status=64/USAGE

Dec 02 18:33:56 setzconote.dyndns.org systemd[1]: vncserver@.79.service: Failed with result 'exit-code'.

Dec 02 18:33:56 setzconote.dyndns.org systemd[1]: Failed to start Remote desktop service (VNC).

Dec 02 18:35:01 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 18:35:01 setzconote.dyndns.org vncsession-start[151792]: Syntax:

Dec 02 18:35:01 setzconote.dyndns.org vncsession-start[151792]:     /usr/sbin/vncsession <username> <display>

Dec 02 18:35:01 setzconote.dyndns.org systemd[1]: vncserver@.79.service: Control process exited, code=exited, status=64/USAGE

Dec 02 18:35:01 setzconote.dyndns.org systemd[1]: vncserver@.79.service: Failed with result 'exit-code'.

Dec 02 18:35:01 setzconote.dyndns.org systemd[1]: Failed to start Remote desktop service (VNC).

Dec 02 18:35:32 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 18:35:32 setzconote.dyndns.org vncsession-start[151831]: No user configured for display 79

Dec 02 18:35:32 setzconote.dyndns.org systemd[1]: vncs...@79.service: Control process exited, code=exited, status=1/FAILURE

Dec 02 18:35:32 setzconote.dyndns.org systemd[1]: vncs...@79.service: Failed with result 'exit-code'.

Dec 02 18:35:32 setzconote.dyndns.org systemd[1]: Failed to start Remote desktop service (VNC).

Dec 02 18:44:25 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 18:44:25 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 02 18:44:34 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 02 18:45:30 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 18:45:30 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 02 18:45:38 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 02 18:50:37 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 18:50:37 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 02 18:50:44 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 02 19:01:30 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 19:01:30 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 02 19:26:47 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

-- Reboot --

Dec 02 19:32:01 setzconote.dyndns.org vncsession-start[902]: Syntax:

Dec 02 19:32:01 setzconote.dyndns.org vncsession-start[902]:     /usr/sbin/vncsession <username> <display>

Dec 02 19:31:45 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 02 19:31:46 setzconote.dyndns.org systemd[1]: vncs...@79.service: Control process exited, code=exited, status=64/USAGE

Dec 02 19:31:46 setzconote.dyndns.org systemd[1]: vncs...@79.service: Failed with result 'exit-code'.

Dec 02 19:31:46 setzconote.dyndns.org systemd[1]: Failed to start Remote desktop service (VNC).

Dec 04 05:01:43 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:01:43 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:01:52 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:06:24 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:06:24 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:06:32 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:07:29 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:07:29 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:07:36 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:09:51 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:09:51 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:09:59 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:11:13 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:11:13 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:11:21 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:13:19 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:13:19 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:13:26 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:14:36 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:14:36 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:14:43 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:18:06 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:18:06 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:18:14 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:19:28 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:19:28 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:19:36 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:20:12 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:20:12 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:20:19 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:21:07 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:21:07 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:21:07 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:22:33 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:22:33 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:22:41 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:24:49 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:24:49 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:24:56 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:26:38 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:26:38 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:26:45 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:44:04 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:44:04 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:44:04 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:44:51 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:44:51 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:44:59 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 04 05:47:53 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 04 05:47:53 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 04 05:48:00 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 07 22:16:18 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 07 22:16:18 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 07 22:16:19 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 07 22:17:22 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 07 22:17:22 setzconote.dyndns.org vncsession-start[1060860]: No user configured for display 79

Dec 07 22:17:22 setzconote.dyndns.org systemd[1]: vncs...@79.service: Control process exited, code=exited, status=1/FAILURE

Dec 07 22:17:22 setzconote.dyndns.org systemd[1]: vncs...@79.service: Failed with result 'exit-code'.

Dec 07 22:17:22 setzconote.dyndns.org systemd[1]: Failed to start Remote desktop service (VNC).

Dec 07 22:34:02 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 07 22:34:02 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 07 22:38:25 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

-- Reboot --

Dec 07 22:41:45 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...

Dec 07 22:41:56 setzconote.dyndns.org systemd[1]: Started Remote desktop service (VNC).

Dec 07 22:44:22 setzconote.dyndns.org systemd[1]: Stopping Remote desktop service (VNC)...

Dec 07 22:44:23 setzconote.dyndns.org systemd[1]: vncserver@:79.service: Succeeded.

Dec 07 22:44:23 setzconote.dyndns.org systemd[1]: Stopped Remote desktop service (VNC).

> Oh? That's very odd. Could you share the entire log output for us? Both

> "journalctl --unit vncs...@79.service" and the file in ~/.vnc.

>

> >

> > Just now tried running the /usr/sbin/vncsession command from command

> > line, and it seems to work with all 3 options??

> > With no session option, it loads with gnome.

> > With session=gnome it does the same

> > With session=xfce it works with xfce

> > So manually doing it works, but with the systemd starting it get the error

> > above??

> >

>

> Even more odd. So we'll have to look at those logs and see if that gives

> us any clues.

>

> Regards

> --

> Pierre Ossman           Software Development

> Cendio AB               https://cendio.com

> Teknikringen 8          https://twitter.com/ThinLinc

> 583 30 Linköping        https://facebook.com/ThinLinc

> Phone: +46-13-214600

>

> A: Because it messes up the order in which people normally read text.

> Q: Why is top-posting such a bad thing?

>

> --

> You received this message because you are subscribed to the Google Groups "TigerVNC User Discussion/Support" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to tigervnc-user...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/d59a554c-bc3a-fe6f-fbb4-9d7b4955c2ee%40cendio.com.

  

[Pierre Ossman]

On 07/12/2020 14:06, 'Michael D. Setzer II' via TigerVNC User

Discussion/Support wrote:
> Tried to do some testing, and got locked out of local login with userid.
> If config doesn't have a session option, it appears a reboot starts the vnc
> session, but then an attempt to login locally fails.

Modern systems don't generally support multiple sessions as the same
user, so you'll need to start the VNC session as a different user than
the one that is logged on locally for things to work.

>
> This is what journalctl shows.
> -- Logs begin at Thu 2020-11-12 14:48:39 ChST, end at Mon 2020-12-07 23:03:41 ChST. --
> Dec 02 18:33:15 setzconote.dyndns.org systemd[1]: Starting Remote desktop service (VNC)...
> Dec 02 18:33:15 setzconote.dyndns.org vncsession-start[151665]: Syntax:
> Dec 02 18:33:15 setzconote.dyndns.org vncsession-start[151665]: /usr/sbin/vncsession
> <username> <display>
> Dec 02 18:33:15 setzconote.dyndns.org systemd[1]: vncserver@.79.service: Control process exited,
> code=exited, status=64/USAGE
> Dec 02 18:33:15 setzconote.dyndns.org systemd[1]: vncserver@.79.service: Failed with result
> 'exit-code'.
> Dec 02 18:33:15 setzconote.dyndns.org systemd[1]: Failed to start Remote desktop service (VNC).

Hmm... Your service is misnamed here. It should be ":79", not ".79". I'm
guessing that's why it is upset here.

I don't see the log message complaining about -session though? Where did
you get that message?

Regards
--
Pierre Ossman Software Development

Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköping http://facebook.com/ThinLinc
Phone: +46-13-214600 http://plus.google.com/+CendioThinLinc

[DRC]

>> On Dec 9, 2020, at 12:40 AM, Pierre Ossman <oss...@cendio.se> wrote:

> On 07/12/2020 14:06, 'Michael D. Setzer II' via TigerVNC User Discussion/Support wrote:
>> Tried to do some testing, and got locked out of local login with userid.
>> If config doesn't have a session option, it appears a reboot starts the vnc
>> session, but then an attempt to login locally fails.
>
> Modern systems don't generally support multiple sessions as the same user, so you'll need to start the VNC session as a different user than the one that is logged on locally for things to work.

The systems support that. GNOME 3 has a few issues with it, but not insurmountable ones. You just have to use a separate D-Bus session for each VNC session. It’s admittedly far from a perfect solution, but it’s working well enough to be usable for us.

[Pierre Ossman]

I'm surprised that works reliable. $DBUS_SESSION_ADDRESS is deprecated
and applications are expected to hard code the /run/user/<uid>/bus path.
I guess that hasn't happened in practice yet.

Regards
--
Pierre Ossman Software Development

Cendio AB https://cendio.com

Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600

[DRC]

On 12/9/20 8:42 AM, Pierre Ossman wrote:
> I'm surprised that works reliable. $DBUS_SESSION_ADDRESS is deprecated
> and applications are expected to hard code the /run/user/<uid>/bus path.
> I guess that hasn't happened in practice yet.

Where are you seeing that it's deprecated? The man page for dbus-launch
says

"If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use
D-Bus, by default the process will attempt to invoke dbus-launch with
the --autolaunch option to start up a new session bus or find the
existing bus address on the X display or in a file in ~/.dbus/session-bus/"

That's the functionality we're using. If there are hidden issues with
it, I'd love to know that, but so far, these are the only issues I've
found that seem to be systemd-related:

https://github.com/TurboVNC/turbovnc/issues/238
https://github.com/TurboVNC/turbovnc/issues/51

I have no way of verifying whether the former also exists in TigerVNC,
because that issue is specific to multiple simultaneous GNOME 3
sessions, which TigerVNC doesn't allow. The latter issue does also
exist in the new systemd-enabled version of TigerVNC, so it's probably
just expected behavior from systemd.

[Pierre Ossman]

On 09/12/2020 17:12, DRC wrote:
> On 12/9/20 8:42 AM, Pierre Ossman wrote:
>> I'm surprised that works reliable. $DBUS_SESSION_ADDRESS is deprecated
>> and applications are expected to hard code the /run/user/<uid>/bus path.
>> I guess that hasn't happened in practice yet.
>
> Where are you seeing that it's deprecated? The man page for dbus-launch
> says
>

From the discussion here:

https://github.com/systemd/systemd/issues/1600

Specifically:

"Wait, nobody should rely on DBUS_USER_BUS_ADDRESS (sic!) except legacy
applications."

[DRC]

On 12/9/20 10:24 AM, Pierre Ossman wrote:
>> Where are you seeing that it's deprecated?  The man page for dbus-launch
>> says
>>
>
> From the discussion here:
>
> https://github.com/systemd/systemd/issues/1600
>
> Specifically:
>
> "Wait, nobody should rely on DBUS_USER_BUS_ADDRESS (sic!) except legacy
> applications."

I'm not sure if unsetting that environment variable in order to force
dbus-launch to create a new session bus or find the existing bus address
on the X display qualifies as "relying on" it. It seems like the
opposite of relying on it, as a matter of fact. Regardless, the systemd
and D-Bus developers need to get their stories straight.

[Mark Mielke]

Possibly it is bad to use undocumented, or private API to influence
the outcome. But, there is also the dbus-launch command, and it is
also possible to fully reset the environment as "runuser -l", "sudo",
or "ssh" does. It is also possible to have separate systemd service
instances.

I don't agree with the conclusion that it can't or shouldn't be done.
Users need multiple graphical sessions for many real-life scenarios,
and the company I work for has day-to-day workflows where this is a
requirement. I do agree that this is not as well tested, and it
requires that people who deploy in this way need a greater
understanding of the requirements with the understanding that upstream
teams such as "GNOME Developers" or "TigerVNC Developers" will make
decisions that from time-to-time cause breakage for these downstream
workflows, and we will need to continue to modify the downstream setup
to address these problems.

In the case of TigerVNC 1.11, it means we are now using a basically
re-written version of the old "vncserver" script, and our own systemd
service script, so that it provides both the old behaviour which
thousands of users rely on today, and which cannot be arbitrarily
broken without a planned exit strategy, as well as alignment with the
new model, such as supporting the 'session=' property in
$HOME/.vnc/config, providing a migration path for users to move from
the old method to the new method.

Once we have further soaked this method - I will be uncertain what
step to take next. Either I propose it back as a commit to the
TigerVNC master branch, however, discussions in the GitHub issues have
lead to the conclusion that there is no appetite for supporting this
capability any longer, or I post it on a stand-alone web site for
downstream users to use, without any expectation of support from the
upstream TigerVNC developers.

I did note that Fedora 33 seems to have restored "vncserver" in the
distro version of TigerVNC 1.11:

* Tue Sep 29 2020 Jan Grulich <jgru...@redhat.com> - 1.11.0-6
- Backport upstream fix allowing Tigervnc to specify boolean valus in
configuration
- Revert removal of vncserver for F32 and F33

I think it is important to say that many of us think the removing of
vncserver script was a poorly executed decision. I do not remember a
community discussion on this to consider ramifications. I do not
remember a call for people to support it - as I would have put my hand
up. I do not remember a call for "what functionality is the minimum
that must be preserved", as I would have had detailed input. It was
basically a unilateral decision to axe a core function, and replace it
with an entirely new mechanism that was both buggy and failed to meet
all prior requirements.

But, it happens. And so, many of us downstream users - including my
company, and Fedora, are now carrying the script forwards despite the
upstream decision that was made without us.

--
Mark Mielke <mark....@gmail.com>

[DRC]

TurboVNC will continue to support the vncserver script for the
foreseeable future, since our project and its users are fully invested
in that method. We are heavily focused on large-scale deployments,
backward compatibility, and launching from portals or batch queuing
systems. I'm not trying to hijack this thread with an advertisement for
my own project. I'm just trying to make people aware that a
fully-supported backward-compatible alternative still exists, so they
don't waste their limited time on Earth trying to reinvent that wheel.
*BSD users, for instance, are being forced to adopt TurboVNC rather than
TigerVNC because of the new systemd requirement.

I would be willing to also adopt TigerVNC's new systemd-based approach
as an option, but it would only be an option-- basically occupying the
same space as our old optional init.d startup mechanism, which some
people use for small-scale deployments. I haven't yet been able to
figure out how TigerVNC's new approach could be integrated into a
large-scale deployment, such as a portal. The lack of dynamic X display
assignment and the need for root access is a non-starter for that use
case, as far as I can tell.

[Jan Grulich]

Hi,

Fedora TigerVNC maintainer speaking. I did backport the old vncserver because many people complained it is missing. However, I modified to tell users that it will most likely be removed in future releases so people know they should not rely on it and move to the new systemd way. I also now fixed the issue with "session=foo" being broken for the old vncserver script so with the next TigerVNC build will just ignore it and not fail.

Regards,

Jan Grulich

Dne středa 9. prosince 2020 v 19:27:48 UTC+1 uživatel mark....@gmail.com napsal:

[Michael D. Setzer II]

On 9 Dec 2020 at 22:53, Jan Grulich wrote:

Date sent: Wed, 9 Dec 2020 22:53:45 -0800 (PST)
From: Jan Grulich <gru...@gmail.com>
To: TigerVNC User Discussion/Support <tigervn...@googlegroups.com>

Subject: Re: [tigervnc-users] Ungraded my notebook to Fedora 32 and tried the
new vncserver setup and it SUCKS...

>

> Hi,
>
> Fedora TigerVNC maintainer speaking. I did backport the old vncserver because many people
> complained it is missing. However, I modified to tell users that it will most likely be removed in future
> releases so people know they should not rely on it and move to the new systemd way. I also now fixed
> the issue with "session=foo" being broken for the old vncserver script so with the next TigerVNC build
> will just ignore it and not fail.
>
> Regards,
> Jan Grulich

I'm not clear on where exactly this change is coming from?? Is it coming
from tigervnc, gnome, fedora or some other party??
Have been using Redhat since version 9, and Fedora since it came out.
Used the vnc since the beginning. Think it was originally tightvnc, and
then changed to the tigervnc. Use to have my 21 classroom machines,
and could vnc into all of them from my office or home to do updates thru
and iptables firewall with no issues.

Could work locally with the standard gnome desktop and used vnc
mostly with the xfce setup.

The new option seems to kill the use of both a local and vnc session with
the same user, so one would need to create a separate ID, and then vnc
into the other user to get access, which seems dumb..

Currently, I have 4 machines running in my office. Use the notebook
with local connection, and vnc into the other 3 using vnc. Occassionally,
I hook up a monitor to the others when I need to do something local. But
can log into the machine just fine without having to do extra.

I would like a clear explanation on why this is being done. It seems to
want to make the linux act more like windows?? I would have no
problem with not being able to run the desktop locally with gnome and
with vnc and gnome. I actually perfer vnc with xfce.

So, who is pushing this change and what is their justification to do
something that effects how a somewhat large number of users are use to.
The old if it ain't broke don't fix it... If it is broke in some way, please
explain it, and why this is the only solution??

Thanks.

[DRC]

On 12/10/20 2:53 AM, 'Michael D. Setzer II' via TigerVNC User

Discussion/Support wrote:
> The new option seems to kill the use of both a local and vnc session with
> the same user, so one would need to create a separate ID, and then vnc
> into the other user to get access, which seems dumb..

Yes, this is part of what I was referring to earlier.  You can no longer
use GNOME simultaneously in a TigerVNC session and a local session
because they're sharing the same D-Bus address.  To be clear, I
understand that GNOME 3 isn't really multi-session-friendly in general,
and even if you do use separate D-Bus addresses to launch multiple GNOME
3 sessions under the same user account, as TurboVNC does, there are
still some minor issues that have to be worked around.  I would just
rather work around those issues than jettison multi-session capability
altogether.  Also, the changes to TigerVNC make it impossible to use
MATE in multiple sessions, even though that would otherwise work
perfectly fine.

[Michael D. Setzer II]

On 10 Dec 2020 at 11:22, DRC wrote:

Subject: Re: [tigervnc-users] Ungraded my notebook to Fedora
32 and tried the
new vncserver setup and it SUCKS...

To: tigervn...@googlegroups.com
From: DRC <d...@virtualgl.org>
Organization: The VirtualGL Project
Date sent: Thu, 10 Dec 2020 11:22:40 -0600

But in the limited testing I have done, I had the vnc setup to use xfce as I
normally do. After having the systemd setup to start it, I could not
locally log into the machine at all. It would give the login prompt, and I
could enter userid and password, but it would immediately go back to the
login window. I would have no problem with only having one gnome
session. But if I could have one gnome and one xfce running, or don't
know if two xfce sessions local and vnc would have the issues that
running two gnome sessions.

Don't know about running a MATE session. Actually, prefer the xfce
over the gnome 3 for a lot of things. Like having desktop icons to run
programs, and don't need the fancy menu system for a lot of things.

Had a somewhat similar problem with gedit. Seems it doesn't like
running from a terminal prompt if you did an "su" command. It would
change the ownership of files to root, and would then mess things up if
you ran it later with the user prompt. First solution was to have a
cron.hourly script that would reset ownership, but sometimes found that
it happened before the ownership was reset. Later found that problem
doesn't occur if you do an "su -". So, I just aliased su to "su -". Solved
the ownership problem, but some others. Talked with their list, and they
seem to have no problem with it switching ownership, and no intent to
come up with a solution. Currently have switch to using geany instead of
gedit. Created an alias of gedit to geany, and created a shortcut ge that
runs geany. Still type gedit about half the time.

Guess I'm use to certain things. Started with an IBM 1130 with 4K Ram
and punched cards in High School in mid 70s. First PC was a Heathkit
H-120 in 83 with dual cpus (8088 and 8080) with 768K of Ram running
at 8mhz dual 320K floppies. 20M hard disk was a $2000 upgrade...
College mini system IBM 34 had 96K of ram and 63.9M hard disk..
The old old days...

Will it is interesting if nothing else.. Just saw a message post about
changes to CENTOS that are causing concerns. We live in interesting
times.. Be Safe..

>
> --

> You received this message because you are subscribed to the Google Groups "TigerVNC User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tigervnc-user...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/1b94498a-9564-8e1a-d6c6-b035c3f6e41b%40virtualgl.org.

[DRC]

On 12/10/20 12:08 PM, 'Michael D. Setzer II' via TigerVNC User > But in

the limited testing I have done, I had the vnc setup to use xfce as I
> normally do. After having the systemd setup to start it, I could not
> locally log into the machine at all. It would give the login prompt, and I
> could enter userid and password, but it would immediately go back to the
> login window. I would have no problem with only having one gnome
> session. But if I could have one gnome and one xfce running, or don't
> know if two xfce sessions local and vnc would have the issues that
> running two gnome sessions.

When I talk about MATE, you can more generally extrapolate what I'm
saying to all non-systemd window managers, include Xfce. What I meant
was: I don't see any need for TigerVNC to limit non-systemd window
managers (including MATE and Xfce) to one session (including the local
session), but effectively it does.

[Pierre Ossman]

On 10/12/2020 22:13, DRC wrote:
>
> When I talk about MATE, you can more generally extrapolate what I'm
> saying to all non-systemd window managers, include Xfce. What I meant
> was: I don't see any need for TigerVNC to limit non-systemd window
> managers (including MATE and Xfce) to one session (including the local
> session), but effectively it does.
>

Just to clarify though; there is nothing in TigerVNC limiting things to
one session per user. However there is also nothing in TigerVNC trying
to bypass the things in the system that limit things to one session per
user. If any distribution should decide to fully support multiple
sessions, then it should work fine in TigerVNC without us changing anything.

[DRC]

On 12/11/20 12:50 AM, Pierre Ossman wrote:
> Just to clarify though; there is nothing in TigerVNC limiting things
> to one session per user. However there is also nothing in TigerVNC
> trying to bypass the things in the system that limit things to one
> session per user. If any distribution should decide to fully support
> multiple sessions, then it should work fine in TigerVNC without us
> changing anything.

Nothing in any distribution has ever limited non-systemd window managers
to one session per user.  If you're going to convince me that those
limits are fundamental, then I'm going to need to see more than a GitHub
comment as proof.  In practice, I test a lot of different WMs on a lot
of different platforms and haven't uncovered any multi-session issues
except with GNOME 3, and those issues can be worked around.  I have
customers with hundreds of users running simultaneous non-systemd WM
sessions (usually MATE) in TurboVNC (or downstream solutions that bundle
it) 24/7, and no one has ever reported any issues with that.

[DRC]

NOTE: Just as a follow-up to this conversation, I did further testing
and discovered that Red Hat derivatives will automatically start a new
D-Bus session if DBUS_SESSION_BUS_ADDRESS is unset (which is why both
TurboVNC's and TigerVNC's X startup scripts historically did that), but
Debian derivatives will not.  Thus, I modified the default X startup
script in the evolving TurboVNC 3.0 code base so that it explicitly
invokes 'dbus-launch --sh-syntax --exit-with-session'.  That causes a
unique D-Bus session (with a corresponding unique
DBUS_SESSION_BUS_ADDRESS value) to be created for the VNC session, which
prevents the xinit/Xsession infrastructure on Debian/Ubuntu from using
the per-user D-Bus session created by systemd.  Effectively, this allows
multiple instances of the same WM to run under the same user account. 
It seems to work well with the following O/S's and window managers:
https://turbovnc.org/Documentation/Compatibility30.  Do as you see fit
for TigerVNC, but I am satisfied that this is a reasonable solution for us.