# Bootup stalls if net.ppp0 fails to start

## Ringtail

Hi all.  I have a problem configuring VPN Internet access on my Gentoo box.  Basically, the machine just hangs at boot whenever VPN connection cannot be established for any reason.

My machine is connected to the ISP's LAN, spanning about a third of the city.  For Internet access, a VPN connection (via PPTP) is established to the ISP's VPN gateway.  (AFAIK this Internet access scheme isn't very widespread outside of Russia.)  Therefore two interfaces are brought up at boot, eth0 (LAN) and ppp0 (PPTP VPN).

The problem is, VPN gateway isn't 100% reliable and might occasionally be down for periods of 3-20 minutes, when no Internet connection is available.  Unfortunately if I happen to boot my machine in that period, it locks up when trying to bring up ppp0, until either it finally succeeds, or I reboot it, choose interactive boot and tell it to skip net.ppp0 service.

This is my /etc/conf.d/net file:

```
#-----------------------------------------------------------------------------

# LAN

config_eth0="10.1.22.60 netmask 255.255.255.0"

dns_servers_eth0="10.0.0.1 10.0.0.2"

routes_eth0="10.0.0.0/8 via 10.1.22.3

             217.76.183.1 via 10.1.22.3"

#-----------------------------------------------------------------------------

# VPN connection

RC_NEED_ppp0="net.eth0"

config_ppp0="ppp"

link_ppp0="pty '/usr/sbin/pptp vpn.olympus.ru --nolaunchpppd'"

username_ppp0='uav'             # password is in chap-secrets

pppd_ppp0="defaultroute

        noipdefault

        noauth

        asyncmap 0

        crtscts

        lock

        hide-password

        local

        noproxyarp

        lcp-echo-interval 30

        lcp-echo-failure 4

        noipx

        nopersist

        updetach"
```

I use baselayout-2.0.0, openrc-0.2.5, ppp-2.4.4-r15, pptpclient-1.7.1-r1.  The problem is readily reproducible if, for example, I specify an incorrect password in chap-secrets and try to do /etc/init.d/net.ppp0 restart; it locks up just the same.

What I would like to see is: if net.ppp0 fails to start in e.g. 30 seconds, it keeps trying in the background and the boot process resumes.

/etc/conf.d/net.example says the following about updetach:

```
#       "updetach"      # If not set, "/etc/init.d/net.ppp0 start" will return

#                       # immediately,  without waiting the link to come up

#                       # for the first time.

#                       # Do not use it for dial-on-demand links!
```

This would be okay for me (although I'm not sure ddclient, which depends on net.ppp0, would start correctly then), but in reality omitting updetach option seems to have just the opposite effect; /etc/init.d/net.ppp0 doesn't quit even after the connection is successfully established.  Other documentation and Google aren't helpful.  Of course I might be missing something entirely obvious.

Thus I'm at a loss.  Two weeks ago I installed Gentoo for a friend who doesn't know anything at all about Linux, and so far she has been surprisingly happy with it (after I spent four days emerging everything and one more day configuring her hardware, of course  :Cool: ), but today she ran into same problem (with a different ISP), and I had to explain her over the phone how to skip net.ppp0 service on boot.  So naturally I'd like to know how to avoid this lockup in the future.

----------

## geforce

I think you can CTRL+C while it is locked, but you definitively need to find a better workaround  :Razz: 

What about a script in local.start to do it ?

----------

## Ringtail

 *geforce wrote:*   

> I think you can CTRL+C while it is locked, but you definitively need to find a better workaround 

 

No, at boot it doesn't react on Ctrl-C.  I can only watch syslog logging failed connection attempts on Alt-F12, or hit Ctrl-Alt-Del to reboot the whole thing.

 *Quote:*   

> What about a script in local.start to do it ?

 

Hmmm, not a clean workaround either...  but I'll try that if I don't find any better solution.  Thanks for the idea.

----------

## mrness

Offtopic: ppp baselayout module MUST run pppd in persist mode.

Check your /etc/ppp/options or options.ppp0 and make sure you don't have "nodetach" in them.

----------

## pa4wdh

Hi,

Sorry for popping-up this old post again, but i have exactly the same problem: I want to start ppp0 (also a pptp tunnel, but in my case for an adsl connection) at boot time, because some services bind to the public IP address. However, if it fails (and it does every now and then) i don't want to stall the boot process.

I'm actually searching for some kind of timeout ....

One other thought .... it might just work, but i don't have time to make it now:

In /etc/conf.d/net create a preup function, and if it's for device ppp0 start an external script (and start it in background).

Also in /etc/conf.d/net configure ppp0 with the updetach flag.

In the external script, issue a sleep with the desired timeout (lets say 10 seconds). After that time the script checks the presence of the ppp0 interface and optionally checks the IP address. If it's okay, i guess the boot process has already gone further. If it's not, kill the pptp processes (which helps in my case if i do it by hand) or maybe pppd too, but i don't know how the initscripts respond to that.

Any ideas ?

Best regards,

pa4wdh

----------

## mrness

If you don't have updetach in your pppd options and net.ppp0 still blocks at booting then it is a baselayout bug.

Just make sure you don't have updetach in /etc/ppp/options or pppd_ppp0 before filling up a bug.

----------

## pa4wdh

Just to make it clear:

I want to have the updetach flag, because if everything works i want the boot process to wait until the interface is up. However, if it doesn't work it shouldn't wait endlessly.

As far is i know this is expected behavior, so i won't file a bug. I just want something between having updetach and not having updetach  :Smile: 

----------

## mrness

updetach means that /etc/init.d/net.ppp0 start will freeze until the link is started for the first time (duh). If something doesn't work and it is not fixable just by retrying over and over again, it will stop the boot process forever. Believe me, you don't want that.

I don't know what kind of broken script you want to run after net.ppp0 is started, but you have many ways of executing scripts on interface startup:

  1) postup function in /etc/conf.d/net

  2) an /etc/ppp/ip-up.d/xx-whatever.sh script

  3) if you like cron scripts (although I wouldn't recommend writing such script when you can do it on event base script), just make sure that "/etc/init.d/net.ppp0 --quiet status" return 0 before running anything dependent on ppp0 interface. That means net.ppp0 is in active state (as opposed to inactive state when net.ppp0 was started but the link didn't came up yet).

