Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #247324 > unrolled thread

Issues running TigerVNC on Debian WSL-2

Back to article view | Back to linux.debian.user

Contents

  Issues running TigerVNC on Debian WSL-2 <mwoodpatrick@gmail.com> - 2022-04-17 16:40 +0200
    Re: Issues running TigerVNC on Debian WSL-2 Greg Wooledge <greg@wooledge.org> - 2022-04-17 16:50 +0200
      RE: Issues running TigerVNC on Debian WSL-2 <mwoodpatrick@gmail.com> - 2022-04-17 20:10 +0200
        Re: Issues running TigerVNC on Debian WSL-2 Greg Wooledge <greg@wooledge.org> - 2022-04-17 20:10 +0200
          Re: Issues running TigerVNC on Debian WSL-2 Mark Wood-Patrick <mwoodpatrick@gmail.com> - 2022-04-17 20:20 +0200
          Re: Issues running TigerVNC on Debian WSL-2 The Wanderer <wanderer@fastmail.fm> - 2022-04-17 21:50 +0200
            Re: Issues running TigerVNC on Debian WSL-2 Greg Wooledge <greg@wooledge.org> - 2022-04-18 00:20 +0200
              Re: Issues running TigerVNC on Debian WSL-2 The Wanderer <wanderer@fastmail.fm> - 2022-04-18 02:20 +0200
                RE: Issues running TigerVNC on Debian WSL-2 <mwoodpatrick@gmail.com> - 2022-04-18 13:20 +0200
              RE: Issues running TigerVNC on Debian WSL-2 <mwoodpatrick@gmail.com> - 2022-04-18 13:20 +0200

#247324 — Issues running TigerVNC on Debian WSL-2

[Multipart message — attachments visible in raw view] — view raw

I installed TigerVNC on my WSL-2 based Debian distro and installed TogerVNC
using:

 

    sudo apt-get install tigervnc-standalone-server

 

It installed version TigerVNC 1.11.0 but TigerVNC 1.12.0 has been out since
last November is there a reason the package version has not been updated?

 

In trying to run TigerVNC using:

 

    Vncserver :1

 

To display on display 1 (since 0 is Microsoft Wayland) I get:

 

=================== tail /home/mwoodpatrick/.vnc/MarkSpectre14.:5901.log
===================

_XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno =
11
<https://www.bing.com/search?q=errno+11&form=ANNNB1&refig=28839b9aa2594a0ab1
cd007b1568da97> 

_XSERVTransMakeAllCOTSServerListeners: failed to create listener for unix

 

Anyone know why this is failing, is anyone able to run TigerVNC on WSL-2
Debian

 

Any pointers would be most helpful

 

Regards

 

Mark

 

 

 

 

[toc] | [next] | [standalone]

#247325

On Sun, Apr 17, 2022 at 07:20:58AM -0700, mwoodpatrick@gmail.com wrote:
> =================== tail /home/mwoodpatrick/.vnc/MarkSpectre14.:5901.log
> ===================
> 
> _XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno =
> 11

errno 11 is EAGAIN, "Try again".  How strange.

I would check the ownership and permissions and fullness of your /tmp
directory.  Make sure everything looks all right.

Also see whether there's a /tmp/.X11-unix directory.  Here's what I have:

unicorn:~$ ls -ld /tmp /tmp/.X11-unix
drwxrwxrwt 29 root root 73728 Apr 17 09:19 /tmp
drwxrwxrwt  2 root root  4096 Mar 26 08:02 /tmp/.X11-unix

Note the world-writability with sticky bits.

[toc] | [prev] | [next] | [standalone]

#247326

Many thanks for the response. Much appreciated

Permissions look ok

    ls -ld /tmp /tmp/.X11-unix
         drwxrwxrwt 2 root root 4096 Apr 17 09:31 /tmp
         lrwxrwxrwx 1 root root   19 Apr 17 09:31 /tmp/.X11-unix ->
/mnt/wslg/.X11-unix

    ls -ld /mnt/wslg/.X11-unix
        drwxrwxrwx 2 root root 60 Apr 17 09:31 /mnt/wslg/.X11-unix

