While creating systemd units for my packages, I found two problems:
1) I cannot force pppd fork to the background. While it is the default behaviour, the user can override that with the 'nodetach' and 'updetach' configuration options.
Should I use Type=simple and force the 'nodetach' option on pppd?
2) systemd has built-in watchdog functionality. Should I omit systemd units for watchdog? With systemd, I don't need it anymore.
On Thu, Aug 30, 2012 at 2:06 AM, Thomas Bächler thomas@archlinux.org wrote:
While creating systemd units for my packages, I found two problems:
- I cannot force pppd fork to the background. While it is the default
behaviour, the user can override that with the 'nodetach' and 'updetach' configuration options.
Here's my instanced ppp@.service, if you're interested:
[Unit] Description=PPP link to %I After=network.target
[Service] Type=forking PIDFile=/run/ppp-%i.pid ExecStart=/usr/sbin/pppd call %I linkname %i nodetach
[Install] WantedBy=multi-user.target
I believe the "nodetach" on the command line will override what happens in the config file. The "linkname" option controls the pidfile name.
Am 30.08.2012 02:50, schrieb Jan Steffens:
On Thu, Aug 30, 2012 at 2:06 AM, Thomas Bächler thomas@archlinux.org wrote:
While creating systemd units for my packages, I found two problems:
- I cannot force pppd fork to the background. While it is the default
behaviour, the user can override that with the 'nodetach' and 'updetach' configuration options.
Here's my instanced ppp@.service, if you're interested:
[Unit] Description=PPP link to %I After=network.target
[Service] Type=forking PIDFile=/run/ppp-%i.pid ExecStart=/usr/sbin/pppd call %I linkname %i nodetach
[Install] WantedBy=multi-user.target
I believe the "nodetach" on the command line will override what happens in the config file. The "linkname" option controls the pidfile name.
You use Type=forking with a process that doesn't fork - that's what 'nodetach' means: do NOT fork into the background. That doesn't seem right.
On Thu, Aug 30, 2012 at 9:24 AM, Thomas Bächler thomas@archlinux.org wrote:
Am 30.08.2012 02:50, schrieb Jan Steffens:
On Thu, Aug 30, 2012 at 2:06 AM, Thomas Bächler thomas@archlinux.org wrote:
While creating systemd units for my packages, I found two problems:
- I cannot force pppd fork to the background. While it is the default
behaviour, the user can override that with the 'nodetach' and 'updetach' configuration options.
Here's my instanced ppp@.service, if you're interested:
[Unit] Description=PPP link to %I After=network.target
[Service] Type=forking PIDFile=/run/ppp-%i.pid ExecStart=/usr/sbin/pppd call %I linkname %i nodetach
[Install] WantedBy=multi-user.target
I believe the "nodetach" on the command line will override what happens in the config file. The "linkname" option controls the pidfile name.
You use Type=forking with a process that doesn't fork - that's what 'nodetach' means: do NOT fork into the background. That doesn't seem right.
Yeah, whoops - it should have been I made that modification in the email. The original doesn't use either.
On Thu, Aug 30, 2012 at 9:24 AM, Thomas Bächler thomas@archlinux.org wrote:
Am 30.08.2012 02:50, schrieb Jan Steffens:
On Thu, Aug 30, 2012 at 2:06 AM, Thomas Bächler thomas@archlinux.org wrote:
While creating systemd units for my packages, I found two problems:
- I cannot force pppd fork to the background. While it is the default
behaviour, the user can override that with the 'nodetach' and 'updetach' configuration options.
Here's my instanced ppp@.service, if you're interested:
[Unit] Description=PPP link to %I After=network.target
[Service] Type=forking PIDFile=/run/ppp-%i.pid ExecStart=/usr/sbin/pppd call %I linkname %i nodetach
a>> [Install]
WantedBy=multi-user.target
I believe the "nodetach" on the command line will override what happens in the config file. The "linkname" option controls the pidfile name.
You use Type=forking with a process that doesn't fork - that's what 'nodetach' means: do NOT fork into the background. That doesn't seem right.
Yeah, whoops - it should have been "updetach". I added it in the email. The original doesn't use either and just expects the default detaching behavior.
Am 30.08.2012 12:32, schrieb Jan Steffens:
You use Type=forking with a process that doesn't fork - that's what 'nodetach' means: do NOT fork into the background. That doesn't seem right.
Yeah, whoops - it should have been "updetach". I added it in the email. The original doesn't use either and just expects the default detaching behavior.
Yes, that's my problem:
* updetach may wait a very long time before detaching. * You cannot force 'detach' on the commandline.
On Thu, Aug 30, 2012 at 1:27 PM, Thomas Bächler thomas@archlinux.org wrote:
Am 30.08.2012 12:32, schrieb Jan Steffens:
You use Type=forking with a process that doesn't fork - that's what 'nodetach' means: do NOT fork into the background. That doesn't seem right.
Yeah, whoops - it should have been "updetach". I added it in the email. The original doesn't use either and just expects the default detaching behavior.
Yes, that's my problem:
- updetach may wait a very long time before detaching.
- You cannot force 'detach' on the commandline.
As I see it you either want to wait for it to establish the connection, or you don't.
If the former, updetach and Type=forking is the right choice:
[Unit] Description=PPP link to %I After=network.target
[Service] Type=forking PIDFile=/run/ppp-%i.pid ExecStart=/usr/sbin/pppd call %I linkname %i updetach
[Install] WantedBy=multi-user.target
---
If the latter, nodetach:
[Unit] Description=PPP link to %I After=network.target
[Service] ExecStart=/usr/sbin/pppd call %I nodetach
[Install] WantedBy=multi-user.target
---
I'd say go for the former. Would allow other units to depend on the connection being up. You could also ship both units under differing names, such as ppp-wait@.service and ppp-nowait@.service. In that case, Conflicts on each other would probably be a good idea (Conflicts=ppp-nowait@%i.service).
Am 30.08.2012 13:44, schrieb Jan Steffens:
On Thu, Aug 30, 2012 at 1:27 PM, Thomas Bächler thomas@archlinux.org wrote:
Am 30.08.2012 12:32, schrieb Jan Steffens:
You use Type=forking with a process that doesn't fork - that's what 'nodetach' means: do NOT fork into the background. That doesn't seem right.
Yeah, whoops - it should have been "updetach". I added it in the email. The original doesn't use either and just expects the default detaching behavior.
Yes, that's my problem:
- updetach may wait a very long time before detaching.
- You cannot force 'detach' on the commandline.
As I see it you either want to wait for it to establish the connection, or you don't.
None of the other networking solutions wait (networkmanager, netcfg), most of them can't.
I'll make ppp not wait either - the 'updetach' is probably also problematic with 'demand'.
On Thu, Aug 30, 2012 at 7:38 PM, Thomas Bächler thomas@archlinux.org wrote:
None of the other networking solutions wait (networkmanager, netcfg), most of them can't.
NetworkManager.service does not wait for the network to be available (whatever that means), but there is NetworkManagcer-wait-online.service which will make network.target wait until you have a network connection (whatever that means).
-t
On Aug 30, 2012 2:06 AM, "Thomas Bächler" thomas@archlinux.org wrote:
While creating systemd units for my packages, I found two problems:
- I cannot force pppd fork to the background. While it is the default
behaviour, the user can override that with the 'nodetach' and 'updetach' configuration options.
Should I use Type=simple and force the 'nodetach' option on pppd?
- systemd has built-in watchdog functionality. Should I omit systemd
units for watchdog? With systemd, I don't need it anymore.
I believe the watchdog demon has features that systemd lacks. So in theory you could want to use them together.
Tom
arch-dev-public@lists.archlinux.org