----------

## mrness

For those of you who are too lazy to grasp what I've just written, there is a way to make updetach option less blocking... sort of. You can set "maxfail x" where x is the number of tries that pppd will do before failing for good.

 CAUTION: Don't complain when your net.ppp0 will remain inactive after pppd failed for x times to start the connection. The PPP baselayout net module was designed based on the premise that pppd will be executed with "persist maxfail 0", but I've allowed this option into pppd_pppX because I got tired to argue against it.

----------

## pa4wdh

You sound a bit rude mrness, but i assume that's just my interpretation and not intended.

 *Quote:*   

> 
> 
> updetach means that /etc/init.d/net.ppp0 start will freeze until the link is started for the first time (duh). If something doesn't work and it is not fixable just by retrying over and over again, it will stop the boot process forever. Believe me, you don't want that. 
> 
> 

 

Thats exactly what i'm searching for something in between, because directly backgrounding doesn't do the job either.

 *Quote:*   

> 
> 
> I don't know what kind of broken script you want to run after net.ppp0 is started, but you have many ways of executing scripts on interface startup: 
> 
> 

 

No, i want to start something *before* starting pppd (with preup), because if it hangs there will be no after. The script will be able to take action to get out of the hanging situation so the boot process can go on. I don't see how that's broken ...

 *Quote:*   

> 
> 
> For those of you who are too lazy to grasp what I've just written, there is a way to make updetach option less blocking... sort of. You can set "maxfail x" where x is the number of tries that pppd will do before failing for good. 
> 
> 

 

I'll try that, not sure if it will work with pptp. The default of pppd is 10 but it can hang for hours with pptp in the faulty situation.

 *Quote:*   

> 
> 
> The PPP baselayout net module was designed based on the premise that pppd will be executed with "persist maxfail 0", but I've allowed this option into pppd_pppX because I got tired to argue against it.
> 
> 

 

What do you think is the problem with this ? I'm searching for solutions, and if there are arguments against using this it might not be the solution i should use.

----------

## mrness

 *pa4wdh wrote:*   

> You sound a bit rude mrness, but i assume that's just my interpretation and not intended.

 

If I sound rude it is because I got tired to repeat the same thing over and over again.

 *pa4wdh wrote:*   

>  *Quote:*   
> 
> The PPP baselayout net module was designed based on the premise that pppd will be executed with "persist maxfail 0", but I've allowed this option into pppd_pppX because I got tired to argue against it.
> 
>  
> ...

 

Once you start net.ppp0 it is supposed to never stop trying to start the link ... not until user stops the service. Since you set a maximal number of tries, it is reasonable to think that in some circumstances this limit is met, in which case you will find your precious net.ppp0 service just lingering in inactive state without any hope it will be automatically started up again (pppd process, the one responsible with maintaining this link, will be long gone at that moment). Call me idealist, but having a dead service that will never be up again (without user intervention that is) is just not acceptable.

I  have to stop explaining this to users, it just dries me out. This is my last tentative to explain it, so say we all!

Btw, pppd might have a default of maxfail 10, but PPP baselayout module does not. Unless you set it explicitly, it will assume maxfail 0 (the sane option for a service).

----------