I have write access to both locations

Regards

Mark

-----Original Message-----
From: Greg Wooledge <greg@wooledge.org> 
Sent: Sunday, April 17, 2022 7:47 AM
To: debian-user@lists.debian.org
Subject: Re: Issues running TigerVNC on Debian WSL-2

On Sun, Apr 17, 2022 at 07:20:58AM -0700, mwoodpatrick@gmail.com wrote:
> =================== tail 
> /home/mwoodpatrick/.vnc/MarkSpectre14.:5901.log
> ===================
> 
> _XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, 
> errno =
> 11

errno 11 is EAGAIN, "Try again".  How strange.

I would check the ownership and permissions and fullness of your /tmp
directory.  Make sure everything looks all right.

Also see whether there's a /tmp/.X11-unix directory.  Here's what I have:

unicorn:~$ ls -ld /tmp /tmp/.X11-unix
drwxrwxrwt 29 root root 73728 Apr 17 09:19 /tmp drwxrwxrwt  2 root root
4096 Mar 26 08:02 /tmp/.X11-unix

Note the world-writability with sticky bits.

[toc] | [prev] | [next] | [standalone]

#247327

On Sun, Apr 17, 2022 at 10:59:44AM -0700, mwoodpatrick@gmail.com wrote:
> Many thanks for the response. Much appreciated
> 
> Permissions look ok
> 
>     ls -ld /tmp /tmp/.X11-unix
>          drwxrwxrwt 2 root root 4096 Apr 17 09:31 /tmp
>          lrwxrwxrwx 1 root root   19 Apr 17 09:31 /tmp/.X11-unix ->
> /mnt/wslg/.X11-unix
> 
>     ls -ld /mnt/wslg/.X11-unix
>         drwxrwxrwx 2 root root 60 Apr 17 09:31 /mnt/wslg/.X11-unix
> 
> I have write access to both locations

That looks incredibly not OK.  You're doing something unusual, and
you are going to have to deal with the consequences of that.  This
may include running afoul of various things like AppArmor that are
restricting access to specific directory trees, which you are no longer
in.

I can't imagine what benefit you think you're deriving from this
convoluted setup, but whatever it is, I hope it's worth the pain you're
going to experience, trying to track down all of the things you've
broken.

