[screen] Проблеммы

[zingel]

что-то мудрил в сисктл?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[MASiK]

Мудрил
Но там только

Код: Выделить всё

#kern.ipc.somaxconn=1024
#net.inet.icmp.drop_redirect=1
#net.inet.icmp.log_redirect=1
#net.inet.ip.redirect=0

Но уже пытался убрать, не помогло...

[savio]

поборол или нет? у меня такая же беда...

[Chel]

Хотел было написать, что я понял причину возникновения проблемы, но потом понял, что не понял .

Дело в чём. У процесса в Unix есть атрибуты, и среди них — управляющий терминал и дескрипторы открытых файлов. И то, и другое наследуется при форке и экзеке. Здесь родословная такая: процесс [bash(root)] ? процесс [su(root?user) ? bash(user)]. Получается, что, даже если после su потомок не имеет прав на открытие файла терминала (в силу поменявшегося uid), ему это и не нужно, так как у него уже и так есть открытый дескриптор того же файла, который он может использовать! Поэтому после su никаких ошибок доступа к /dev/ttyp0 не возникает, хотя новый bash уже и не имеет прав доступа к этому файлу. А вот

Код: Выделить всё

cat /dev/ttyp0

или

Код: Выделить всё

echo 0 > /dev/ttyp0

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

Потом до меня дошло, что дальше происходит bash(user) ? screen(user), и screen, соответственно, также имеет всё тот же файл терминала уже открытым . Это для команд cat и echo мы пытаемся отрыть его заново, а screen-то это зачем делать? Он же, пока работает, ввод и вывод и так подаёт нам на экран, то есть использует стандартный ввод и вывод.

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


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

Смог обойти только временным изменением владельца файла терминала на время работы su. Изменение прав доступа — аналогичное решение.

[savio]

