Как создать файл rules
Обновлено: 08.07.2024
Обычно, когда правила используются в приложении рабочего процесса, они являются частью сборки. В некоторых случаях, возможно, потребуется создать наборы правил отдельно от сборки, чтобы можно было обновлять их, без повторного построения и развертывания сборки рабочего процесса. Этот пример позволяет управлять наборами правил и изменять их в базе данных, а также получать доступ к этим наборам правил из рабочего процесса во время выполнения. Это позволяет запускать экземпляры рабочего процесса, чтобы автоматически включать изменения в наборах правил.
пример внешнего набора правил набор средств содержит средство на основе Windows Forms, которое можно использовать для управления и редактирования версий набора правил в базе данных. Также включены действие и служба размещения для выполнения этих правил.
для этого примера требуется Microsoft SQL Server.
Visual Studio предоставляет редактор набора правил в составе Windows Workflow Foundation (WF). Редактор запускается двойным щелчком действия Policy в рабочем процессе; редактор выполняет сериализацию объекта набора правил в файл с расширением RULES, связанный с рабочим процессом (действие Policy запускает экземпляр набора правил из рабочего процесса). При построении проекта рабочего процесса выполняет компиляция в сборку файла с расширением RULES как ресурса.
Компоненты данного образца включают следующее:
Средство пользовательского графического интерфейса набора правил, которое используется для редактирования и управления версиями набора правил в базе данных.
Служба набора правил, настройка которой выполняется в ведущем приложении, осуществляет доступ к наборам правил из базы данных.
Действие ExternalPolicy запрашивает набор правил из службы набора правил и запускает набор правил из рабочего процесса.
Взаимодействие компонентов показано на следующем рисунке. В следующих разделах приведено описание каждого из компонентов.
Средство "RuleSet"
На следующем рисунке показан снимок экрана средства создания правил. В меню хранилище правил можно загрузить доступные наборы правил из базы данных и сохранить измененные наборы правил обратно в хранилище. Файл конфигурации приложения предоставляет строку подключения базы данных для базы данных набора правил. При запуске это средство автоматически загружает наборы правил из настроенной базы данных.
Средство "RuleSet" служит для применения основного и вспомогательного номеров версий к наборам правил, что позволяет одновременно создавать и хранить несколько версий (средство не предоставляет возможности блокировки или другие возможности управления конфигурацией, помимо поддержки версий). С помощью данного средства можно создавать новые версии набора правил или удалять существующие версии. При нажатии кнопки создать средство создает новое имя набора правил и применяет версию 1,0. При копировании версии средство создает копию выбранной версии набора правил, включая содержащиеся правила, и присваивает новые уникальные номера версий. Эти номера версий основаны на номерах версий существующих наборов правил. Имя и номера версий набора правил можно изменить с помощью связанных полей на форме.
При нажатии кнопки изменить правила запускается редактор набора правил, как показано на следующем рисунке:
это повторное размещение диалогового окна редактора, которое является частью надстройки Windows Workflow Foundation Visual Studio. Оно предоставляет тот же набор функциональных возможностей, включая поддержку Intellisense. Правила создаются для целевого типа (например, рабочего процесса), связанного с набором правил в средстве. Если нажать кнопку Обзор в главном диалоговом окне средства, откроется диалоговое окно выбора рабочего процесса или типа , как показано на рис. 4.
Рисунок 4. Выбор рабочего процесса или типа
Путь к файлу сборки и набору правил типа name are stored with the в базе данных, чтобы при извлечении набора правил из базы данных средство предпримет попытку автоматически загрузить целевой тип.
При нажатии кнопки ОК в диалоговом окне выбора рабочего процесса или типа он проверяет выбранный тип на соответствие с набором правил, чтобы убедиться, что целевой тип содержит все элементы, на которые имеются ссылки в правилах. Ошибки отображаются в диалоговом окне ошибок проверки . Можно выбрать продолжение изменения, несмотря на ошибки, или нажмите кнопку Отмена. В меню Сервис диалогового окна основное средство можно нажать кнопку проверить , чтобы повторно проверить версию набора правил на соответствие целевому действию.
В меню данные в средстве можно импортировать и экспортировать наборы правил. При нажатии кнопки Импорт появляется диалоговое окно выбора файла, в котором можно выбрать файл rules. Это может быть файл, изначально созданный в Visual Studio. В RULES-файле должен содержаться сериализованный экземпляр RuleDefinitions с коллекцией условий и коллекцией наборов правил. средство не использует коллекцию условий, но использует RuleDefinitions формат. rules, чтобы разрешить взаимодействие с Visual Studioной средой.
После выбора файла rules открывается диалоговое окно выбора набора правил . Можно использовать диалоговое окно для выбора наборов правил из файла, который требуется импортировать (по умолчанию указаны все наборы правил). Наборы правил в RULES-файле не содержат номеров версии, поскольку их версии в рамках проекта WF совпадают с версией сборки. Во время процесса импорта средство автоматически назначает следующий доступный основной номер версии (который можно изменить после импорта); Номера назначенных версий можно просмотреть в списке выбора набора правил .
При нажатии кнопки Экспорт данных в главном меню средства диалоговое окно выбора набора правил появляется снова, из которого можно определить наборы правил из базы данных, которую необходимо экспортировать. При нажатии кнопки ОК появляется диалоговое окно Save File (сохранить файл ), в котором можно указать имя и расположение результирующего файла rules. Поскольку в RULES-файл не содержатся сведения о версии, для заданного имени набора правил можно выбрать только одну версию набора правил.
Действие "PolicyFromService".
Код для действия PolicyFromService является прямолинейным. Функционирование этого кода во многом аналогично действию Policy , предоставляемому в WF, однако вместо извлечения конечного набора правил из RULES-файла данный код выполняет вызов службы размещения, чтобы получить экземпляр набора правил. Затем код запускает набор правил из экземпляра действия корневого рабочего процесса.
После того, как действие помещено в рабочий процесс, необходимо указать имя набора правил, который требуется запустить. Можно ввести имя как буквенное значение, либо выполнить привязку к переменной рабочего процесса или свойству другого действия. Дополнительно можно задать номера версий для конкретного набора правил, который требуется запустить. Если оставить значение по умолчанию "0" для основного и вспомогательного номеров версий, действию будет автоматически присвоен номер последней версии в базе данных.
Служба "RuleSet"
Эта служба отвечает за извлечение заданной версии набора правил из базы данных и ее возврат в вызывающее действие. Как уже обсуждалось ранее, если значения основной и вспомогательной версии, переданные в вызов GetRuleSet оба равны "0", служба выполняет извлечение последней версии. На этой стадии не выполняется кэширование определений или экземпляров набора правил; также, отсутствуют функции пометки версий набора правил как "развертываемых", чтобы отличить их от наборов правил в процессе выполнения.
База данных, доступ к которой осуществляется службой, должна быть настроена на узле с помощью файла конфигурации приложения.
Запуск средства
В папке, в которой задана таблица набора правил, используемая средством и службой, также содержится файл "Setup.sql". Можно запустить пакетный файл "Setup.cmd", чтобы создать базу данных правил в SQL Express и задать таблицу набора правил.
При редактировании пакетного файла или файла "Setup.sql", если использование SQL Express или размещение таблицы в базе данных с именем, отличным от Rules , не задано, файлы конфигурации приложения в средстве "RuleSet" и проекты UsageSample следует редактировать, используя одинаковые сведения.
После запуска скрипта "Setup.sql" можно построить решение ExternalRuleSetToolkit , а затем запустить средство "RuleSet" из проекта "ExternalRuleSetTool".
Решение консольного приложения последовательного рабочего процесса RuleSetToolkitUsageSample включает образец рабочего процесса. Рабочий процесс включает действие PolicyFromService и две переменные: orderValue и discount , для которых выполняется запуск конечного набора правил.
Чтобы использовать этот образец, необходимо построить решение RuleSetToolkitUsageSample . Затем в главном меню средства набора правил щелкните Импорт данных и укажите файл дискаунтрулесет. rules в папке рулесеттулкитусажесампле. Щелкните пункт меню хранилище правил — сохранить , чтобы сохранить импортированный набор правил в базе данных.
Поскольку ссылка на сборку PolicyActivities дана из образца проекта рабочего процесса, действие PolicyFromService используется в рабочем процессе. Тем не менее, это оно не отображается на панели инструментов по умолчанию. Чтобы добавить действие на панель инструментов, необходимо сделать следующее.
Щелкните правой кнопкой мыши панель элементов и выберите пункт Выбрать элементы (это может занять некоторое время).
Когда откроется диалоговое окно Выбор элементов панели элементов , перейдите на вкладку действия .
Перейдите к PolicyActivities сборке в ExternalRuleSetToolkit решении и нажмите кнопку Открыть.
Убедитесь, что PolicyFromService действие выбрано в диалоговом окне Выбор элементов панели элементов , и нажмите кнопку ОК.
Теперь действие должно отобразиться в области элементов в категории компоненты рулесеттулкитусажесампле .
Служба "RuleSet" уже настроена на узле консольного приложения с помощью приведенного ниже оператора в файле "Program.cs".
Можно также настроить службу на узле с помощью файла конфигурации. Дополнительные сведения см. в документации по пакету SDK.
Файл конфигурации приложения добавляется в проект рабочего процесса, чтобы указать строку подключения для базы данных, которая будет использоваться службой. Средством "RuleSet" должна использоваться та же строка подключения, что указывает на базу данных, содержащую таблицу набора правил.
Теперь можно выполнить проект RuleSetToolkitUsageSample , а также остальные консольные приложения рабочего процесса. нажмите клавишу F5 или Ctrl + F5 в Visual Studio или непосредственно запустите RuleSetToolkitUsageSample.exe файл.
Чтобы повторную скомпилировать выборку использования, необходимо закрыть средство "RuleSet", поскольку средство загружает сборку выборки использования.
Начнём с небольшого введения для новичков. Философия Unix гласит, что всё есть файл. Таким образом, файлы в Unix - это не только информация, хранимая на жёстком диске, но и устройства. Да, в Linux жёсткий диск, мышь, клавиатура, флешка, сетевой адаптер и другие устройства имеют свои файлы, с помощью которых с ними и взаимодействуют различные системные программы.
Все файлы устройств хранятся в каталоге /dev. Этот каталог генерируется во время загрузки специальным сервисом - udev. Происходит это на основе подключённых к компьютеру устройств и определённых правил. По умолчанию в udev уже заложены все необходимые для нормальной работы устройств правила. Но некоторые пользователи хотят самим настраивать устройства и выбирать им имена и права доступа. Кроме того, понимание процесса генерации файлов устройств даёт возможность глубже понять работу операционной системы.
Правила udev помогут вам, если вы хотите:
- переименовать устройство, например жёсткий диск или сетевую карту;
- создать дополнительное имя для устройства;
- поменять права доступа к устройству;
- установить владельца и группу;
- выполнить скрипт при подключении или отключении устройства.
Общая информация про udev
Правило udev состоит из нескольких пар ключ - значение, разделённых запятой. Одни ключи используются для проверки соответствия устройства определённому правилу. В таких ключах используется знак == для разделения пары, например: SUBSYSTEM == "block". Это значит, что правило будет применено, только если значение ключа SUBSYSTEM для этого устройства равно block. Другие ключи используются для указания действия, если все условия соответствия выполняются. Для разделения пар в таких ключах используется знак равно " mydisk". Ну и полностью правило:
SUBSYSTEM=="block", ATTR(size)=="1343153213", NAME="mydisk"
Это правило выполниться только для устройства подсистемы block и с размером 1343153213 байт. Откуда брать эти значения, мы рассмотрим ниже, а пока разберёмся, что же значат те или иные ключи. Сначала ключи соответствия:
- SUBSYSTEM - подсистема устройства;
- KERNEL - имя, выдаваемое устройству ядром;
- DRIVER - драйвер, обслуживающий устройство;
- ATTR - sysfs-атрибут устройства;
- SUBSYSTEMS - подсистема родительского устройства.
Устройство может иметь родительские устройства, например, жёсткий диск имеет родительское устройство SSCI, которое в свою очередь имеет родительское устройство - шину BUS. Иногда необходимо получить информацию от родительского устройства. Для этого используются ключи SUBSYSTEMS, KERNELS, DRIVERS, ATTRS соответственно.
Для действий используются ключи:
- NAME - установить имя файла устройства;
- SYMLINK - альтернативное имя устройства;
- RUN - выполнить скрипт при подключении устройства;
- GROUP - группа, у которой есть доступ к файлу;
- OWNER - владелец файла устройства;
- MODE - маска прав доступа.
Рассмотрим подробнее ключ ATTR. Он позволяет получить информацию об устройстве, доступную в sysfs. Например, ATTR=13413423124, если размер устройства равен 13413423124. Посмотреть все возможные sysfs-параметры для устройства можно непосредственно в файловой системе /sys. Например, для диска /dev/sda есть каталог /sys/block/sda/, в котором можно найти файлы size, stat, ro, range и т д. Также посмотреть все возможные udev- параметры для устройства можно с помощью утилиты udevadm. Например, для диска /dev/sda:
udevadm info -a -n sda1
Опция -n задаёт имя устройства, -p - путь в sysfs. Например, то же самое получим, если выполнить:
udevadm info -a -p /sys/block/sda/sda1
Как переименовать устройство в Linux
Теперь на основе полученной из udevadm информации можем составить udev rules для добавления альтернативного имени диска:
SUBSYSTEM=="block", ATTR=="976773168", SYMLINK+="root"
Или смены названия:
SUBSYSTEM=="block", ATTR=="976773168", name="root"
Получим устройство /dev/root, которое будет указывать на корневой раздел (sda1), то же самое можно сделать для привода оптических дисков:
udevadm info -a -p /sys/block/sr0
Затем добавляем правило на основе модели:
SUBSYSTEM=="block", ATTRS=="DVDRAM GH22NS70 ", SYMLINK+="cdrom"
После перезагрузки появится файл устройства /dev/cdrom. Хотя, конечно, это можно сделать без udev, прописав в автозагрузку команду создания символической ссылки:
ln -s /dev/sr0 /dev/cdrom
Как переименовать сетевую карту
Настройка udev Linux на этом не заканчивается. Сетевая карта - тоже устройство и тоже управляется udev. Файлы сетевых устройств хранятся в /sys/class/net. Поэтому получаем информацию о ней с помощью udevadm:
udevadm info -a -p /sys/class/net/enp24s0
И создаём правило, например на основе mac-адреса:
SUBSYSTEM=="net", ATTR=="00:d8:61:16:a5:a5", NAME="eth0"
Перезагружаем компьютер, и теперь устройство называется eth0.
Как запустить скрипт при подключении устройства
Например, мы хотим автоматически скопировать все данные с флешки при её подключении к компьютеру. Мы знаем, что флешка будет называться /dev/sdb, тогда можно создать правило udev такого вида:
При подключении флешки выполнится скрипт /usr/bin/my_script и сделает необходимые действия. Нужно заметить, что скрипт не должен выполняться слишком долго, так как udev остановится и будет ожидать завершения его работы.
Отладка правил
Если вы не уверены, правильно ли составлено правило, можно воспользоваться командой udevadm test для проверки. В единственном параметре нужно передать путь sysfs-устройства. Например, проверим наше правило для жёсткого диска:
udevadm test /sys/block/sda
Среди многочисленного вывода видим строчку:
creating link '/dev/root' to '/dev/sda'
Значит всё работает, и настройка udev выполнена успешно. Если же в правиле допустить синтаксическую ошибку, например UBSYSTEM вместо SUBSYSTEM, udevadm test выдаст что-то подобное:
Здесь мы видим саму причину ошибки, неверный ключ, а также файл и строку, в которой допущена ошибка.
Выводы
На этом всё. Теперь вы знаете, как создать правило udev и взять под полный контроль все ваши устройства. Если нужна более подробная информация по созданию и использованию правил udev, читайте официальную документацию по udev в man.
Udev (userspace /dev) — это подсистема Linux для динамического обнаружения устройств и управления ими, начиная с версии ядра 2.6. Это замена devfs и hotplug.
Она динамически создаёт или удаляет узлы устройств (интерфейс для драйвера устройства, который появляется в файловой системе, как если бы это был обычный файл, хранящийся в каталоге /dev) во время загрузки или если вы добавляете устройство или удаляете устройство из системы. Затем она передаёт информацию об устройстве или изменениях его состояния в пользовательское пространство.
Её функция состоит в том, чтобы 1) снабжать системные приложения событиями устройств, 2) управлять разрешениями узлов устройств и 3) создавать полезные символические ссылки в каталоге /dev для доступа к устройствам или даже переименовывать сетевые интерфейсы.
Одним из плюсов udev является то, что она может использовать постоянные имена устройств, чтобы гарантировать согласованное именование устройств при перезагрузке, несмотря на порядок их обнаружения. Эта функция полезна, потому что ядро просто назначает непредсказуемые имена устройств в зависимости от порядка обнаружения.
В этой статье мы узнаем, как использовать Udev для обнаружения устройств и управления ими в системах Linux. Обратите внимание, что большинство, если не все основные современные дистрибутивы Linux, поставляются с Udev как часть установки по умолчанию.
Изучите основы Udev в Linux
Демон udev, systemd-udevd (или systemd-udevd.service) взаимодействует с ядром и получает события устройства непосредственно от него каждый раз, когда вы добавляете или удаляете устройство из системы, или когда устройство меняет своё состояние.
Udev основан на правилах — правила гибкие и очень мощные. Каждое полученное событие устройства сопоставляется с набором правил, считываемых из файлов, расположенных в /lib/udev/rules.d, /usr/lib/udev/rules.d и /run/udev/rules.d.
Чтобы создать файл узла устройства, udev необходимо идентифицировать устройство с помощью определённых атрибутов, таких как label, serial number (метка, серийный номер), его основной и дополнительный номер, номер устройства шины и многое другое. Эта информация экспортируется файловой системой sysfs.
Каждый раз, когда вы подключаете устройство к системе, ядро обнаруживает и инициализирует его, и в каталоге /sys/ создаётся каталог с именем устройства, в котором хранятся атрибуты устройства.
Главный файл конфигурации для udev — это /etc/udev/udev.conf, а для управления поведением демона udev во время выполнения вы можете использовать утилиту udevadm.
Чтобы отобразить полученные события ядра (uevents) и события udev (которые udev отправляет после обработки правила), запустите udevadm с командой monitor. Затем подключите устройство к вашей системе и наблюдайте с терминала, как обрабатывается событие устройства.
На следующем снимке экрана показан фрагмент события ADD после подключения USB-накопителя к тестовой системе:
Чтобы узнать имя, присвоенное вашему USB-диску, используйте утилиту lsblk, которая считывает файловую систему sysfs и udev db для сбора информации об обрабатываемых устройствах.
Исходя из вывода предыдущей команды, USB-диск называется sdb4 (абсолютный путь должен быть /dev/sdb4). Чтобы запросить атрибуты устройства из базы данных udev, используйте команду info.
Как работать с правилами Udev в Linux
В этом разделе мы кратко обсудим, как писать правила udev. Правило состоит из списка из одной или нескольких пар ключ-значение, разделённых запятыми. Правила позволяют вам, среди прочего, переименовать узел устройства с именем по умолчанию, изменить разрешения и владение узлом устройства, инициировать выполнение программы или сценария при создании или удалении узла устройства.
Мы напишем простое правило для запуска скрипта при добавлении USB-устройства и его удалении из работающей системы.
Начнём с создания двух скриптов:
Добавьте следующие строки в скрипт device_added.sh.
Откройте второй скрипт.
Затем добавьте следующие строки в скрипт device_removed.sh.
Сохраните файлы, закройте и сделайте оба сценария исполняемыми.
Добавьте в него эти два следующих правила.
- «==»: оператор для сравнения на равенство.
- «+=»: оператор для добавления значения к ключу, содержащему список записей.
- SUBSYSTEM: соответствует подсистеме устройства события.
- ACTION: соответствует названию действия события.
- ENV : соответствует значению свойства устройства, в данном случае типу устройства.
- RUN: указывает программу или сценарий, выполняемый как часть обработки события.
Сохраните файл и закройте его. Затем от имени пользователя root скажите systemd-udevd перезагрузить файлы правил (это также перезагрузит другие базы данных, такие как индекс модуля ядра), для этого выполните:
Теперь подключите USB-накопитель к своей машине и проверьте, был ли выполнен скрипт device_added.sh. Прежде всего, файл scripts.log должен быть создан в /tmp.
Проверьте журнал сценариев после добавления USB
Затем в файле должна быть запись типа «USB device added at ВРЕМЯ».
Для получения дополнительной информации о том, как писать правила udev и управлять udev, обратитесь к записям руководства udev и udevadm соответственно, запустив:
Резюме
Udev — замечательный диспетчер устройств, который обеспечивает динамический способ настройки узлов устройств в каталоге /dev. Это гарантирует, что устройства будут настроены, как только они будут подключены и обнаружены. Он передаёт информацию об обрабатываемом устройстве или изменениях его состояния в пользовательское пространство.
Это замена devfs и hotplug.
Он динамически создает или удаляет узлы устройства (интерфейс к драйверу устройства, который отображается в файловой системе, как если бы это был обычный файл, хранящийся в каталоге /dev) во время загрузки, или если вы добавляете устройство или удаляете устройство из система.
Затем он распространяет информацию об устройстве или изменяет его состояние на пользовательское пространство.
Это функция: 1) предоставлять системные приложения событиям устройств, 2) управлять разрешениями узлов устройств и 3) создавать полезные символические ссылки в каталоге /dev для доступа к устройствам или даже переименовывать сетевые интерфейсы.
Одним из плюсов udev является то, что он может использовать постоянные имена устройств, чтобы гарантировать согласованное присвоение имен устройствам при перезагрузках, несмотря на их порядок обнаружения.
Эта функция полезна, потому что ядро просто назначает непредсказуемые имена устройств в зависимости от порядка обнаружения.
В этой статье мы узнаем, как использовать Udev для обнаружения и управления устройствами в системах Linux.
Обратите внимание, что большинство, если не все распространенные современные дистрибутивы Linux, поставляются с Udev как часть стандартной установки.
Изучаем основы Udev в Linux
Демон udev, systemd-udevd (или systemd-udevd.service) общается с ядром и сразу получает от него устройства uevents каждый раз, когда вы добавляете или удаляете устройство из системы, или устройство меняет свое состояние.
Каждое событие принятого устройства сопоставляется с набором правил, считанных из файлов, расположенных в /lib/udev/rules.d и /run/udev/rules.d.
Обратите внимание, что файлы правил в этом каталоге имеют наивысший приоритет.
Чтобы создать файл узла устройства, udev необходимо идентифицировать устройство с использованием определенных атрибутов, таких как метка, серийный номер, его основной и младший номер, номер устройства шины и многое другое. Эта информация экспортируется файловой системой sysfs.
Всякий раз, когда вы подключаете устройство к системе, ядро обнаруживает и инициализирует его, а каталог с именем устройства создается в каталоге / sys /, в котором хранятся атрибуты устройства.
Чтобы отобразить полученные события ядра (uevents) и udev события (которые udev отправляет после обработки правила), запустите udevadm с помощью команды monitor. Затем подключите устройство к вашей системе и наблюдайте с терминала, как обрабатывается событие устройства.
На следующем снимке экрана показан фрагмент события ADD после подключения флэш-диска USB к тестовой системе:
Чтобы найти имя, назначенное на ваш USB-диск, используйте утилиту lsblk, которая считывает файловую систему sysfs и udev db для сбора информации о обработанных устройствах.
На выводе предыдущей команды USB-диск называется sdb1 (абсолютный путь должен быть /dev/sdb1).
Чтобы запросить атрибуты устройства из базы данных udev, используйте команду info.
Как работать с правилами Udev в Linux
В этом разделе мы кратко обсудим, как писать правила udev.
Правило содержит список разделенных запятыми одной или нескольких пар ключ-значение.
Правила позволяют переименовывать узел устройства c имени по умолчанию, изменять разрешения и владение узлом устройства, запускать выполнение программы или скрипта, когда узел устройства создается или удаляется/
Мы напишем простое правило для запуска сrhbgnf при добавлении USB-устройства и его удалении из запущенной системы.
Начнем с создания двух скриптов:
Добавьте следующие строки в скрипт device_added.sh.
Откройте второй скрипт.
Затем добавьте следующие строки в script_removed.sh.
Сохраните файлы, закройте и сделайте оба скрипта исполняемыми.
Добавьте в него следующие два правила.
- «==»: является оператором сравнения для равенства.
- «+ =»: является оператором для добавления значения к ключу, содержащему список записей.
- SUBSYSTEM: соответствует подсистеме устройства события.
- ACTION: соответствует имени события.
- ENV : в этом случае сопоставляется значение свойства устройства, тип устройства.
- RUN: указывает программу или скрипт для выполнения как часть обработки событий.
Сохраните файл и закройте его.
Затем, от пользователя root, скажите systemd-udevd перезагрузить файлы правил (это также перезагружает другие базы данных, такие как индекс модуля ядра), запустив.
Теперь подключите USB-накопитель к компьютеру и проверьте, был ли запущен скрипт device_added.sh.
Прежде всего файл scripts.log должен быть создан в /tmp.
Затем файл должен иметь запись, такую как «USB device removed at date_time”»
Для получения дополнительной информации о том, как писать правила udev и управлять udev, обратитесь к руководству udev и udevadm соответственно, выполнив:
Читайте также: