screen fail with "WriteMessage: Bad file descriptor"

Не делайте этого ...

Если две операционные системы попытаются получить доступ к одному и тому же блочному устройству одновременно, вы должны ожидать увидеть повреждение данных. Даже если один из них доступен только для чтения, этот доступный только для чтения экземпляр будет кэшировать данные (например, содержимое каталога, содержимое файла) и не будет знать, что базовые блоки данных изменились. В лучшем случае это может привести к предполагаемому повреждению внутри ОС; в худшем случае это может привести к тому, что ОС будет рассматривать файловую систему как плохую. Если обе ОС имеют доступ на запись к устройству, то в худшем случае, если вы можете ожидать, что файловая система будет повреждена.

(Есть некоторые файловые системы, которые допускают многосерверный доступ, но они не распространены).

Вместо этого вы должны иметь доступ к блочному устройству одной ОС, а затем экспортировать его по NFS в другую ОС, которая затем смонтирует файловую систему по сети.

9
17.12.2015, 08:55
3 ответа

Попробуйте добавить строку defnonblock on в файл ~/.screenrc.

Когда у меня возникла такая же проблема, я нашел несколько сообщений, в которых упоминалось, что это решило их проблемы. Это помогло мне.

4
27.01.2020, 20:07

Ejecute screen -d, encuentre las pantallas y ejecute screen -R [screen_name].

7
27.01.2020, 20:07

Бывает, что у меня есть экран с таким же именем, как у другого экрана + дополнительный текст после него, имя экрана без лишних текстовых разрывов, т.е.

~$ screen -ls
        7385.foo-screen      (02/27/2020 12:03:41 AM)        (Detached)
        7296.foo-screen-2    (02/27/2020 12:00:48 AM)        (Detached)

работает:

~$ screen -r foo-screen-2 

не удается:

~$ screen -r foo-screen 
WriteMessage: Bad file descriptor

работает:

~$ screen -r 7385.foo-screen 
1
27.02.2020, 16:21

Теги

Похожие вопросы