а я поставил transmission и не капли не желею. вот у себя черкнул (http://savio.km.ua/2009/07/01/консольны ... терфейсом/) чего делал. сейчас качает себе и проблем нету со скрином

[Chel]

…Немного тут «последопытил» .

/* Может, для кого-то это уже давно известные факты, но для меня всё, что удалось выяснить, — новое. И так углубленно к проблемам в используемом софте я ещё, похоже, не подходил. */


Итак, что удалось выяснить извне (у меня Gentoo GNU/Linux, если что).

screen действительно при запуске получает дескрипторы 0, 1 и 2, указывающие на рассматриваемый файл терминала. Также вместе с ним запускается главный процесс сессии — демон SCREEN, который на самом деле произошёл от того же самого исполняемого файла /usr/bin/screen, но имеет права рута (/usr/bin/screen имеет suid-бит, поэтому смог сам себя запустить с правами рута. Я читал, что возможна установка без suid, но там будут неудобства).

Когда выполняется screen (то есть сессия присоединена) у SCREEN оказывается открыт файл того же терминала, что и у screen-клиента. screen и SCREEN вроде как имеют некоторую область общей памяти, так что через неё, наверное, и передаётся имя этого файла демону SCREEN (ведь подсоединяться через

Код: Выделить всё

screen -r

можно откуда угодно). Наверное, screen-клиент передаёт через общую память демону имя своего управляющего терминала, а тот уже сам к этому терминалу подсоединяется и использует его для ввода-вывода. Теперь можно было бы уже сказать, что именно из-за последнего факта файл терминала должен быть доступным для открытия, но демон SCREEN и так выполняется от рута.

Для всех выполняющихся внутри экранной сессии программ создаётся файл устройства (подчинённого) псевдотерминала, которым, очевидно, управляет SCREEN.


В общем, теперь я лучше стал понимать принцип работы screen. Но! Так и не решён главный вопрос про требование открытия файла терминала. А также я не понял, зачем нужен именованный канал /var/run/screen/S-<user>/<pid>.<session_name> (у меня это здесь), который используется демоном. Поэтому я рискнул-таки поискать в исходниках.


Теперь исследование изнутри.

Оказалось, что screen при старте открывает-таки отдельно файл терминала, на который указывает дескриптор 0 (если не указывает, то ошибка)… но тут же его закрывает, только лишь проверив возможность открытия с O_RDWR.

Я сначала был в недоумении: зачем это надо? Потом заметил, что такое требование выдвигается только к стандартному вводу — и действительно,

Код: Выделить всё

screen | tail -f -

работает, а значит стандартный вывод можно перенаправлять куда угодно безнаказанно — а от стандартного ввода требуется только возможность чтения, но не записи! А без вывода это уже не может быть полноценным терминалом.

Чуть ниже файл опять открыли, но уже без поспешного закрытия. То есть его для чего-то собрались использовать. (Кстати, это ж наверное, и есть момент, когда файл открывается уже самим демоном SCREEN, а не screen-клиентом!) Я поковырял пример

Код: Выделить всё

screen | tail -f -

, и до меня вдруг дошло, что Ctrl+C не убивает весь канал, или даже хотя бы сам screen, а действует только на шелл внутри screen! И только после выхода из этого шелла (и, соответственно, screen) дополнительное нажатие Ctrl+C убивает оставшийся

Код: Выделить всё

tail -f -

. Тут меня и осенило, что файл терминала — не обычный поток ввода или вывода, а файл устройства! И к нему, следовательно, можно применять что-то типа ioctl(). Значит, наверное, можно настроить так, что результаты Ctrl+C будет получать только шелл внутри screen, не смотря на то, что этот же файл открыт в родительских процессах.

Тогда я подумал, что нашёл, наконец, ответ: для правильного использования файла терминала, его надо открывать самому, а не использовать доставшийся по наследству дескриптор. Но теперь — опять в замешательстве: ведь та самая ioctl() применяется не к чему-либо, а именно к уже полученному ранее дескриптору файла устройств, а при наследовании эти самые дескрипторы тупо копируются! Значит, никакой разницы быть не должно!

Кроме того, немного погуглив, узнал, что та самая особенность терминала в случае спецкомбинаций, например Ctrl+C, — посылка сигнала читающему процессу. Но тут опять непонятки: ведь читающих этот файл процессов куча, почему сигнал приходит только последнему шеллу в screen? Ни о каких других особенностях настройки терминала, чтобы он посылал сигнал только «избранным», я не нашёл информации.


В общем, не нашёл я объяснения специального открытия файла терминала. Если поставить требование, чтобы и стандартный ввод, и вывод указывали на терминал, то, по-моему, должна отпадать необходимость открытия его в O_RDWR-режиме.

[Chel]

а я поставил trabsmission и не капли не желею. вот у себя черкнул (http://savio.km.ua/2009/07/01/консольны ... терфейсом/) чего делал. сейчас качает себе и проблем нету со скрином

Я стал использовать rtorrent, потому что его на каждом углу хвалили, как малоресурсожрущий. И теперь привык. И он действительно, как-то не отвлекает на себя внимания.

(Но, кстати, не всегда! Не могу справиться с проблемой: когда подсоединяется пир из локальной сети и начинает тянуть со скростью несколько мегов в секунду, или когда идёт хеширование фильма, всё резко начинает тормозить. При этом rtorrent всегда запускаю с низким приоритетом:

Код: Выделить всё

nice -n15 rtorrent

, но что-то как-то никакого влияния это, похоже, не оказывает .)

А вот вебморду я не ставил: боюсь слишком муторной и времяпожирающей окажется настройка вебсервера и вебморды. Я этого ещё никогда не делал .


А про transmission что-то никаких разговоров нет.

[Гость]

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

А разве сервер с клиентом общаются не через unix domain сокет?

[Chel]

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

А разве сервер с клиентом общаются не через unix domain сокет?

А, да, наверное, для этого там и файл-сокет в /var/run/screen .

[Гость]

А, да, наверное, для этого там и файл-сокет в /var/run/screen .

Блин. Там именованный канал:

Код: Выделить всё

prwx------

Ну, значит, наверное, общаются через него.