ssh: 2 действует как ^w независимо от терминала

Я обнаружил следующее в /var/log/syslogв Ubuntu 14.04.

Mar 24 09:41:19 ripple pulseaudio[4838]: [autospawn] core-util.c: Failed to create secure directory (/run/user/112/pulse): No such file or directory
Mar 24 09:41:19 ripple pulseaudio[4838]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
Mar 24 09:41:19 ripple pulseaudio[4838]: [pulseaudio] main.c: Failed to acquire autospawn lock
Mar 24 09:41:21 ripple pulseaudio[4840]: [autospawn] core-util.c: Failed to create secure directory (/run/user/112/pulse): No such file or directory
Mar 24 09:41:21 ripple pulseaudio[4840]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
Mar 24 09:41:21 ripple pulseaudio[4840]: [pulseaudio] main.c: Failed to acquire autospawn lock
Mar 24 09:41:23 ripple pulseaudio[4844]: [autospawn] core-util.c: Failed to create secure directory (/run/user/112/pulse): No such file or directory
Mar 24 09:41:23 ripple pulseaudio[4844]: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
Mar 24 09:41:23 ripple pulseaudio[4844]: [pulseaudio] main.c: Failed to acquire autospawn lock

В моей системе обращение к файлу /etc/passwdпоказывает, что пользователем 112является lightdm, который является менеджером отображения (входа в систему ). Я не использую lightdm. Я вручную останавливаю lightdmпосле каждой перезагрузки. Тем не менее, некоторые процессы lightdmзависали. Изhtop:

  PID  PPID USER      START   TIME+  PRI  NI  VIRT   RES  DATA   SHR S CPU% MEM% Command
 8273  2124 lightdm   Mar20  6:42.31  20   0  404M  5108  224M  3936 S  0.0  0.0 /usr/lib/x86_64-linux-gnu/indicator-sou
 2124     1 lightdm   Mar20  0:44.20  20   0 39800  2128   620  1572 S  0.0  0.0 init --user --startup-event indicator-s
 8265  2124 lightdm   Mar20  0:00.00  20   0  257M  3016  216M  2484 S  0.0  0.0 /usr/lib/x86_64-linux-gnu/indicator-blu

Я сделал sudo kill 2124. Все три процесса исчезли, и сообщения журнала прекратились.

В случае с @grm @grm, похоже, использует менеджер отображения gdm, но принципы могут быть теми же. Возможные решения::

1 )Убедитесь, что процессы, связанные с gdm, не запущены, или, в качестве альтернативы...

2 )Воссоздайте /tmp/.esdи убедитесь, что процессы, связанные с gdm, имеют доступ на запись к /tmp/.esd.

Удачи!