Куда идут журналы, направленные в / dev / console?

Причина не историческая, а практическая. Существует много многих программ, которые работают поверх ядра Linux; если интерфейс ядра разрывает эти программы, то все должны обновить эти программы.

Теперь верно, что большинство программ на самом деле зависят не непосредственно от интерфейсов ядра (системные вызовы ), а только от интерфейсов стандартной библиотеки C (оболочки C вокруг системных вызовов). О, но какая стандартная библиотека? Глибк? uClibC? Дитлиб? Бионик? Мюсл? и т.д.

Но есть также много программ, которые реализуют специфичные для ОС службы и зависят от интерфейсов ядра, которые не доступны стандартной библиотеке. (В Linux многие из них предлагаются через /proc и /sys .)

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

Даже когда источник доступен, собрать все это может быть боль. Особенно при обновлении ядра, чтобы исправить ошибку с помощью оборудования. Люди часто обновляют свое ядро независимо от остальной системы, потому что они нуждаются в аппаратной поддержке. В словах Линус Торвальдс :

Ломка пользовательских программ просто неприемлема. (…) Мы знаем, что люди используют старые двоичные файлы годами и годами, и что создание нового выпуска не означает, что вы можете просто выбросить это. Ты можешь доверять нам.

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

несколько нормально иметь четко определенную одностороннюю зависимость. Это грустно, но иногда неизбежно. (…) Что НЕ нормально, так это иметь двустороннюю зависимость. Если пользовательский HAL-код зависит от нового ядра, это нормально, хотя я подозреваю, что пользователи надеются, что это будет не «ядро недели,» а скорее «ядро последних нескольких месяцев.»

Но если у вас двусторонняя зависимость, вы облажались. Это означает, что вы должны обновить на этапе блокировки, и это просто НЕ ПРИЕМЛЕМО. Это ужасно для пользователя, но еще более важно, что это ужасно для разработчиков, потому что это означает, что вы не можете сказать «ошибка случилась» и делать такие вещи, как попытаться сузить его с помощью бисекции или тому подобное.

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

Официально ,

обратная совместимость для [системных вызовов, объявленных стабильными] будет гарантирована в течение не менее 2 лет.

Однако на практике

Большинство интерфейсов (например, syscalls)ожидается, что они никогда не изменятся и всегда будут доступны.

Чаще всего изменяются интерфейсы, предназначенные только для использования аппаратными программами в /sys . (/proc , с другой стороны, которая с момента введения /sys была зарезервирована для услуг, не связанных с оборудованием, практически никогда не ломается несовместимыми способами.)

В итоге,

разрыв пользовательского пространства потребует исправления на уровне приложения

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

Как упоминалось выше, вы не можете знать наверняка.

Одна из основных эвристик, которую я лично использую:

• прочитайте PKGBUILD и узнайте, с каких веб-сайтов он загружает программное обеспечение. Там, где вы ожидали? Это из надежного источника? Возьмем spotify например, его источник ' http://repository.spotify.com/pool/non-free/s/spotify-client/spotify-client_1.0.15.137.gbdf68615_amd64.deb '

Если бы я собирался попытаться установить это вручную, я бы все равно загрузил его с spotify.com, так что это нормально в моих книгах. Краткое прочтение остальной части PKGBUILD, и это, кажется, не делает ничего явно необычного. Конечно, есть способы быть вкрадчивым, но я думаю, что главной целью для любого вредоносного кода на AUR были бы люди, использующие yaourt и т.д., которые обычно не читают PKGBUILD до того, как они установят программное обеспечение и не обнаружат проблему, даже если это было очевидно.

Убедитесь, что syslogd запущен. Убедитесь, что в /etc/rsyslog.conf включен модуль локального ведения журнала.

$ModLoad imuxsock # provides support for local system logging

Можно всегда выводить данные в файл вместо консоли.

ie:
kern.notice      /var/log/kern.log

Для просмотра выходных данных файла журнала в режиме реального времени с любой консоли можно использовать tail -f/var/log/kern.log .

Консоль может быть любым устройством tty, включая виртуальный tty, например / dev / tty1 , настоящий терминал, например последовательный порт / dev / ttyS0 , или псевдо-терминал, например / dev / pts / 8 .

Начальная консоль устанавливается при загрузке, и вы можете указать ее с помощью параметра загрузки, например console = ttyS0,9600 , где 9600 - скорость передачи данных. Обычно на машинах с графикой это первый виртуальный tty, к которому вы можете подключиться с помощью chvt или ctrl-leftalt-1 или аналогичных.

Вы можете изменить консоль, выполнив ioctl (fd, TIOCCONS, 0) , где fd - это tty, и у вас есть достаточные разрешения (обычно root). См. Man tty_ioctl.

Чтобы поэкспериментировать, есть команда console on в утилите screen , которая превратит ваш pty в консоль, хотя вы должны быть root, чтобы она работала, а ваш хост должен поддерживайте ioctl TIOCCONS.