5

My hosting space (Debian Wheezy) serves two websites (one WordPress and one Rails). Today I saw both were down and I rebooted the server. The Rails site works again and the WordPress one now says that it has an error connecting to the database. Then after the reboot (from SSH as well) I SSH'ed into the server I got the following message:

PTY allocation request failed on channel 0
stdin: is not a tty

When I run with -v flag I get output with nothing strange I think (just checking the public and private key). See this gist.

When I SSH as follows ssh user@host "/bin/bash -i" I can login into the remote shell.

I read in another answer (which also provided also the tip with appending "bin/bash -i" and that helped) that I should manually remove and re-add the /dev/pt* files. The one who asked the question said that unmounting /dev/pts and remounting it worked. Unfortunately I get the error:

Can't find /dev/pts in /etc/fstab or /etc/mtab

My /etc/fstab files looks like this:

#UNCONFIGURED FSTAB FOR BASE SYSTEM

Does anyone have any idea what is going on and how I can solve this?

/edit Output of tty; ls -l /proc/self/fd locally:

/dev/pts/2
total 0
lrwx------ 1 erwin erwin 64 Sep 13 19:01 0 -> /dev/pts/2
lrwx------ 1 erwin erwin 64 Sep 13 19:01 1 -> /dev/pts/2
lrwx------ 1 erwin erwin 64 Sep 13 19:01 2 -> /dev/pts/2
lr-x------ 1 erwin erwin 64 Sep 13 19:01 3 -> /proc/4389/fd

Output of ls -la /dev/ptmx /dev/pts on remote machine:

crw-rw-rw- 1 root tty  5, 2 Sep 11 00:19 /dev/ptmx

/dev/pts:
total 8
drwxr-xr-x 2 root root 4096 Mar 10  2013 .
drwxr-xr-x 3 root root 4096 Sep 11 00:35 ..

/edit 2

Login via ssh root@host "/bin/bash -i" at 18:10 and looked in /var/log. Besides a cronjob I saw one file that was edited:

-rw-r----- 1 root adm 614306 Sep 15 18:10 auth.log and syslog (via cronjob). Syslog was a coincidence since something happened every 30 minutes which relates to PHP.

Then I copied the file via scp to local.

auth.log:

Sep 15 18:10:23 vz1223 sshd[23681]: Accepted publickey for root from [localIp] port 39126 ssh2
Sep 15 18:10:23 vz1223 sshd[23681]: pam_unix(sshd:session): session opened for user root by (uid=0)
Sep 15 18:12:14 vz1223 sshd[23681]: Received disconnect from [localIp]: 11: disconnected by user
Sep 15 18:12:14 vz1223 sshd[23681]: pam_unix(sshd:session): session closed for user root
Sep 15 18:12:29 vz1223 sshd[23700]: Accepted publickey for root from [localIp] port 39160 ssh2
Sep 15 18:12:29 vz1223 sshd[23700]: pam_unix(sshd:session): session opened for user root by (uid=0)
Sep 15 18:12:29 vz1223 sshd[23700]: Received disconnect from [localIP]: 11: disconnected by user
Sep 15 18:12:29 vz1223 sshd[23700]: pam_unix(sshd:session): session closed for user root
Sep 15 18:12:47 vz1223 sshd[23709]: Accepted publickey for root from [localIp] port 39163 ssh2
Sep 15 18:12:47 vz1223 sshd[23709]: pam_unix(sshd:session): session opened for user root by (uid=0)

*/edit 3/

As said, according to this answer to a similar question I should umount and mount my /dev/pts by running mount -t devpts -o OPTIONS devpts /dev/pts.

When I run mount I do not see /dev/pts/ And when I run mount /dev/pts/ I get: can't find /dev/pts in /etc/fstab or /etc/mtab. The output of mount is the following:

/home/vz/private/1223 on / type simfs (rw,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=6556k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=39320k)

Perhaps I should get /dev/pts to mount again?

*/edit 4/ More logging with running ssh -vvv user@host gives this.

*/edit 5/ result of namei -lx /dev/pts on host:

f: /dev/pts
Drwxr-xr-x root root /
drwxr-xr-x root root dev
drwxr-xr-x root root pts

*/edit 6/ I rebooted the server once again from SSH with the "/bin/bash -i" appended via the reboot command and now the terminal is back to normal... I have no idea what went wrong nor what solved it, but it works again.

Thanks a lot everyone for your help!

  • Are you running these SSH sessions from a terminal? Post the output of tty; ls -l /proc/self/fd on the local machine, and of ls -la /dev/ptmx /dev/pts on the remote machine. By the way, it's normal that /dev/pts wouldn't be mentioned in /etc/fstab, most distributions hard-code it in startup scripts. – Gilles Sep 12 '14 at 14:59
  • Does anything appear in a log file? Check all files in /var/log that got modified at the time of the login attempt and post all messages generated at that time (replace host names by placeholders for privacy). – Gilles Sep 14 '14 at 19:53
  • @Gilles Nothing appears in /var/log except a change to auth.log. I added this. – Erwin Rooijakkers Sep 15 '14 at 16:27
  • 1
    On a running Debian system the /dev directory is a tmpfs mounted filesystem. Within that mount, /dev/pts is a devpts mounted filesystem. The namei -lx <full path> command displays d for directories and D for mount points for as the first character of each line. Your results showed / as a mount point (D) and the other two as mere sub-directories (d). That suggests that they hadn't been mounted as /dev and /dev/pts. As it's working now, running that command again should show Ds. – garethTheRed Sep 21 '14 at 6:53
  • 3
    I presume you've tried ssh -t ... ("force pseudo-tty allocation") but it hasn't been noted anywhere. If that doesn't work, try ssh -tt ... ("force tty allocation even if ssh has no local tty"). – Adam Katz Jan 26 '15 at 6:07
1

So, /dev/pts is a virtual filesystem in the kernel for the pseudo terminal s(omething; not sure what the s stands for). It is a virtual kernel-only filesystem that exports some data from the kernel, very much like sysfs (/sys) and procfs (/proc) do as well. The filesystem should be mounted with a type devpts, on /dev/pts.

This is a special filesystem that doesn't usually appear in /etc/fstab, but it needs to be mounted. Usually distributions have init scripts or similar to do the mounts needed; but occasionally this may fail, and then you get issues like that.

On systemd-based systems, this problem should not occur anymore; systemd takes care of ensuring that the devpts filesystem is mounted.

If you use a different init system, then the fix may depend on the distribution you use. On Debian with sysvinit, the devpts filesystem is mounted by the mountdevsubfs.sh init script. If you run into this problem ever again, you can do one of two things:

  • Run /etc/init.d/mountdevsubfs.sh restart
  • Bypass the init script and manually run mount -t devpts devpts /dev/pts

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.