Сигнал может быть проигнорирован (потерянный)?

Отключение fcitx (ответственного за азиатские макеты), который установлен по умолчанию, позволяет kde нормально обрабатывать макеты. Его можно даже удалить или отключить от запуска при запуске. На панели задач появится значок.

Вы можете сделать это только с head и базовой арифметикой, если группировать команды с {...;} с помощью конструкции, такой как

{ head -n ...; head -n ...; ...; } < input_file > output_file

, где все команды имеют один и тот же ввод (спасибо @ mikeserv ).
Получение строк 6-11 и строк 19-24 эквивалентно:

head -n 5 >/dev/null  # dump the first 5 lines to `/dev/null` then
head -n 6             # print the next 6 lines (i.e. from 6 to 11) then
head -n 7 >/dev/null  # dump the next 7 lines to `/dev/null` ( from 12 to 18)
head -n 6             # then print the next 6 lines (19 up to 24)

Таким образом, в основном, вы бы запустить:

{ head -n 5 >/dev/null; head -n 6; head -n 7 >/dev/null; head -n 6; } < input_file > output_file

Вы не можете доверять, что каждый посланный сигнал будет доставлен. Например, ядро linux «объединяет» SIGCHLD , если процесс занимает много времени при обработке SIGCHLD из завершенного дочернего процесса.

Чтобы ответить на другую часть вашего вопроса, сигналы становятся «в очередь» внутри ядра, если количество различных сигналов поступает за слишком короткий интервал.

Использовать sigaction () для настройки обработчика сигнала с элементом sa _ sigaction siginfo _ t , тщательно установив элемент sa _ mask аргумента siginfo _ t . Я думаю, это означает маскирование всех «асинхронных» сигналов, по крайней мере. В соответствии со страницей для Linux sigaction () , вы также маскируете обрабатываемый сигнал. Я думаю, вы должны установить член sa _ flags на SA_SIGINFO, но я не могу вспомнить, почему у меня это суеверие. Я верю, что это даст вашему процессу обработчик сигнала, который остается установленным без условий гонки, и тот, который не прерывается большинством других сигналов.

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

Кроме того, необходимо тщательно протестировать код обработки сигналов. Поместите его в небольшой тестовый процесс и отправьте как можно больше SIGUSR1 и SIGUSR2 сигналов, возможно, из 2 или 3 специальных программ передачи сигналов. Смешайте также некоторые другие сигналы, после того как вы уверены, что ваш код может обрабатывать SIGUSR1 и SIGUSR2 быстро и правильно. Подготовьтесь к сложной отладке.

Если вы используете linux и только linux, вы можете подумать об использовании signalfd () для создания дескриптора файла, который вы можете выбрать () или опросить для получения этих сигналов. Использование signalfd () может упростить отладку.

Исправление @ jimmij

первоначально я написал это с неправильной оболочки в виду (bash вместо zsh). ниже отражает исправленный код

От этот ответ stackoverflow :

history | cut -c 8-

И далее, чтобы ограничить историю поддерживают определенное число линий, пробег

history -<number of lines> (history -20 prints the last 20 entries)

Наконец: история-20 | сократила-c 8-> Удар commands_list.sh

#!/bin/bash #!/bin/zsh в начале того файла, chmod +x commands_list.sh, сделанный.

Ни udev , ни DKMS нельзя адекватно охарактеризовать как «путь динамического управления всеми подключенными/отключенными драйверами устройств в системе Linux». Udev динамически управляет устройствами , а не драйверами - создает записи в /dev при подключении устройства. DKMS относится к драйверам, но не имеет никакого отношения к поиску драйвера для устройства: это способ компиляции драйверов сторонних производителей из источника при установке ядра.

Когда ядро обнаруживает устройство, для которого отсутствует драйвер, оно вызывает программу modprobe , чтобы попытаться загрузить модуль, предоставляющий этот драйвер. Программа modprobe в свою очередь обращается к базе данных, созданной depmod , которая проходит через файлы модулей ( * .ko ), расположенные в /lib/modules/ VERSION /. Более подробное описание этого механизма см. в debian не обнаруживает последовательную PCI-карту после перезагрузки .

Номинальная последовательность событий при подключении устройства и отсутствии драйвера в памяти:

1. Ядро вызывает modprobe для загрузки драйвера.
2. modprobe загружает файл модуля из /lib/modules .
3. Теперь, когда драйвер доступен, ядро уведомляет udev о наличии нового устройства.
4. udev создает запись под /dev для нового устройства.

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

DKMS вмешивается, когда драйвер не является частью ядра Linux. Трудно создать бинарный модуль, который работает между версиями ядра и параметрами компиляции. DKMS - это рамка для автоматической компиляции модулей для установленного ядра (ядер); модули распределяются как исходный код.

Гарантированно доставляется сигнал, в том смысле, что если процесс успешно вызовет kill , то цель получит сигнал. Это асинхронно:отправитель не имеет пути знать, когда сигнал принимается или обрабатывается. Однако это не гарантирует, что сигнал будет доставлен. Цель может погибнуть, прежде чем она сможет обработать сигнал. Если цель игнорирует сигнал во время его доставки, сигнал не будет иметь эффекта. Если цель получает несколько экземпляров одного и того же номера сигнала до того, как сможет их обработать, сигналы могут (и обычно) объединяться: если отправить один и тот же сигнал дважды в процесс, вы не можете знать, получит ли процесс сигнал один или два раза. Сигналы в основном предназначены для уничтожения процесса или как способ заставить процесс обратить внимание, они не предназначены для связи как таковой.

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

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

Из signal(7) manual page:

Сигналы реального времени отличаются следующим:

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

Попробуйте использовать сигнал с номером в диапазоне от SIGRTMIN до SIGRTMAX.