То, почему я получаю “экран, завершается” без корня?

На возможных причин для той ошибки - неправильные selinux политики, но по данным Redhat bugtracker такие ошибки были зафиксированы в мягкой фетровой шляпе 17/18.

Как обходное решение можно заменить переменную SCREENDIR в Вас ~/.bashrc к чему-то как $HOME/.screen.

Переброс зеркального отражения между "должен иметь режим 777", и "должен иметь режим 775", вызывается strace.

screen обычно setuid или setgid программа. Это получает дополнительные полномочия, когда это выполняется, который является использованием, чтобы создать файлы сокета и/или изменить utmp.

Когда процесс прослеживается, setuid, и setgid отключены. Процесс трассировки, которым управляет меньшее-количество-привилегированный-пользователь, может принять прослеженный процесс, таким образом, он должен работать без его дополнительных полномочий постараться не давать исходному пользователю слишком много питания.

screen обнаруживает, выполняется ли это с setuid полномочиями, setgid полномочия или ни один, и корректирует свое ожидание полномочий каталога соответственно.

Таким образом, это создает класс проблем, которые не могут быть легко отлажены с strace.

Но если Вы - корень, существует обходное решение! Если процесс трассировки работает как корень, то прослеженный процесс может обычно получать полномочия. Таким образом, вот то, что Вы делаете:

1. Откройте 2 новых терминала
2. В первом терминале войдите в систему удаленной машины как корень
3. Во втором терминале войдите в систему удаленной машины как обычный пользователь
4. Использовать ps для получения PID оболочки обычного пользователя обрабатывают во втором терминале
5. В первом терминале, выполненном strace -f -p SHELLPID
6. На втором терминальном, выполненном экране и часах это перестало работать
7. В первом терминале у Вас теперь есть strace, регистрируют Вас, должен узнать то, что является действительно неправильным.

Ключевое дополнение к strace команда -f опция, которая говорит этому прослеживать дочерние процессы. Вам нужен он для трассировки экрана, который будет дочерним элементом оболочки, обрабатывают Вас указанный с -p.

Мне также нравится использовать -ff и укажите выходной файл с -o, как в

strace -ff -o /tmp/screentrace -p SHELLPID

который создаст отдельный выходной файл для каждого дочернего процесса. Позже Вы читаете их с less /tmp/screentrace* и результатом обычно является инструмент для очистки, чем, что Вы получаете использование сингла -f.

ОБНОВЛЕНИЕ

Теперь, когда я видел вывод strace, я не знаю точно, что пошло не так, как надо, но эта строка является самой удивительной вещью в трассировке:

chown("/dev/pts/2", 1002, 5)            = -1 EPERM (Operation not permitted)

Несколько строк ранее, это создало имущество, которое было показано TIOCGPTN быть номером 2.

open("/dev/ptmx", O_RDWR)               = 5
...
ioctl(5, TIOCGPTN, [2])                 = 0
stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0

Но это было неспособно к показанному это. Я не знаю, почему показанный перестал бы работать, но показанный отказ действительно приводит вероятную причину, почему экран сдался. Можно получить немного больше информации путем добавления -v к strace опциям, и смотрящий на stat после TIOCGPTN видеть, кто владеет /dev/pts/ запись.

Другой способ с gnu ed :

ed -s '!ps aux' <<< $'2,$v/PATTERN/d\n,p\nq\n'

или, если оболочка поддерживает замену процесса:

printf '%s\n' '2,$v/PATTERN/d' ,p q | ed -s <(ps aux)

то есть:

2,$v/PATTERN/d  - remove all lines not matching pattern (ignore the header)
,p              - print the remaining lines
q               - quit

более портативный, без gnu '!' или подстановки оболочки - с помощью только ed встроенных r - r передайте вывод ps aux в буфер, а затем удалите несоответствующие строки в диапазоне 2, $ и распечатайте результат

printf '%s\n' 'r !ps aux' '2,$v/PATTERN/d' ,p q | ed -s

И поскольку команды sed в принятом ответе также соответствуют друг другу, с sed , поддерживающим -f- , и оболочкой, поддерживающей подстановку процесса, я бы запустил:

printf '%s\n' '2,${' '/PATTERN/!d' '}' | sed -f - <(ps aux)

