On Thu, Aug 30, 2012 at 2:06 AM, Thomas Bächler wrote:

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.

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 wrote:

...

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.

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 wrote:

Am 30.08.2012 02:50, schrieb Jan Steffens:

...

On Thu, Aug 30, 2012 at 2:06 AM, Thomas Bächler wrote:

...

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.

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.

On Thu, Aug 30, 2012 at 1:27 PM, Thomas Bächler 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).

On Thu, Aug 30, 2012 at 7:38 PM, Thomas Bächler 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