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

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

I believe the watchdog demon has features that systemd lacks. So in theory
you could want to use them together.

Tom

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

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

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