Всем привет.
Думаю опытные люди должны легко ответить на мой вопрос.Я не специалист ни в unix-программинге, ни в TCP/IP, но следующее меня смутило и хочется разобраться. Использовал netstat для просмотра состояния сокетов, но как-то захотелось узнать кто держит какой сокет, через man нашел sockstat - просто замечательно, но вот что я увидел:
$ sockstat -4 | grep sshd
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
user sshd 3701 3 tcp4 192.168.9.1:22 192.168.9.3:1557
root sshd 3696 3 tcp4 192.168.9.1:22 192.168.9.3:1557
user sshd 3596 3 tcp4 192.168.9.1:22 192.168.9.3:1535
root sshd 3592 3 tcp4 192.168.9.1:22 192.168.9.3:1535
user sshd 3415 3 tcp4 192.168.9.1:22 192.168.9.3:1484
root sshd 3411 3 tcp4 192.168.9.1:22 192.168.9.3:1484
root sshd 919 3 tcp4 *:22 *:*
Т.е. сокет один, а держут их по два процесса на каждый коннект. Могу предположить, что при коннекте форкается еще один процесс от pid#919 под тем же рутом для обслуживания новоиспеченного сокета, затем уже после логина форкается еще один процесс уже под конкретным пользователем, который, судя по ps, вешается на один из псевдо-tty, и ему же передается тот же самый сокет ибо весь ввод-ввывод через него и идет. Но у мя возник глупый вопрос: а зачем тогда остается в живых процесс от рута? Он владеет сокетом (еще чем-то) или висит как предок для юзерского процесса, чтобы установить корректность выхода последнего? Или как раз ввод-вывод через ttyp использует юзерский процесс, а заворотом ttyp в сеть занимается рутовский? Хотя зачем тогда юзеру владеть сокетом?Заранее огромное спасибо за возможные разъяснения (даже в стиле "почитай то-то").
ps. Еще раз извиняюсь за возможный бред :)
>Но у мя возник глупый вопрос: а зачем тогда остается в живых процесс от рута?Встречные вопросы - а кому он мешает и зачем ему умирать?
1. Есть исходники - значит можно посмотреть.
2. если это сделано девелоперами специально - значит так надо, есть тому веские причины. Не нервничать.
3. Девелоперы могли неаккуратно оставить системные ресурсы не закрытыми. Написать багрепорт девелоперам, если разобрались и поняли что это действительно так.
4. По поводу кому мешает - на embedded linux можем поиметь проблемы (ресурсы-то резко ограничены), да и на сильно загруженном сервере это может вызвать проблемы. Хотя обычно это не мешает никому. В самом крайнем случае - есть исходники, руки, моск и gcc :)
>4. По поводу кому мешает - на embedded linux можем поиметь проблемы
>(ресурсы-то резко ограничены)Но и сессий SSH не будет же сотни...
>>4. По поводу кому мешает - на embedded linux можем поиметь проблемы
>>(ресурсы-то резко ограничены)
>
>Но и сессий SSH не будет же сотни...99% да, но найдется 1%.. ;)
>>Но и сессий SSH не будет же сотни...
>
>99% да, но найдется 1%.. ;)И этот 1% будет использовать какой-нибудь BusyBox :)