, который практически делает то же самое, что и предыдущие команды ed .

Хотя в современных системах доступ к секторам файла возможен в любом месте на диске, все равно имеет смысл ограничить загрузочные материалы собственным загрузочным разделом, просто из принципа «не кладите все яйца в одну корзину».

Предположим, что основная файловая система повреждена в таком пути, что какой-либо загрузчик более низкой ступени не может правильно прочитать следующую ступень. Если вместо этого материалы загрузчика находятся в собственном разделе, то ядро может подойти и правильно справиться с поврежденным корневым разделом через fsck. Это само по себе может быть в своем разделе.

Загрузочный раздел может предоставить варианты «восстановления», такие как установка альтернативного корневого раздела. Кроме того, что делать при многозагрузке различных операционных систем в различных разделах? Тогда загрузочные материалы не принадлежат ни одной из этих систем. Разумно, чтобы у него был свой раздел. Можно заменить любой из разделов ОС другой ОС, но при этом можно загрузить остальные ОС.

Что также, если вы хотите использовать файловую систему для вашего основного раздела, который загрузчик вообще не понимает? Или, скажем, для чего поддержка на стороне загрузчика просто экспериментальная? В подобных ситуациях файл времени загрузки ещё можно использовать при наличии карты секторов (а загрузчик поддерживает такую вещь: старый добрый загрузчик Linux LILO использовал карты секторов, и поэтому вообще не должен был понимать структуру файловой системы). Но карты секторов по своей сути бледны. Если файловая система реорганизована, сектора перемещаются, и поэтому карты секторов становятся неправильными и должны быть восстановлены, иначе система не сможет перезагрузиться.

Наконец, существует организационный принцип, согласно которому даже если у вас нет фактического раздела, это все равно хорошая идея, что все загрузочные материалы находятся, по крайней мере, под /boot , и не разбросаны нигде.

При обнаружении этого сообщения об ошибке. Мне пришлось скорректировать свои разрешения следующим образом:

chmod 2775/usr/bin/screen

И это решило проблему для меня. 2 очень важно для правильных разрешений доступа.

Вы должны прочитать больше о SUID, SGID, Sticky Bit, ACL и о том, как они влияют на доступ.

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

Просто выполните ps и найдите pid, убейте PID и повторите команду screen еще раз.

Если вы выполняете несколько команд screen, убедитесь, что вы завершаете правильный процесс, связанный с вашим терминалом.

Я обнаружил, что эта проблема решена после комментирования следующей строки в / etc / fstab и перезагрузки:

devpts         /dev/pts        devpts  defaults        0       0

Убедитесь, что это устройство не используется другим экраном.

Этого можно добиться с помощью https://superuser.com/questions/97844/how-can -i-determine-what-process-open-in-in-linux-file-in-inux :

sudo lsof /dev/ttyS0

И затем убить этот процесс, если это так.

По какой-то причине при этом условии sudo screen все еще может получить доступ к устройству, но тогда в этом соединении будут пропущены символы, которые используются другим экраном.

Убедитесь, что у пользователя есть разрешение на чтение и запись в файл.

Например. в Ubuntu вы хотите добавить пользователя в группу dialout: https://askubuntu.com/a/133244/52975

У меня была точно такая же проблема и довольно похожий вывод strace.

Это исправило:

sudo chmod u+s /usr/bin/screen
sudo chmod 755 /var/run/screen

кредиты:https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/

В моем случае просто выйдите из текущего сеанса и снова войдите в систему, и экран снова заработает.

Это другая проблема, но я подумал, что это может быть полезно для тех, кто попал сюда только из-за названия:

Я заметил, что когда я выхожу из screenс помощью Ctrl + ad(отсоединить ), процесс не завершается, и если я попытаюсь начать другой сеанс Я получаю ошибку [screen is terminating]. Начиная с sudoработает. Убить процесс тоже работает.

Если я выхожу с помощью Ctrl + a\(quit ), я могу нормально начать другой сеанс без sudo.

У меня была эта проблема, потому что я работал от непривилегированного пользователя, чья оболочка по умолчанию была /bin/false. Исправление состояло в том, чтобы просто поместить:shell "/bin/bash"в ~/.screenrc.