Как сохранить вывод консоли в файл

Да, ошибка (вероятно )связана с библиотеками. Я подозреваю, что поскольку вы дали configureпрефикс /usr/local/apache2, библиотеки, созданные для httpd, оказались в /usr/local/apache2/lib, о чем динамический компоновщик не знает.

Есть несколько способов исправить это:

  • Вместо этого используйте пакет , это облегчит вашу жизнь в долгосрочной перспективе:

    sudo apt install apache2
    

или

  • Добавить /usr/local/apache2/libв конфигурацию динамического компоновщика; создайте файл /etc/ld.so.conf.d/apache2-local.conf, содержащий одну строку

    /usr/local/apache2/lib
    

    и запустите sudo ldconfig.

или

  • Пересоберите httpdс префиксом /usr/local, чтобы его двоичные файлы оказались в /usr/local/bin, а его библиотеки — в /usr/local/lib.

(Кстати, запускать configureот имени root не нужно, да и не следует — настраивать и собирать под обычным пользователем, а устанавливать только под root.)

0
19.08.2020, 17:18
3 ответа

Хорошо, кажется, я нашел ответ. Я очень-очень удивлен, что такая простая и нужная ИМХО вещь решается так "нестандартно", но такова жизнь...:-)
В любом случае, спасибо telcoM, который дал мне ссылки, которые ведут к ссылкам и еще ссылкам, и, наконец, позволил найти пакет ttyrpl, который делает именно то, что я хотел.
Поддержка пакета прекратилась примерно 7 -10 лет назад, и мне потребовалось некоторое время, чтобы адаптировать его к моей версии Linux и необходимым библиотекам, но он работает!
Он делает именно то, что я хотел -собирает выходные данные ttyS0/ttyO0 и сохраняет их в файл. И имеет много навороченных опций, хотя мне они не нужны...:-)

0
18.03.2021, 23:12

Попробуйте использовать picocom вместо console=/dev/ttyS0. Есть и другие инструменты, но picocom кажется самым простым.

Если вы используете один из этих инструментов, вы можете использовать трубу и тройник на выходе.

picocom /dev/ttyS0 -b 115200 -l | tee my.log

https://askubuntu.com/q/1010232

0
18.03.2021, 23:12

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

Эти три файловых дескриптора:

  • дескриптор файла #0 :стандартный входной поток или stdinдля краткости.
  • файловый дескриптор #1 :стандартный поток вывода или stdoutдля краткости.
  • файловый дескриптор #2 :стандартный вывод ошибок поток или stderrдля краткости.

Когда программа не передается по конвейеру или не перенаправляется для чтения/записи файла, все эти три файловых дескриптора обычно указывают на устройство TTY, на котором выполняется текущий сеанс входа в систему. Если программа преднамеренно запущена как демон или фоновый/не -интерактивный процесс, все они могут быть направлены в файл (s )или /dev/nullили, возможно, в какое-то средство ведения журнала.

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

Если вы хотите передать все выходные данные из вашего myapplication.shв канал, вам, возможно, придется сделать что-то вроде этого:

myapplication.sh 2>&1 | logger

2>&1говорит: "перенаправить файловый дескриптор #2 в то же место, куда идет #1", и тогда вы можете передавать их оба одновременно.

Вы можете сами проверить это с помощью небольшого скрипта, подобного этому:

#!/bin/sh
echo "this is stdout"
echo "this is stderr" >&2

>&2означает «взять стандартный вывод этой команды и вместо этого отправить его в стандартный поток ошибок».Вероятно, это самый простой способ генерировать вывод stderrв скрипте.

Теперь, если вы запустите этот скрипт, например ./test.sh | od -t x1z, чтобы получить его выходные данные в шестнадцатеричной -форме дампа, вы получите это:

$./test.sh | od -t x1z
this is stderr
0000000 74 68 69 73 20 69 73 20 73 74 64 6f 75 74 0a     >this is stdout.<
0000017

