/dev/log
Я думаю, что во время создания размер устройства был зарегистрирован где-то в метаданных. Смена контроллера не изменит метаданные.
Удалите запасной диск из md, затем добавьте его в RAID-массив как новый диск. Вероятно, придется удалить метаданные (проверьте на странице руководства --zero-superblock или сотрите весь диск). Если это сработает для одного диска, повторите процедуру для всех оставшихся дисков. Затем выполните команду --grow.
Не извлекайте дополнительные диски до завершения синхронизации!!!
Чтобы добавить некоторую дополнительную информацию к принятому (правильному )ответу, вы можете увидеть, в какой степени /dev/logявляется просто сокетом UNIX, записав его как таковой:
lmassa@lmassa-dev:~$ echo 'This is a test!!' | nc -u -U /dev/log
lmassa@lmassa-dev:~$ sudo tail -1 /var/log/messages
Sep 5 16:50:33 lmassa-dev journal: This is a test!!
В моей системе вы можете видеть, что процесс journald прослушивает этот сокет:
lmassa@lmassa-dev:~$ sudo lsof | grep '/dev/log'
systemd 1 root 29u unix 0xffff89cdf7dd3740 0t0 1445 /dev/log
systemd-j 564 root 5u unix 0xffff89cdf7dd3740 0t0 1445 /dev/log
Он получил мое сообщение и сделал с ним свое дело :(, то есть добавил в файл /var/log/messages ).
Обратите внимание, что, поскольку протокол системного журнала, о котором говорит journald, ожидает дейтаграммы (думать UDP ), а не потоки (думать TCP ), если вы просто попытаетесь записать в сокет напрямую с помощью nc, вы Вы увидите ошибку в системном вызове (и журнал не появится ).
Сравните:
lmassa@lmassa-dev:~$ echo 'This is a test!!' | strace nc -u -U /dev/log 2>&1 | grep connect -B10 | egrep '^(socket|connect)'
socket(AF_UNIX, SOCK_DGRAM, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/dev/log"}, 10) = 0
lmassa@lmassa-dev:~$ echo 'This is a test!!' | strace nc -U /dev/log 2>&1 | grep connect -B10 | egrep '^(socket|connect)'
socket(AF_UNIX, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/dev/log"}, 10) = -1 EPROTOTYPE (Protocol wrong type for socket)
Примечание. Для ясности я опустил некоторые системные вызовы. Важным моментом здесь является то, что первый вызов задавал SOCK _DGRAM, а это то, что ожидает сокет /dev/log (, поскольку именно так сокет /dev/logбыл создан первоначально ), тогда как второй сделал не так, мы получили ошибку.
Вы должны проверить журнал /run/systemd/journal/dev -, его разрешения и тех, кто его использует. Вы проверяли ссылку.
Я обобщаю комментарии к полному ответу. Обратите внимание, что @MarkPlotnick первым указал на правильное решение.
Как вы можете видеть в выводе ls -lL, файл, на который указывает ваша ссылка, является сокетом , не обычным файлом или каналом.
~$ ls -lL /dev/log
srw-rw-rw- 1 root root 0 Aug 23 07:13 /dev/log
Посмотрите на первый символ вывода. Это sозначает, что файл является сокетом.
Вы не можете использовать механизм перенаправления >изbash(или, AFIK, любую другую оболочку )для записи в сокет, потому что оболочка попытается открыть файл и openне поддерживает сокеты. Подробнее см. man open .
Вы должны использовать программу, которая подключается к сокету. Подробнее см. man connect .
В качестве примера вы можете использовать netcatилиsocat(см. Как я могу взаимодействовать с сокетом домена Unix через оболочку в Debian Squeeze?).
Для полноты картины можно использовать перенаправление по каналам.
~$ mkfifo /tmp/fifo
~$ ls -l /tmp/fifo
prw-rw-rw- 1 root root 0 27 ago 15.04 /tmp/fifo
~$ echo "hello" > /tmp/fifo
Посмотрите на первый символ вывода ls. Это pозначает, что файл является каналом.