работа с модемом через screen

общение с модемом через миником это же не цель?

Обычно такие проблемы бывают из-за буферизации. Это можно увидеть strace-ом. Нужна либо строчная буферизация или совсем без нее. Или fflush после вывода каждой команды в порт.

спасибо
подскажите, эта буферизация определяется командами к модему (например команда для включения строчной буферизации) или это делается в софте (в моем случае модули питона pygsm/serial)?

пока не нагуглил ничего вразумительного

в софте.

Запустри программу через strace и увидишь, сразу данные передаются в модем или нет.

я приаттачил к питоновскому процессу

psgrep python3
user 27876 18.0 0.2 477720 22452 ? Sl 22:47 0:00 /usr/local/bin/python3 /home/user/start.py

sudo strace -p 27876 -o test

Однако в файле минимум информации:

cat test
futex(0x11e9e10, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x12cece0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x12d9fa0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x7f60980008c0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x87e424, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x87e420, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x87e3e0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x12f4590, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
write(1, «<script>clearInterval(window.tim»..., 48) = 48
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f60b85e3880}, {0x4df770, [], SA_RESTORER, 0x7f60b85e3880}, 8) = 0
exit_group(0) = ?
+++ exited with 0 +++

Похоже это то, что питон отвечает апачу, которым он запускается как cgi

Последил за миникомом, там вроде все в порядке.
Как же отследить что и когда пишется в устройство /dev/ttyUSB0 питоном?

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

IMHO оно у тебя тредовое, а это всегда дополнительный набор граблей ( во всем ).

Кстати, дурацкий вопрос - а uid/gid из под которого идет обмен с модемом имеет права на запись в /dev/ttyUSB0 ?

Отладка через веб-вервер весьма утомительна. Что мешает взять кусок кода и запустить его отдельно?

PS это в development нужно переносить.

интересен только процесс, который взаимодействует с модемом

точно, у меня к модему подключаются отдельные треды

имеет права на запись в /dev/ttyUSB0 ?

да, скрипт просто делает «sudo chmod 666 /dev/ttyUSB0» при запуске

Что мешает взять кусок кода и запустить его отдельно

спасибо, так и сделаю

Вот ещё интересный момент: 15 потоков одновременно начали работать с устройствами /dev/ttyUSB0-14

сделали некоторые действия, но потом разом все отвалились.
ls показал что в системе больше нет USB0-14, зато появились USB15-30

что это вообще было?
как многопоточный питон может убивать устройство?

*usb-шнур один, это пул модемов

дык dmesg обычно при этом говорит нехорошие слова в адрес usb-устройств, ресетит их и находит под новым именем ( т.к. старое еще используется)

Нужно настраивать udev чтоб после ресета устройства и последующего его обнаружения об этом узнавала программа работавшая с ним (например через сигналы (и снова здрасте треды)) и чтоб устройству сохраняли имя (как это сделать - сильно зависит от usb-устройства)