Таким образом, только вывод stdoutобрабатывался командой od.

Если вы добавите 2>&1для объединения обоих потоков, вместо этого вы получите это:

$./test.sh 2>&1 | od -t x1z
0000000 74 68 69 73 20 69 73 20 73 74 64 6f 75 74 0a 74  >this is stdout.t<
0000020 68 69 73 20 69 73 20 73 74 64 65 72 72 0a        >his is stderr.<
0000036

Теперь оба вывода были отправлены в конвейер, что и требуется в вашем случае с | logger.


Ваша вторая командная строка захватывает все, что ваше встроенное устройство получает от терминальной программы, а не то, что встроенное устройство отправляет на терминал:

(stty raw; cat > received.txt) < /dev/ttyO0

Вы сказали, что работаете над встроенной системой, в которой используется параметр ядра console=/dev/ttyO0, поэтому, по сути, /dev/consoleбудет последовательным портом, а не графическим дисплеем (, который может даже не существовать во встроенном устройстве ).

Если вы запускаете эту команду на встроенном устройстве, команды в круглых скобках будут выполняться с их стандартным входным потоком(файловым дескриптором #0 или stdinдля краткости ), назначенным для /dev/ttyO0. Но если вы вводите эту команду через последовательную линию, подключенную к ttyO0, это то, что, вероятно, будет по умолчанию, поэтому это перенаправление ввода может просто перенаправлять -ситуацию как есть.

Устройство /dev/ttyO0является прямым представлением UART, подключенного к вашей терминальной программе на другом компьютере. Когда вы читаете из него, вы получаете только то, что вы вводите в программу терминала:нет возможности прочитать какой-либо вывод, который был ранее отправлен в него. И все, что в него записано, идет прямо в терминальную программу на конце последовательного кабеля.

Командная строка Unix на последовательном порту обычно работает по принципу удаленного эха :, чтобы видеть, что вы пишете в терминальной программе,Драйвер TTY во встроенной системе должен отправлять копию каждого символа, который вы набираете, обратно в терминальную программу. Это поведение не является симметричным :программа терминала также не будет отправлять обратно копию всего, что она получает через соединение через последовательный порт.

Драйвер TTY — сложная вещь, потому что наследие Unix требует, чтобы он был способен делать много вещей, -функция удаленного эха — лишь одна из них.

Когда вы используете stty raw, вы фактически отключаете все обычно -полезные функции драйвера TTY , включая функцию удаленного эха. Таким образом, с этого момента и далее, если что-то явно не читает из /dev/ttyS0и не записывает его обратно прямо в него, вы не увидите, что вы пишете в терминальной программе.

После выхода из команды stty rawлюбой ввод из терминальной программы будет передан команде cat, которая просто передаст его в свой стандартный вывод, как -при вызове без параметров. Но его стандартный вывод теперь перенаправлен в файл received.txt. Итак, что происходит, так это то, что только то, что вы печатаете в терминальной программе, записывается в файл до тех пор, пока команда catне завершится -, и это закончится только тогда, когда она получит конец -из -символ файла (обычно Control+D).

(Из-за того, что оболочка может выполнять буферизацию, выполняющую перенаправление, вывод в файл received.txtможет отсутствовать, если вы не завершите ввод символом конца -из -файла и/или не наберете более одной строки текста.)

Таким образом, кроме отключения функций драйвера TTY, (stty raw; cat > received.txt) < /dev/ttyO0во встроенной системе вообще ничего не делает для захвата любого вывода , который записывается в /dev/ttyO0.Эта команда может использоваться только при устранении неполадок с подключением к последовательному порту :. терминальная программа отправляет на встроенное устройство в самой необработанной форме.


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

Это связано с тем, что если что-то пойдет не так с ядром, запись чего-либо в файл на диске может оказаться невозможной. Гораздо проще просто отправить текст сообщения об ошибке из UART и быть уверенным, что тот, кто его получит, поймает его.

1
18.03.2021, 23:12

Теги

Похожие вопросы