[mosh-users] Problems with mosh-server and pselect syscall, fixed

[Quentin Smith]

Hi Ingo and Keith,

In general, you should be booting a kernel in Xen that comes from the 
guest OS, to avoid glibc mismatches. pselect is not the only system call 
that will be confused in this situation, and also udev will often have 
problems.

The easiest way to do this is to configure your Xen host to use pygrub. 
Alternatively, you could copy the guest's kernel to the host and use that 
in the "kernel = " line in the domain's config file.

You don't say what version of Debian you're running, but note that squeeze 
and newer kernels can be used on Xen unmodified (and in lenny, you just 
need the -xen kernel variant).

--Quentin

On Fri, 4 Jan 2013, Keith Winstein wrote:

> Hello Ingo,
>
> We think this problem happens when you have a userspace glibc that
> doesn't match your kernel. (Because glibc would emulate the pselect()
> call if it knew the kernel was before 2.6.16 and didn't support it
> directly.) We've heard of this happening in Xen installations but I'm
> not sure exactly how you are supposed to install Xen so this doesn't
> happen. Thanks for the report and maybe somebody else knows better.
>
> Best regards,
> Keith
>
> On Tue, Jan 1, 2013 at 1:01 PM, Ingo Blechschmidt <iblech at web.de> wrote:
>> Hello,
>>
>> I experienced the following problem with mosh-1.2.3 on a virtual Debian
>> Linux box (using Xen): mosh-server terminated itself instantly after
>> starting. Using
>>
>>     $ mosh-server new -v
>>
>> revealed the error message
>>
>>     "select: Function not implemented".
>>
>> Looking into src/frontend/mosh-server.cc, src/util/select.h and
>> experimenting with the example provided by the select(2) manpage, it
>> seemed that the pselect syscall was not supported on my particular
>> system; but I did not dig further to find out why.
>>
>> As a quick and dirty workaround, I modified src/util/select.h to use
>> select() instead of pselect(), see attached patch. This resulted in a
>> working and usable mosh-server, but I suspect this might very well cause
>> some undesirable consequences; use at your own risk.
>>
>> To the developers: I'd be happy to provide additional information to fix
>> this properly.
>>
>> Thanks!
>> Ingo
>>
>> _______________________________________________
>> mosh-users mailing list
>> mosh-users at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/mosh-users
>>
> _______________________________________________
> mosh-users mailing list
> mosh-users at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-users
>