(You've also forgotten the sticky bit on your mounted directory.)

[toc] | [prev] | [next] | [standalone]

#247328

[Multipart message — attachments visible in raw view] — view raw

I need to run on Debian under WSL-2 and want to be able to use Microsoft
Wayland as display 0 and want to have VNC access to the system.

Can you elaborate on exactly what your concerns are and how you would
resolve them and on your comment about the sticky bit, any links on these
issues would be appreciated

Regards

Mark

On Sun, Apr 17, 2022 at 11:07 AM Greg Wooledge <greg@wooledge.org> wrote:

> On Sun, Apr 17, 2022 at 10:59:44AM -0700, mwoodpatrick@gmail.com wrote:
> > Many thanks for the response. Much appreciated
> >
> > Permissions look ok
> >
> >     ls -ld /tmp /tmp/.X11-unix
> >          drwxrwxrwt 2 root root 4096 Apr 17 09:31 /tmp
> >          lrwxrwxrwx 1 root root   19 Apr 17 09:31 /tmp/.X11-unix ->
> > /mnt/wslg/.X11-unix
> >
> >     ls -ld /mnt/wslg/.X11-unix
> >         drwxrwxrwx 2 root root 60 Apr 17 09:31 /mnt/wslg/.X11-unix
> >
> > I have write access to both locations
>
> That looks incredibly not OK.  You're doing something unusual, and
> you are going to have to deal with the consequences of that.  This
> may include running afoul of various things like AppArmor that are
> restricting access to specific directory trees, which you are no longer
> in.
>
> I can't imagine what benefit you think you're deriving from this
> convoluted setup, but whatever it is, I hope it's worth the pain you're
> going to experience, trying to track down all of the things you've
> broken.
>
> (You've also forgotten the sticky bit on your mounted directory.)
>
>

-- 
Mark Wood-Patrick

[toc] | [prev] | [next] | [standalone]

#247330

[Multipart message — attachments visible in raw view] — view raw

On 2022-04-17 at 14:07, Greg Wooledge wrote:

> On Sun, Apr 17, 2022 at 10:59:44AM -0700, mwoodpatrick@gmail.com wrote:
>
>> Many thanks for the response. Much appreciated
>> 
>> Permissions look ok
>> 
>>     ls -ld /tmp /tmp/.X11-unix
>>          drwxrwxrwt 2 root root 4096 Apr 17 09:31 /tmp
>>          lrwxrwxrwx 1 root root   19 Apr 17 09:31 /tmp/.X11-unix ->
>> /mnt/wslg/.X11-unix
>> 
>>     ls -ld /mnt/wslg/.X11-unix
>>         drwxrwxrwx 2 root root 60 Apr 17 09:31 /mnt/wslg/.X11-unix
>> 
>> I have write access to both locations
> 
> That looks incredibly not OK.  You're doing something unusual, and
> you are going to have to deal with the consequences of that.  This
> may include running afoul of various things like AppArmor that are
> restricting access to specific directory trees, which you are no longer
> in.
> 
> I can't imagine what benefit you think you're deriving from this
> convoluted setup, but whatever it is, I hope it's worth the pain you're
> going to experience, trying to track down all of the things you've
> broken.

I don't think this is something he broke himself; from the little I've
found, this appears to be something that's recommended or even required
for WSLg (the Windows Subsystem for Linux GUI) to work. See e.g.
https://github.com/microsoft/wslg/issues/193#issuecomment-841341256 for
one indication that that may be the case.

It is, of course, always possible that other software might not be
compatible with doing this - and, honestly, if I were trying to debug
this I'd probably start by getting the source of TigerVNC and
experimenting with changing things around there.

> (You've also forgotten the sticky bit on your mounted directory.)

While that's certainly not ideal, I can't see how it could cause the
exhibited behavior in this case; from what I can find reading up on the
sticky bit to refresh my memory, having it unset should just result in
being able to do *more* things with/inside the directory than would be
the case if it were set.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#247332

On Sun, Apr 17, 2022 at 03:44:33PM -0400, The Wanderer wrote:
> I don't think this is something he broke himself; from the little I've
> found, this appears to be something that's recommended or even required
> for WSLg (the Windows Subsystem for Linux GUI) to work.

*shudder*

> > (You've also forgotten the sticky bit on your mounted directory.)
> 
> While that's certainly not ideal, I can't see how it could cause the
> exhibited behavior in this case; from what I can find reading up on the
> sticky bit to refresh my memory, having it unset should just result in
> being able to do *more* things with/inside the directory than would be
> the case if it were set.

Well, some applications may check the permissions on the directory,
see that they are set wrong, and refuse to operate.  I have no idea
whether their VNC server is one of them, but there's certainly
precedent.

But as soon as I saw they had made a symlink from a standard location
to a nonstandard location, I *immediately* thought of AppArmor, because
that has been an issue so many times in the past with so many apps.

I don't know precisely why the EAGAIN errno is happening, but it isn't
EACCES so it's not a direct refusal by file system permissions, and it's
not EPERM so it's not a direct refusal for not being superuser.  It's also
not ENOSPC (disk full), so I don't think it's due to a full file system,
but it doesn't take much effort to check that, so I would check anyway.

[toc] | [prev] | [next] | [standalone]

#247334

[Multipart message — attachments visible in raw view] — view raw

On 2022-04-17 at 18:16, Greg Wooledge wrote:

> On Sun, Apr 17, 2022 at 03:44:33PM -0400, The Wanderer wrote:

[that in an earlier message, Greg Wooledge wrote:]

>>> (You've also forgotten the sticky bit on your mounted
>>> directory.)
>> 
>> While that's certainly not ideal, I can't see how it could cause
>> the exhibited behavior in this case; from what I can find reading
>> up on the sticky bit to refresh my memory, having it unset should
>> just result in being able to do *more* things with/inside the
>> directory than would be the case if it were set.
> 
> Well, some applications may check the permissions on the directory,
> see that they are set wrong, and refuse to operate.  I have no idea
> whether their VNC server is one of them, but there's certainly 
> precedent.

Given the error messages being displayed, I don't think it likely that
this is the result of a failed permissions check; it looks as if the
program called mkdir() on the specified path, and is just dealing with
the error code returned by that function call.

I initially thought this was the C library's mkdir() (see 'man 2 mkdir')
- but since that appears to require a second argument to specify the
mode, and there's only one argument presented here, I'm not so sure of
that anymore. This might even be some higher-level language that's
layered over top of the C mkdir(), which would make it even messier to
try to understand.

> But as soon as I saw they had made a symlink from a standard
> location to a nonstandard location, I *immediately* thought of
> AppArmor, because that has been an issue so many times in the past
> with so many apps.

I would be surprised if the WSL2 version of Debian was using AppArmor
enabled by default, but I suppose it's hard to rule anything out,
especially when it comes to Microsoft.

> I don't know precisely why the EAGAIN errno is happening, but it
> isn't EACCES so it's not a direct refusal by file system permissions,
> and it's not EPERM so it's not a direct refusal for not being
> superuser.  It's also not ENOSPC (disk full), so I don't think it's
> due to a full file system, but it doesn't take much effort to check
> that, so I would check anyway.

Assuming this *is coming from the mkdir() C library function, it gets
weirder. On my own (non-WSL-based) Debian system, the man page does not
list EAGAIN for that function.

(I'll note that multiple man pages say that errno 11 may legally be,
and/or specifically is, used for both EAGAIN and EWOULDBLOCK. I can't
see why the latter would make any more sense here than the former,
though.)

I think this almost has to be a WSL2-specific detail - probably
something about how it layers *nix semantics over top of filesystems
which are not compatible with those semantics. (I think it does at least
part of it via having actual virtual-hard-disk files, but that can't be
everything, and in this specific case it's pointing to a mounted
filesystem which is very probably on the host machine and therefore not
in such a contained filesystem.)

From what I gather, WSLg is explicitly in an experimental / pre-release
sort of mode, so it's not surprising that there'd be incompatibilities
and other bugs. I rather think the OP has just hit one of those bugs: a
case where some existing *nix applications are doing things that are
legitimate in their original environment but don't (currently) work
under WSLg, or in other words, a case where WSLg isn't sufficiently
compatible yet.

It might even be worth filing a report about this on the WSLg GitHub
issue tracker; they might decide to declare it not their problem and
close the issue, but they might also consider it legitimate and track it
down and try to get this working.

(If the solution winds up involving not using that symlink, though, I
think - based on what I've seen from existing issue discussions - that
that's going to be a nonstarter.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#247340

Many thanks for the reply I will explore further, follow up with Microsoft and try to debug from source locally, I will update with findings

Regards

Mark

-----Original Message-----
From: The Wanderer <wanderer@fastmail.fm> 
Sent: Sunday, April 17, 2022 5:16 PM
To: debian-user@lists.debian.org
Subject: Re: Issues running TigerVNC on Debian WSL-2

On 2022-04-17 at 18:16, Greg Wooledge wrote:

> On Sun, Apr 17, 2022 at 03:44:33PM -0400, The Wanderer wrote:

[that in an earlier message, Greg Wooledge wrote:]

>>> (You've also forgotten the sticky bit on your mounted
>>> directory.)
>> 
>> While that's certainly not ideal, I can't see how it could cause the 
>> exhibited behavior in this case; from what I can find reading up on 
>> the sticky bit to refresh my memory, having it unset should just 
>> result in being able to do *more* things with/inside the directory 
>> than would be the case if it were set.
> 
> Well, some applications may check the permissions on the directory, 
> see that they are set wrong, and refuse to operate.  I have no idea 
> whether their VNC server is one of them, but there's certainly 
> precedent.

Given the error messages being displayed, I don't think it likely that this is the result of a failed permissions check; it looks as if the program called mkdir() on the specified path, and is just dealing with the error code returned by that function call.

I initially thought this was the C library's mkdir() (see 'man 2 mkdir')
- but since that appears to require a second argument to specify the mode, and there's only one argument presented here, I'm not so sure of that anymore. This might even be some higher-level language that's layered over top of the C mkdir(), which would make it even messier to try to understand.

> But as soon as I saw they had made a symlink from a standard location 
> to a nonstandard location, I *immediately* thought of AppArmor, 
> because that has been an issue so many times in the past with so many 
> apps.

I would be surprised if the WSL2 version of Debian was using AppArmor enabled by default, but I suppose it's hard to rule anything out, especially when it comes to Microsoft.

> I don't know precisely why the EAGAIN errno is happening, but it isn't 
> EACCES so it's not a direct refusal by file system permissions, and 
> it's not EPERM so it's not a direct refusal for not being superuser.  
> It's also not ENOSPC (disk full), so I don't think it's due to a full 
> file system, but it doesn't take much effort to check that, so I would 
> check anyway.

Assuming this *is coming from the mkdir() C library function, it gets weirder. On my own (non-WSL-based) Debian system, the man page does not list EAGAIN for that function.

(I'll note that multiple man pages say that errno 11 may legally be, and/or specifically is, used for both EAGAIN and EWOULDBLOCK. I can't see why the latter would make any more sense here than the former,
though.)

I think this almost has to be a WSL2-specific detail - probably something about how it layers *nix semantics over top of filesystems which are not compatible with those semantics. (I think it does at least part of it via having actual virtual-hard-disk files, but that can't be everything, and in this specific case it's pointing to a mounted filesystem which is very probably on the host machine and therefore not in such a contained filesystem.)

>From what I gather, WSLg is explicitly in an experimental / pre-release sort of mode, so it's not surprising that there'd be incompatibilities and other bugs. I rather think the OP has just hit one of those bugs: a case where some existing *nix applications are doing things that are legitimate in their original environment but don't (currently) work under WSLg, or in other words, a case where WSLg isn't sufficiently compatible yet.

It might even be worth filing a report about this on the WSLg GitHub issue tracker; they might decide to declare it not their problem and close the issue, but they might also consider it legitimate and track it down and try to get this working.

(If the solution winds up involving not using that symlink, though, I think - based on what I've seen from existing issue discussions - that that's going to be a nonstarter.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#247341

Definitely not due to a full filesystem

Regards

Mark

-----Original Message-----
From: Greg Wooledge <greg@wooledge.org> 
Sent: Sunday, April 17, 2022 3:16 PM
To: debian-user@lists.debian.org
Subject: Re: Issues running TigerVNC on Debian WSL-2

On Sun, Apr 17, 2022 at 03:44:33PM -0400, The Wanderer wrote:
> I don't think this is something he broke himself; from the little I've 
> found, this appears to be something that's recommended or even 
> required for WSLg (the Windows Subsystem for Linux GUI) to work.

*shudder*

> > (You've also forgotten the sticky bit on your mounted directory.)
> 
> While that's certainly not ideal, I can't see how it could cause the 
> exhibited behavior in this case; from what I can find reading up on 
> the sticky bit to refresh my memory, having it unset should just 
> result in being able to do *more* things with/inside the directory 
> than would be the case if it were set.

Well, some applications may check the permissions on the directory, see that
they are set wrong, and refuse to operate.  I have no idea whether their VNC
server is one of them, but there's certainly precedent.

But as soon as I saw they had made a symlink from a standard location to a
nonstandard location, I *immediately* thought of AppArmor, because that has
been an issue so many times in the past with so many apps.

I don't know precisely why the EAGAIN errno is happening, but it isn't
EACCES so it's not a direct refusal by file system permissions, and it's not
EPERM so it's not a direct refusal for not being superuser.  It's also not
ENOSPC (disk full), so I don't think it's due to a full file system, but it
doesn't take much effort to check that, so I would check anyway.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web