[arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, So now that I've got a network through systemd, I ran into trouble with some daemon service files that I crafted by hand. None of the following directives will work (culled from different files): ExecStartPre=cd /etc/solr ExecStart=$JAVA_HOME/bin/java -jar $JAVA_OPTS start.jar $JETTY_OPTS >> /var/log/jetty.log 2>&1 ExecStop=kill `pidof -o %PPID /usr/sbin/dictd` 2>/dev/null 1>/dev/null Basically lots of things that would be normal in a shell are problematic. So I need to create separate scripts to start and stop some daemons. I'm thinking I definitely do not want to use /etc/rc.d for this (I had to back out and go back to init and /etc/rc.d is still in use for that). Is there some consensus on where such scripts should go? - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEv+RAAoJELT202JKF+xp9rAP/1+hg9rapqIp8xI01vJ6Uvyd twIXA5bD3LvGS36FkCTmapdpcNKxGzCgxIoXcST0Qe1uJsrFboTl7LGJ14dmBBqg 05tqpvg6Vv4/tv+ac4S6dIO9uY0SmyzZoQMue5B0cvGvEAb7vcdh+dCjru0/YGis 8Nzsyyv3c/hJE43GIL4buz46cqKhcJqQyJAs8xXBbM50uchr2vpOQ6F2COMs196C 4NeLnPut4Gc5xZJd0cJmS/cqAYd7CYH0UX6gGYfxo9GT+CVoLJmnSeooNiRZZBAN uO/Fq7azsN8jRBWynmS0Ckqt5Dx1ErPyW/J2uj3UinMbg2XeOK2cLbmYAsmWyLIu 9fnWfsllHXEs+phbk4qUerojHDH4p/IQAyNV2FsiLVQmAV0FXKZB39NaM+7ws7z4 X9xbRcWKM8kTAflmPdiaGGmDJ7v8E0yhaB/0IbTbAhM2HDQxUVvgpHZFSyiQbR8T pED90wLp2iv10Jl16K/GRdn6GjMLS4QVftAWdPUyfR9NlLV/wPGVsB4jVmTmLzM5 jw0JJvKyrybZvJP0l/G/mUX+0KxHHcSQaldhTL2q5jlD+ZbHOda1inwgH5Dq+eJ2 ruJDNXYIy0Jy7fa1J3Wh+9FRk9LEo9VEdoQhPzjjhYXZ4qnkwRd5etmUun99v6/2 FX8jWC4EAX6Gb0gq9Fxh =zGji -----END PGP SIGNATURE-----
On Fri, Jul 27, 2012 at 10:52 PM, David Benfell <benfell@parts-unknown.org> wrote:
So now that I've got a network through systemd, I ran into trouble with some daemon service files that I crafted by hand.
None of the following directives will work (culled from different files):
ExecStartPre=cd /etc/solr ExecStart=$JAVA_HOME/bin/java -jar $JAVA_OPTS start.jar $JETTY_OPTS >> /var/log/jetty.log 2>&1 ExecStop=kill `pidof -o %PPID /usr/sbin/dictd` 2>/dev/null 1>/dev/null
Basically lots of things that would be normal in a shell are problematic.
Yup, Exec* does not accept shell syntax, but does accept some variable substitution (see systemd.service(5) for details).
So I need to create separate scripts to start and stop some daemons. I'm thinking I definitely do not want to use /etc/rc.d for this (I had to back out and go back to init and /etc/rc.d is still in use for that).
Is there some consensus on where such scripts should go?
Not really, as far as I know. However, it seems that it is common to put "helper scripts" that are shipped with systemd in /usr/lib/systemd/ and those shipped with udev in /usr/lib/udev/, so for user-created helper scripts, I think I'd put them in /etc/systemd/. -t
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/27/2012 02:01 PM, Tom Gundersen wrote:
Not really, as far as I know. However, it seems that it is common to put "helper scripts" that are shipped with systemd in /usr/lib/systemd/ and those shipped with udev in /usr/lib/udev/, so for user-created helper scripts, I think I'd put them in /etc/systemd/.
That works for me. With some intervening logic to monitor the jobs--since systemd won't be able to monitor them itself--I think I can pull this off. Thanks! - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEwJmAAoJELT202JKF+xp2EoP/RG8BI3mqw+BP3XdZtWusrct z/OTNGkwoZw9FuKLBGY9e5T1jbuZfAh/9nEwkgXSEqgglLTffo4KewNbPgqlv+X4 ziBSSFeYxL0dlgu2eNa2KNI+2mDg3UcF8bIUFxPf2y8IfdmGeNta1jjC7cIESoLz EWrZx8Ukf7hRrgcxn6PY//ET19FOxvx1Rs43Cwd7MhGES/bZBkKLYhg18eJaCBLN 4U/m1R1xRBbzkfqaW3gGsi1lHPnlHy9jeG8j82IbCImoW12mHR6XSgV6qAnJOMyu xcxHU+pagCy7U8SPs/KM3CGXebQ3UJeDS1383vPubljzxdjiTu3gj1EpBk9jh1G9 FAO0GDMtBq422RaF9wHLwLhX19leDusAEX/mU1m4d35MpOOd7mHkWK7Q6A7zmZbE prhjXUDilRX2uW3jTQDONLVaEn4Q4x9Dw0bpSbYTIQdDJ8Nnc2kJQL0ULuUAnvXX NRAg+sE+DEAQRDKI28VKXM0DmWlNSewJ9tbASqCh+SD43KCs0RhHmlQfKM/WGPkh YEp0oB4C1Ek2DqiZFJXcZLdJpaTiQIGrRsBLrIDFYVQH3V0zXVO24ZpK+GeT4h1Y MTaS3vng0CnzvAevDqbaPwRNVi5dk3sObLTyoQMq3gSKi5pIxLbnP6ORqVhbzKXI vz4XEPIvJXjMsfMdOnug =JJNz -----END PGP SIGNATURE-----
On Fri, Jul 27, 2012 at 4:04 PM, David Benfell <benfell@parts-unknown.org> wrote:
On 07/27/2012 02:01 PM, Tom Gundersen wrote:
Not really, as far as I know. However, it seems that it is common to put "helper scripts" that are shipped with systemd in /usr/lib/systemd/ and those shipped with udev in /usr/lib/udev/, so for user-created helper scripts, I think I'd put them in /etc/systemd/.
That works for me. With some intervening logic to monitor the jobs--since systemd won't be able to monitor them itself--I think I can pull this off.
also note that you likely want to simply run the service differently that you had previously. for example, i modify several .service files -- even ones that are shipped upstream -- because they are pointlessly configured as `forking` when they could be much better integrated (ddclient, dhcpd, hostapd, SEVERAL unfortunately) ... eg, in general, PID files are not needed anymore, and logs should go to STDOUT. so ... set the daemon to FOREGROUND, and DON'T redirect output (see man systemd.exec for stdout/err options, among others). ... then you can just: ExecStop=-/bin/kill $MAINPID .. and be done with it :-) part of succeeding with systemd is recognizing that 3/4 of the @#$% -required- before is not only -unnecessary-, but now a hindrance! other notes from your pasted unit file: - Exec* requires absolute paths to binaries - $JAVA_OPTS is different from ${JAVA_OPTS}; the former is subjected to word-splitting while the latter is not (see man bash) -- C Anthony
On Sat, Jul 28, 2012 at 12:39 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
also note that you likely want to simply run the service differently that you had previously.
for example, i modify several .service files -- even ones that are shipped upstream -- because they are pointlessly configured as `forking` when they could be much better integrated (ddclient, dhcpd, hostapd, SEVERAL unfortunately) ...
They are often configured as Type=forking because they only fork after performing some form of initialization (e.g. dhcpcd [the client] might fork only after actually receiving a DHCP lease), and systemd will interpret this as a signal that the service has now started, without having to add systemd-specific sd_notify(). -- Mantas Mikulėnas
On Fri, Jul 27, 2012 at 11:39 PM, C Anthony Risinger <anthony@xtfx.me> wrote:
for example, i modify several .service files -- even ones that are shipped upstream -- because they are pointlessly configured as `forking` when they could be much better integrated (ddclient, dhcpd, hostapd, SEVERAL unfortunately) ...
eg, in general, PID files are not needed anymore, and logs should go to STDOUT. so ... set the daemon to FOREGROUND, and DON'T redirect output (see man systemd.exec for stdout/err options, among others).
Please file bugs if you think there are errors. Sometimes "Type=forking" is the right thing to do. If the daemon is not socket/dbus actiavted, then Type=forking is the only way to know if a service has finished starting.
ExecStop=-/bin/kill $MAINPID
Hm, this should be uneccesary, no? If no ExecStop is configured the process will get a SIGTERM when the service is stopped. -t
On Fri, Jul 27, 2012 at 4:53 PM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Jul 27, 2012 at 11:39 PM, C Anthony Risinger <anthony@xtfx.me> wrote:
for example, i modify several .service files -- even ones that are shipped upstream -- because they are pointlessly configured as `forking` when they could be much better integrated (ddclient, dhcpd, hostapd, SEVERAL unfortunately) ...
eg, in general, PID files are not needed anymore, and logs should go to STDOUT. so ... set the daemon to FOREGROUND, and DON'T redirect output (see man systemd.exec for stdout/err options, among others).
Please file bugs if you think there are errors. Sometimes "Type=forking" is the right thing to do. If the daemon is not socket/dbus actiavted, then Type=forking is the only way to know if a service has finished starting.
ah, you/Mantas are probably correct here -- i didn't think about such cases -- i don't seem to be using anything in such a way to be negatively affected. for most of my custom stuff i've tried to use out-of-band triggers like sysfs files appearing/etc ... will explore this more, thanks.
ExecStop=-/bin/kill $MAINPID
Hm, this should be uneccesary, no? If no ExecStop is configured the process will get a SIGTERM when the service is stopped.
ah yes, right right ... i mainly wanted to demonstrate the simplicity of "not thinking in terms of rc.d scripts" ... which is now even simpler thanks to your "you don't need anything at all" :-) hard to get much more concise than "nothing". -- C Anthony
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/27/2012 02:53 PM, Tom Gundersen wrote:
Please file bugs if you think there are errors. Sometimes "Type=forking" is the right thing to do. If the daemon is not socket/dbus actiavted, then Type=forking is the only way to know if a service has finished starting.
I am indeed finding in many cases I have to use 'forking'. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEzBnAAoJELT202JKF+xpJiQQAJwNawMLQsz1kBBv1aIvH/bM jx5jI9WWhVSv1x573c8hY04Yw3AUEBdHahvljOlzpQgVbtT9iHAdRvl2tl0S6PgV 2C9aKsdIyJQOLqHXCSI11FxSWv+qcbxuoj1TOzHvqLe2bBpWOCGz+FeXsjRvfbCq B4wLzcLYbsTSg/sQdkVW0AK9rupT1ahvDQNAFDMBTRvw6SEZtxqgLgcCndjLVKv0 u9v8rX5LEwklaowiWEDO/mTmij6XW4U3IM1WUG2DZnCBMHxqJegxGCQLyRq1pqn/ A5chjn2ppRhAQkzgX8WfCNCoGzgZ2rt1TNRhwYeeeosjkn5eIqzZu4qeTQlyOaiO j8175VdZ9uJ/0OkH6ZGUqKmuL6pyUGBcByjGxjdM8ctU0ol78BULVueZA2RVYR2+ xGQwr4JVlfuG1Euw4+yp9egUuB0FNRWp+vrcPcpFjbjQ9W8VhyUD7OslniUnaaNt Qe/0eBgq/gHlu8FDY/kf+h9031cFCzO+7hFs0wBmg5ziwTaSi5A/LN0o+AbBlOtq T5u+WXyTAej4ZmUGTfdWPQdW+VK77GI2vJMqzeEy9pizXmVx3LUFFPTDnknyaYC/ SsJ4dd6Q1G8Ko6mkQB0DYdpBpfBDwiscGK61xnZCvBTC1uHZ38fvNV8g694PVcMF Jftob66pCfB81/sfU8gi =plbc -----END PGP SIGNATURE-----
So now that I've got a network through systemd, I ran into trouble with some daemon service files that I crafted by hand.
None of the following directives will work (culled from different files):
ExecStartPre=cd /etc/solr
Use: WorkingDirectory=
ExecStart=$JAVA_HOME/bin/java -jar $JAVA_OPTS start.jar $JETTY_OPTS >> /var/log/jetty.log 2>&1
You shouldn't redirect stdout/stderr, let systemd handle it see StandardInput=, StandardOutput=, StandardError= in man systemd.exec
ExecStop=kill `pidof -o %PPID /usr/sbin/dictd` 2>/dev/null 1>/dev/null
I don't know what's that "kill dictd" but if it's a subprocess started from your java program, systemd can handle it too. It puts every service in its own CGroup so it know all the processes started from that service. See man systemd.kill KillMode= -- дамјан
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, On 07/27/2012 02:24 PM, Damjan wrote:
So now that I've got a network through systemd, I ran into trouble with some daemon service files that I crafted by hand.
None of the following directives will work (culled from different files):
ExecStartPre=cd /etc/solr
Use: WorkingDirectory=
ExecStart=$JAVA_HOME/bin/java -jar $JAVA_OPTS start.jar $JETTY_OPTS >> /var/log/jetty.log 2>&1
You shouldn't redirect stdout/stderr, let systemd handle it
see StandardInput=, StandardOutput=, StandardError= in man systemd.exec
ExecStop=kill `pidof -o %PPID /usr/sbin/dictd` 2>/dev/null 1>/dev/null
I don't know what's that "kill dictd" but if it's a subprocess started from your java program, systemd can handle it too. It puts every service in its own CGroup so it know all the processes started from that service. See man systemd.kill KillMode=
Thanks for all the help here. 'cause I'm clueless. Here's what I've got for dictd (which seems like a relatively simple case): [Unit] Description=Dict Server After=network.target [Service] Type=simple EnvironmentFile=/etc/conf.d/dictd ExecStart=/usr/sbin/dictd ${DICTD_ARGS} -- ${DICTD_EARGS} Restart=always [Install] WantedBy=multi-user.target Is this making sense? Thanks! - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQExIdAAoJELT202JKF+xpbPIP/R1KB2d62nnil+BF1rLrz5oB Fu9AtOodoS9IQnj1duM+PNDbSa55ePuL/HsoNEgRQ2PxrR906DhrHciIP3VeT01M Ll2MX44nvsCpn+s4zDjJMxIy5F5yp0UWSrG1zPNmYLoTH4Zd50JyNCYq0xrj+9kM K1qPI/RRHNYJXZJ31dih3D0AV3l8iGzjzfIn+toYQsy+KDjRkg8+73ZPoIpmYACt DdraX+25QxAV6H91eFj27sk101Q6NG4GER3VeZbxTAIYTnOsfEEZjlFDslSXaLV3 OCVZGHkbuKxxMDFphm84S52oVRkFy8XJagJ76+DeMbwH7a44f/Q31dV8hXqrJiIT EBFJEes1GtkiatmMM9UREaVsE45cFAcVdGA+NWsy6/j0P8E8y9tfGSCytIChEZcr yn0sSFITuAi8kSgePD0KpTKV6lZlGoqkWfIeoeXtY0oXVJDx3O1s9CS3N5I5mp1i YI33cXbcpWpvKRsSvOPdeT5gDyQubAkLwWq+dFZ2C3WRDh6eIkeEyQEnpjJUlYSb GmFHJR1je3Z96kOdcr8EUwci+T6F4oTu2iXFWrcWggPHi8xIjsm+2dvRI/9VJ8iT U6w1RU4wbk8wB0e+EzehcziXpufeYrpQF5LF6TMOAEeN8A4yVjUcTf7/URRAU1IK tBliDW0dTGJl8U920mZ3 =yv1o -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/27/2012 02:24 PM, Damjan wrote:
I don't know what's that "kill dictd" but if it's a subprocess started from your java program, systemd can handle it too. It puts every service in its own CGroup so it know all the processes started from that service. See man systemd.kill KillMode=
It turns out I do need KillSignal= for my memcached jobs. But when I include it in the service file it complains: Unknown lvalue 'Kill-Signal' in section 'Service'. Ignoring. I'm not understanding, then, where you put this. Thanks! - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEzAjAAoJELT202JKF+xpte0QAJWCiklk7gUi6uHXczxV5xnn B4ydHLUN8VMolWHh9keneHXKEPct5NtiILkT9vC6yGrldqGHtPhhwfIVwcXXeVGT OBB4zbujn/OAivjBtOd8gyQ4MxTmwbxterPc7VCku1IOcFLU8aSgNsFX8+EpM+hD pTVOv7gYCSZKqZbhq8sPC4cd+V/a/zoUM8ZIqLnbjFHd4ctMfFkEuz8aLh8cfEDO znnQUcL9ZiVsfBrBZJeauTpxPNKvvMdcC9SEXV8jggkZyr4Dm88kB9F/x/EeGij9 mzs/qxf1pSxiq1FZvn2VF5SKtyGMwr67qcJyooUugy/wDBZEuWRRsnkDcEVS5jP+ /0bcyQt65fijUQwih7FULQaZrQcutDzy6CwfbbDh/v3BXxxNiJ8RYiFGc0eXVqOd vK2bezZ1M155dWBvcfZkwmTN2jeo1vLQqOCpKa7Lem/FfrTUAff/W7l8zaH0QZHP 2NemIIjM+jwJWc1ZYaMMw6N2vHJsSupaJl4ZWHxME8G2HCj+0myhEJ287/1MnRWh 43bpoId8RC9rqE6OihJ8sU0boa+W+JzNleBI6UfJPIo9gQLa7n0wTYB2FenM7M8L Gtm8GHGCnmAEw1ohZL1Af5qidcJO6lKHDsAAzfhKFc4imora/oarPCpj8FUW13Pr MdQ9TBpofqHT1Qqv4ZbI =+oRJ -----END PGP SIGNATURE-----
On Sat, Jul 28, 2012 at 3:19 AM, David Benfell <benfell@parts-unknown.org> wrote:
It turns out I do need KillSignal= for my memcached jobs. But when I include it in the service file it complains:
Unknown lvalue 'Kill-Signal' in section 'Service'. Ignoring.
Probably because it's "KillSignal", not "Kill-Signal". -- Mantas Mikulėnas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/28/2012 02:28 AM, Mantas Mikulėnas wrote:
Probably because it's "KillSignal", not "Kill-Signal".
Thanks! I'm about to head out the door, but I've corrected the service files accordingly. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQFD8uAAoJELT202JKF+xpzG0QAIRUlbkjJ+A6tehJIVKACgWr T5s2ip9swRrvWOOEhp5+qbFuaz7XA5v6kXFkSlRsWJkr3wxBLDU3bQCpaFgsfREE EDKB8KuQsxv/YYNt/7cvt+RBmmz0ikyNGFf0mR3B9RTIM5xu8oUIZyHhmCVgh7MN cH2yEYzowkoi3M7o/WBcjkseSWVIiVe03OZI0IcnLh6r/WP59MCwDQ4c2j5bLy1F 2WmizqvpkHnbD/y3/3GEfz1ViTajsfKafkgWROtJVIepDHbXWAnFx5xCCdUpQviQ OUg5kRpfpgHoNPFqUoZkH3HE77XrgNaElf5gvimnC1wZdoSaTFFaE5fZzy+jyx/g 9BBDV2TL1rK9Lnb6b96Vv4EFuJbt0IBBAQr4nGENDcT+Y0fr1yjA1Z8rKnRhyDix pv3eEySRyw3ZXMROHc7RnNXIwLbRzKCsWTNrpT8SxSXM/xsgOIoz1CxzM7ctCu/G GTrt7cdpMrXBco5Nv2B69YfuS8Mg0mbiDL1SoUxc9GlfJ50cRn+Q4z+jvaFGNDUC lETDOKWB+ftg+eVR3MpNSBIqaCc63JGUSzIqqy/CIAObILCBj6IMle9/BtNlxqyL Oa961JZ8xfaXE/YBsR8VU/dAXZZ1B8Hk/jdPLbi52/AKkcUMcgQcbuXrCmuz4ryz J9/QriNtI0PEUOc6cqGm =yXdr -----END PGP SIGNATURE-----
participants (5)
-
C Anthony Risinger
-
Damjan
-
David Benfell
-
Mantas Mikulėnas
-
Tom Gundersen