Помогите разобраться со FreeBSD – root не может снять процесс ни по kill, ни по ctrl+C.

Система свежая, FreeBSD 7.0, на персоналке с одноядерным процессором. Единственное отличие от установки по умолчанию – терминалы стали русские (cons25r, но сообщения об ошибках английские), и есть установленные Demos Commander (deco) из дистрибутива deco38.tgz и Midnight Commander, но они даже в автозапуске не прописаны. Вот ссылка на deco38.tgz: http://rapidshare.de/files/48014947/DECO38.TGZ.html http://www.rapidshare.ru/1121771

Терминал 1. login: root password: (пустой) #deco Esc, esc. “Do you want to quit the Demos Commander ?” Yes No Exec shell Выбираю exec shell Видимо по умолчанию стоит шелл csh, а deco запускает sh. #ps [code] PID TT STAT TIME COMMAND 745 v0 Is 0:00.05 login [pam] (login) 753 v0 I 0:00.04 -csh (csh) 757 v0 S 0:00.03 sh -i 774 v0 R+ 0:00.00 ps 746 v1 Is+ 0:00.01 /usr/libexec/getty Pc ttyv1 747 v2 Is+ 0:00.01 /usr/libexec/getty Pc ttyv2 748 v3 Is+ 0:00.01 /usr/libexec/getty Pc ttyv3 749 v4 Is+ 0:00.01 /usr/libexec/getty Pc ttyv4 750 v5 Is+ 0:00.01 /usr/libexec/getty Pc ttyv5 751 v6 Is+ 0:00.01 /usr/libexec/getty Pc ttyv6 752 v7 Is+ 0:00.01 /usr/libexec/getty Pc ttyv7 [/code] #pwd /root #mkfifo fif Далее пример из книжки Робачевского «Операционная система Unix» (2-е издание) с. 25. #while : ; do date >fif; sleep 5; done& #ps [code] PID TT STAT TIME COMMAND 745 v0 Is 0:00.05 login [pam] (login) 753 v0 I 0:00.04 -csh (csh) 757 v0 S 0:00.03 sh -i 779 v0 I 0:00.00 sh -i 780 v0 I 0:00.00 sh -i 782 v0 R+ 0:00.00 ps 746 v1 Is+ 0:00.01 /usr/libexec/getty Pc ttyv1 747 v2 Is+ 0:00.01 /usr/libexec/getty Pc ttyv2 748 v3 Is+ 0:00.01 /usr/libexec/getty Pc ttyv3 749 v4 Is+ 0:00.01 /usr/libexec/getty Pc ttyv4 750 v5 Is+ 0:00.01 /usr/libexec/getty Pc ttyv5 751 v6 Is+ 0:00.01 /usr/libexec/getty Pc ttyv6 752 v7 Is+ 0:00.01 /usr/libexec/getty Pc ttyv7 [/code] Это уже странно. Когда тот же пример запускался, не выходя из deco (просто у него в командной строке набирал), 2 создаваемых процесса назывались не sh -i, а по той командной строке (while и пр.), что я набирал. В csh же, что по умолчанию во FreeBSD, вообще при интерпретации строки вылезает ошибка и пример Робачевского в этом шелле попросту не работает. Продолжаем пример Робачевского #while : ; do awk ‘{print $4}’ fif; done Он начинает с интервалом в 5 секунд выводить текущее время. У Робачевского – «для остановки используйте ^C». Так вот, оно не работает. Появляется ^C на экране, а цифры все идут. Причем, когда все запускалось из-под deco, ^C работало.

