I did not have permissions to /dev/ptmx and could not figure out why mosh would not work (Infinite count-up Connecting... screen). I figured it out once I tried to run screen and it told me "No more available PTYs" or something to that regard. Mosh should likely error out there similar to screen does instead of connecting indefinitely.
Thanks, let us think how to best handle this. I think the problem here is that your mosh-client is < version 1.2 (1.2 and later will not do an infinite count-up), and it is the mosh-server that is dying (the client doesn't do anything with ptys).
If you upgrade the client to 1.2 or later, you will at least get a better error message. But I think it would require "mosh-server new -v" (verbose) on the server side to actually see the forkpty, since it happens after the server detaches.
Ah, my bad, I thought I had updated my client. My mosh server is the latest. (Although an error would be great, I will keep in mind the -v flag for verbose errors on the server side)
I had a quite similar issue: forkpty failed with "No such file or directory" because my Ubuntu 11.10 server did not have /dev/pts mounted. (*)
Maybe doing stat() on /dev/ptmx and /dev/pts on error could help improve the error message, but I'm afraid it would decrease portability. Should I check the source and come up with a patch?
(*) Full story: http://www.divideandconquer.se/2012/08/10/unable-to-use-mosh-to-connect-to-one-of-my-servers/
I would happily take a pre-forkpty warning in this situation (/dev/ptmx bad permissions or /dev/pts missing), since almost everybody is going to be using UNIX 98 ptys.
But unless we make it fatal, that warning will flash by awful quick unless the user runs mosh-server manually, so not sure how helpful it will be.
Not if the platform uses BSD ptys or another interface. We really only care that forkpty() works, so I'd prefer not to be fatally sensitive to how it's implemented.