Динамические переменные в файлах блоков обслуживания systemd
Согласно файлу readme ядра modutils , поддержка amd64 была добавлена в 2.4.26, а некоторые комментарии о проблемах указывают на добавленную поддержку ядра до версии 2.4.22.
OP заметил, что самое раннее примечание для amd64 было для 2.4.15, также в modutils readme:
modutils-2.4.15.tar.gz Expand small snprintf buffers to PATH_MAX. Add
alias ppp-compress-18 ppp_mppe. Add x86-64
support. Clean up and document modinfo printing
of parameters. Update config.{guess,sub} to
2002-03-04.
В журнале изменений для 2.4.15 есть отметка времени файла от 23 ноября 2001 г. (см. архив ) . Предположительно комментарий о config. {Guess, sub} был добавлен "позже" , как часть подготовки tar-шара.
Если вы поищете дополнительную информацию о поддержке 64-разрядных систем в Linux, вы обнаружите, что были и другие изменения (например, для ia64, sparc64), которые были внесены ранее в разработку 2.4.x, и что дата, когда данная платформа была «полной» несколько туманна. Примечания к выпуску Red Hat Enterprise Linux AS 3 (AMD64 Edition) в 2003 году относятся к некоторым из этих незавершенных / незавершенных изменений.
Если вы будете осторожны, вы можете включить небольшую последовательность сценария bash в качестве своей команды exec в файл службы экземпляра. Например,
ExecStart=/bin/bash -c 'v=%i; USE_GPU=$${v%:*} exec /bin/mycommand'
$$ в строке станет единственным $ в результате, переданном в bash, но, что более важно, остановит $ {...} от интерполяции systemd. (Более ранние версии systemd не документировали использование $$ , поэтому я не знаю, поддерживалось ли оно тогда).
Нет встроенного способа. Вам нужно сделать это до запуска службы. Один из способов - поместить его в файл окружения.
[Service]
# Note you need to escape percentage sign
ExecStartPre=/bin/sh -c "my_awesome_parser %%i > /run/gpu_service_%i"
EnvironmentFile=/run/gpu_service_%i
ExecStart=...
Похоже, вы действительно можете установить переменные среды внутри файла модуля systemd ...
Согласно предложениям комментаторов, вот решение:
Использование переменных среды в модулях systemd
Директива среды
systemd имеет директиву Environment, которая устанавливает переменные среды для выполняемых процессов. Требуется список назначений переменных, разделенных пробелами. Эта опция может быть указана более одного раза, и в этом случае будут установлены все перечисленные переменные. Если одна и та же переменная установлена дважды, более поздняя настройка переопределит более раннюю настройку. Если этому параметру присвоена пустая строка, список переменных среды сбрасывается, все предыдущие назначения не действуют. Директивы окружения используются во встроенных модулях systemd в Linux, например, в etcd2 и flannel.
В примере ниже вы можете настроить демон etcd2 для использования шифрования. Просто создайте
/etc/systemd/system/etcd2.service.d/30-certificates.confdrop-in для etcd2.service:[Служба] # клиентских переменных окружения Environment = ETCD_CA_FILE = / path / to / CA.pem Environment = ETCD_CERT_FILE = / path / to / server.crt { {1}} Environment = ETCD_KEY_FILE = / path / to / server.key # Peer Env Vars Environment = ETCD_PEER_CA_FILE = / path / to / CA.pem Environment = ETCD_PEER_CERT_FILE = / path / to / peers.crt Environment = ETCD_PEER_KEY_FILE = / path / to / peers.keyЗатем запустите
sudo systemctl daemon-reloadиsudo systemctl restart etcd2.serviceдля применения нового окружения к демону etcd2.
Цитата из следующего URL: https: // coreos.com / os / docs / latest / using-environment-variables-in-systemd-units.html
Некрасиво и не совсем то, что вы просили, и не позволяет автозапуск, но для последователей можно что-то сделать с помощью окружения systemctl :
$ sudo systemctl set-environment USE_GPU=4 # add it to the env. variables for future services
$ sudo systemctl start gpu_service@4:2.service
Просто пытаюсь перечислить все возможные варианты, некоторые другие ответы тоже работают:)