Терминал 2. login: root password: (пустой) #ps [code] PID TT STAT TIME COMMAND 745 v0 Is 0:00.05 login [pam] (login) 753 v0 I 0:00.04 -csh (csh) 757 v0 S 0:00.07 sh -i 779 v0 S 0:00.05 sh -i 948 v0 S 0:00.00 sleep 5 949 v0 S+ 0:00.00 awk {print $4} fif 746 v1 Is 0:00.04 login [pam] (login) 923 v1 S 0:00.05 -csh (csh) 946 v1 R+ 0:00.00 ps 747 v2 Is+ 0:00.01 /usr/libexec/getty Pc ttyv2 748 v3 Is+ 0:00.01 /usr/libexec/getty Pc ttyv3 749 v4 Is+ 0:00.01 /usr/libexec/getty Pc ttyv4 750 v5 Is+ 0:00.01 /usr/libexec/getty Pc ttyv5 751 v6 Is+ 0:00.01 /usr/libexec/getty Pc ttyv6 752 v7 Is+ 0:00.01 /usr/libexec/getty Pc ttyv7 [/code] У процессов sleep, awk номера все время меняются (что неудивительно). Пытаемся снять тот процесс, у которого номер не меняется. #kill 779 Нет ответного сообщения. Даем ps и видим, что... процесс жив! #ps [code] PID TT STAT TIME COMMAND 745 v0 Is 0:00.05 login [pam] (login) 753 v0 I 0:00.04 -csh (csh) 757 v0 S 0:00.08 sh -i 779 v0 S 0:00.07 sh -i 1013 v0 S 0:00.00 sleep 5 1014 v0 S+ 0:00.00 awk {print $4} fif 746 v1 Is 0:00.04 login [pam] (login) 923 v1 S 0:00.06 -csh (csh) 1015 v1 R+ 0:00.00 ps 747 v2 Is+ 0:00.01 /usr/libexec/getty Pc ttyv2 748 v3 Is+ 0:00.01 /usr/libexec/getty Pc ttyv3 749 v4 Is+ 0:00.01 /usr/libexec/getty Pc ttyv4 750 v5 Is+ 0:00.01 /usr/libexec/getty Pc ttyv5 751 v6 Is+ 0:00.01 /usr/libexec/getty Pc ttyv6 752 v7 Is+ 0:00.01 /usr/libexec/getty Pc ttyv7 [/code] Такой же эффект на команду #kill 757 Помогает только #shutdown -r now

Если вместо запуска deco набрать просто #sh -i, таких проблем не возникает – процесс, осуществляющий цикл (и его потомки), снимается по первому же ^C.

Что не так?

Добрый день! Насколько я понимаю, есть 3 способа писать-читать в сокеты:

1. Использовать интерфейс сокетов (recv, send). Используется т.н. дескриптор сокета, возвращаемый функциями accept() у сервера и непосредственно socket() у клиента. Правда, socket() у сервера тоже возвращает дескриптор, но после accept() мы имеем дескриптор, «направленный» на конкретного клиента. А поскольку у клиента по одному сокету всегда «висит» один сервер, то там достаточно того, что возвращает socket(). При этом что будет, если сервер запишет что-нибудь через send() и дескриптор, возвращенный ему socket() – неясно. Кто из клиентов это получит? 2. Как известно, дескриптор сокета ничем (с определенной точки зрения) не отличается от дескриптора файла, они указывают на элементы в одной таблице и т.д. Можно (по крайней мере клиенту) закрыть перед подключением 1-й или 2-й дескрипторы через close(), и потом сокет получит этот номер (первый не занятый в таблице дескрипторов), при этом он встанет на место stdout или stderr. Можно будет работать с ним как с stdout, например. Говорили, что в данном случае всю работу на себя возьмет демон inetd. Правда, мне не ясно, можно ли поставить сокет одновременно на место stdin и stdout (видимо, сдублировав дескриптор, например, через fcntl), и каков режим его открытия применительно к обычным режимам открытия файлов (я подозреваю, что у каждого сокета это – одновременно на чтение и запись). И неясно, может ли сервер так делать... 3. Можно, наверное, писать в сокет как в файл. Правда, все функции (fwrite(), fputs() и др.) требуют параметр типа FILE*. Как преобразовать int (дескриптор) в FILE*, ума не приложу.

Все 3 подхода наверняка имеют свои плюсы и минусы. Но я никак не пойму, какие. Прошу совета. Наверное, какой-то более переносим, а какой-то менее? И вы, лично вы, если бы вам дали писать простенький клиент SMTP, скажем, вы бы какой из трех подходов выбрали и почему? А какой бы не выбрали и почему? А если клиент/сервер FTP? (ну и пара вопросов была задана в самой формулировке пунктов 1, 2, 3).

Отложенный или немедленный ^C, ^Z

4. В MS DOS, как известно, Control-Break распознается некоторыми функциями ввода. То есть мало того, что пользователь нажал CTRL-Break, при этом само по себе ничего не произойдет, программа еще не прервется и будет продолжать работу – надо, чтобы программа вызвала функцию чтения MS DOS с клавиатуры, поддерживающую обработку Ctr-Break (если был ctrl—break, из этой функции программа уже не вернется) :) Во FreeBSD есть ^C и ^Z (suspend). Вопрос, они сразу действуют или как в MS DOS, т.е. надо, чтобы программа обратилась к терминалу? Какова внутренняя архитектура этих механизмов?

Все вопросы - http://unixvop.narod.ru/

2. Увидел в протоколе ESMTP, что может быть несколько ответов: ehlo office.company1.tld 250-mail.company2.tld is pleased to meet you 250-DSN 250-SIZE 250-STARTTLS 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-TURN 250-ATRN 250-NO-SOLICITING 250-HELP

Хотя про SMTP было написано в той же Википедии, что ответ всегда 1 строка. (То есть, когда реализуешь протокол SMTP, надо дождаться приема символов 0D 0A в ответ, да?)

Telnet (стандартный, из FreeBSD) работает по схеме "ввели 1 символ - послали", да? И вообще при такой передаче, получив один символ на любой стороне, никак нельзя сказать, собирается ли вторая сторона послать за ним еще символы (считая их неразрывным по смыслу целым) или нет? Т.е. нужно ждать определенного признака, например того же 0D 0A (cr lf)?

Как же тогда можно работать по протоколу ESMTP, ведь откуда клиент знает, сколько строчек ему послал сервер?

3. Что должна делать нормальная функция приема ответа от сервера? Где можно найти ее схему. Имеется в виду надежное соединение, по TCP. Например, есть такая книжка - Теренс Чан. Системное программирование на C++ для Unix. Так у него ничего из нижеперечисленного нету (просто вызов recv(), подразумевается, что он примет абсолютно все данные, посланные другой стороной по одному вызову send(), за один вызов recv). А я современные функции почитал - там целая куча всего. - Вроде бы количество прочитанных байт 0 означает, что у той стороны, наконец, нет ничего, что бы она хотела нам послать. Но с другой стороны, вторая сторона вроде в любой момент может передумать и решить послать еще данные, новым вызовом send... С другой стороны походит, что возврат recv 0 прочитанных байт сродни нулю в ASCIIZ-строке, разделяющему одну строку из идущих подряд от другой. А если мы не успели дочитать первую строку “KISA1”, сервер послал уже вторую “KISA2”... То прочитав 0, мы можем подумать, что более нам ничего не посылали, в то время как там еще вторая строка? Или это неправда? Т.е. что мы прочитаем из сокета: 5 байт + “KISA1” – 0 байт – 5 байт + “KISA2” – 0 байт ? Или : 5 байт + “KISA1” – 5 байт + “KISA2” – 0 байт? Или 10 байт + “KISA1KISA2” – потом 0 байт? - Если прочитано не 0 байт из сокета, то большинство функций чтения (не как у Чана!) читают и читают, пока не прочитают 0 байт. - Надо как-то ловить разрывы соединения (по ошибке) и нормальное закрытие сокета второй стороной (как???? У Теренса Чана об этом ничего не сказано).

Можно ли различить на второй стороне 2 случая: а) первая сторона послала туда первым вызовом send() строку из 40 байт, вторым – еще строку из 40 байт; б) первая сторона послала все 80 байт одним вызовом send(). Я подумывал, что функция recv возвращает 0 прочитанных байт, именно чтобы дать знать, что кончились за один раз посланные данные. Т.е. например в случае с ESMTP когда очередное обращение вернет 0 прочитанных байт, значит мы дочитали все строчки этого длинного ответа сервера (см. выше про ESMTP). А то может быть, если сообщение шло частями (не гарантируется доставка мгновенно и всего сразу), то может ли быть так, что прочитается из сокета первая часть сообщения, а потом, т.к. остаток еще не пришел, то прочитается 0 байт?? Не преждевременно ли будет в таком случае считать ответ полностью полученным. И может ли такое случиться.

Все вопросы - http://unixvop.narod.ru/

Добрый день,

1. Почему в midnight commander атрибут "execute" называется "execute/search"? Что там search? Кто там search? Может быть search имеет значение для директории? Почему тогда атрибута read для этого недостаточно (чтобы дать возможность поиска)?

Гугль по запросу "атрибут search" не дал ничего вразумительного.

Все вопросы - http://unixvop.narod.ru/