Dotaz: systemd service: ignoruje parametry příkazu?

[JanM]

Zdravím,

nedaří se mi vyřešit situaci, kdy proces démona spuštěný z CLI funguje ok, zatímco při spuštění skrze systemd s týmiž parametry jsou tyto parametry ignorovány a démon běží s výchozími nastaveními.

Nejprve z CLI:

$ sudo /usr/bin/ebusd --configpath /etcWRONG/ebusd --logfile /var/log/ebusd-remote/ebusd.log --dumpfile /var/log/ebusd-remote/ebusd.dump --dumpsize 100000 --dump

$ ps aux | grep /usr/bin/ebusd
root      5832  0.0  0.2  38392  1080 ?        Ssl  11:23   0:00 /usr/bin/ebusd --configpath /etcWRONG/ebusd --logfile /var/log/ebusd-remote/ebusd.log --dumpfile /var/log/ebusd-remote/ebusd.dump --dumpsize 100000 --dump

$ cat /var/log/ebusd-remote/ebusd.log
2015-01-24 11:23:09.646 [bas event] ebusd started
2015-01-24 11:23:09.647 [bas trace] path to ebus configuration files: /etcWRONG/ebusd
2015-01-24 11:23:09.648 [bas error] error reading templates: ERR: file/element not found or not readable
2015-01-24 11:23:09.648 [bas error] error reading config files: ERR: file/element not found or not readable

A nyní systemd:

$ cat ebusd.service
[Unit]
Description=Communication interface to the energy bus (ebus)
After=local-fs.target
ConditionPathExists=/var/log

[Service]
Type=forking
EnvironmentFile=-/etc/conf.d/ebusd
ExecStart=/usr/bin/ebusd ${EBUSD_ARGS}
PIDFile=/run/ebusd.pid

[Install]
WantedBy=multi-user.target

Mohu-li soudit, tak parametry procesu jsou shodné:

$ ps aux | grep /usr/bin/ebusd
root      5774  0.0  0.2  46584  1260 ?        Ssl  10:47   0:00 /usr/bin/ebusd --configpath /etcWRONG/ebusd --logfile /var/log/ebusd-remote/ebusd.log --dumpfile /var/log/ebusd-remote/ebusd.dump --dumpsize 100000 --dump

Jenže jsou ignorovány; log leží jinde, výchozí konfiguraci to čte z /etc/ebusd místo /etcWRONG/ebusd:

$ cat /var/log/ebusd.log
2015-01-24 10:47:39.898 [bas event] ebusd started
2015-01-24 10:47:39.899 [bas trace] path to ebus configuration files: /etc/ebusd
2015-01-24 10:47:39.935 [bas trace] read templates
2015-01-24 10:47:39.938 [bas trace] read config files
2015-01-24 10:47:39.939 [bas event] message DB: 4
2015-01-24 10:47:39.940 [bas event] updates DB: 0
2015-01-24 10:47:39.940 [bas event] polling DB: 0

Co je to za podivnost? Vyžaduje systemd od démona nějaké specifické vlastnosti? (/usr/bin/ebusd sám forkuje a běží na pozadí, což by mělo být klasické chování a odpovídá tomu "Type=forking".) Arch Linux, ARM.

---

---

Odpovědi

[rastos]

Posledný parameter commandline-u sa líši. Alebo si to zle pastol.

To tam vážne máš "/etcWRONG/ebusd" ?

Skúsil by som porovnať veci pod /proc (cmdline, environment, mounts, ...) v jednom a druhom prípade.

Je sranda googliť slovné spojenie "systemd wrong" Mno ... vyzerá to tak, že sa zábava so systemd rozbieha.

[vasek]

No je to pěkně blbá sranda. Nevzpomínám si, že bych v před-systemd době musel některé špatně nabíhající či nenabíhající služby restartovat v /etc/rc.local nebo startovat manuálně a v systemd je zakázat. Doufat v brzké vyřešení bug reportů fakt nehodlám ... Na druhou stranu takhle mohu identifikovat systémy se systemd nebo upstartem jen na základě nadávek v rc.local ... No co buďme rádi za to, že nám server nabíhá 8 sekund a ne těch hrozných 10 sekund.

[JanM]

Poslední parametr je "--dump", ale na tom až zase tak nesejde. Ona je totiž v systemd ignorována celá ta řádka s parametry, můžu tam psát, co chci.

Vážně tam mám /etcWRONG/ebusd, abych viděl, že to při akceptaci "path to ebus configuration files: /etcWRONG/ebusd" následně vyhodní chybovou hlášku "error reading templates: ERR: file/element not found or not readable", protože ten adresář neexistuje.

[JanM]

/proc/PID/... jsem porovnával, nic zvláštního, ale to může být mojí neznalostí.

[JanM]

Při "systemctl start ebusd" to v systémovém logu hodí hlášku "Failed to reset devices.list on /system.slice: Invalid argument", chvíli jsem hledal, zda by to mohlo souviset, zatím žádný výsledek.

[petr_p]

A jste si jistý, že systemd opravdu používá vás změněný /etc/systemd/system/ebusd.service?

[JanM]

Celkem ano, k problému jsem se dostal při snaze vytvořit PKGBUILD pro Arch. V contribu zdrojáků jsou jen init skripty pro Debian, systemd na ARMech asi ještě moc rozšířen není

Modifikací proměnných v /etc/conf.d/ebusd dosáhnu změny parametrů procesu (/proc/PID/cmdline). Jinou binárku v PATH na systému nemám. Mohu ty parametry natvrdo napsat do /usr/lib/systemd/system/ebusd.service (třeba i s jinou modifikací, abych si byl jist), ale stejně jsou při běhu ignorovány.

Vyzkouším totéž na x86, abych zúžil množinu sprostých podezřelých.

[JanM]

Cvičně jsem to vyzkoušel na Lubuntu 12.04 arm, init skript spouští démona, jak má, vč. parametrů a démon také dělá co má.

Pak ještě totéž na Archu x86_64, tam to blbne stejně jako na ARMu. Napsal jsem autorovi a optal se na archlinuxARM, tak uvidíme.

[JanM]

Mas u prirazeni EBUSD_ARGS uvozovky? Dej je pryc. I like that logic.

[JanM]

vyhodil jsem je, ale výsledek je stejný,

$ cat /etc/conf.d/ebusd
# /etc/conf.d/ebusd: config file for ebusd.service
# Options to pass to the ebusd.
# See the ebusd -h for more info.

EBUSD_ARGS=--configpath /etcNONEXISTENT/ebusd --logfile /tmp/ebusd.log

tak jsem je tam pro další testování zase vrátil

Navedlo mne to ovšem správným směrem. V ebusd.service jsem změnil ExecStart=/usr/bin/ebusd ${EBUSD_ARGS} na ExecStart=/usr/bin/ebusd $EBUSD_ARGS et voilà, funguje to!

Manuál systemd říká, že je to feature a ne bug:

Basic environment variable substitution is supported. Use "${FOO}" as part of a word, or as a word of its own, on the command line, in which case it will be replaced by the value of the environment variable including all whitespace it contains, resulting in a single argument. Use "$FOO" as a separate word on the command line, in which case it will be replaced by the value of the environment variable split at whitespace resulting in zero or more arguments. For this type of expansion, quotes and respected when splitting into words, and afterwards removed.

V každém případě velmi děkuji za nakopnutí, škoda, že jsem na tom strávil tolik času.