I had to change quite a few things after emerging net-dialup/ppp-2.4.3-r10. As suggested, I examined net.example. I had to add 'config_ppp0=( "pppd" )' which doesn't seem to be documented currently. Otherwise the interface wouldn't come up at all because pppd doesn't get started. In the ppp section of net.example this isn't mentioned. Please consider adding a line explicitly stating that every (?) interface needs that config_${iface} stuff or else nothing will happen. Furthermore, please document the usage of "pppd" (or whatever it might supposed to be) in this case. I had migrated the "persist" pppd option, too, which the new scripts don't like either. In /lib/rcscripts/net.modules.d/pppd "persist" and some related options are being handled ungracefully because they are now "forced options" (which is bad, too). "persist" obviously is the default now which should be *prominently* documented because pppd's default is "nopersist". Same for "maxfail" which is now being forced to "0" - pppd's default is "10". Reproducible: Always Steps to Reproduce: 1. 2. 3.
"persist maxfail 0" are needed for setting pppd to keep trying no matter what. otherwise, PPP daemon might just die which is not something you could accept from an init script. your complaints could be reduced to the following: - the net.example should specify that you need config_${iface}=( pppd ) for PPP connections - the example file should contain a reference to man pppd satisfied?
That sounds good, thanks. I don't agree about enforcing persist and maxfail (especially not to "0") but this is not the right place to discuss that.
this _is_ the right place! take your best shot.
About any comments in this bug is invalid except the config_ppp0 thing. The net.example file already contained a reference to pppd man page. For any further comments, please see bug #114551.
I think that "maxfail" value should be user denined into net configuration file. If my modem can't sync, for example, or it's simply switched off my system doesn't boot! It stop trying to bring up ppp0 interface, and it isn't good imho
And you can't even ssh into the machine as the daemon is started only afterwards by default. Great for remote maintenance especially if the server is not easily physically accessible. But, alas, as Alin stated in comment #4 "about any comments in this bug" are invalid.
I already explained why persist&maxfail are forced options. If you want boot sequence to go on without waiting ppp0 to come up, you remove "updetach" option.
Alin, we're facing two extremes here: 1) "updetach" set -> Wait for all eternity if the link doesn't go up. Get blocked by your ISP if it has a policy against unlimited connection attempts. 2) "updetach" not set -> Boot through, no matter what. With "maxfail" *not* being enforced, the machine would boot through when the *user's* choice of attempts failed. Failed runlevels can be audited.
True, but what do you propose? I repet, if I don't force "persistent maxfail 0", pppd process could just die of old age, which mean ppp0 will also die without the possibility of coming up again on its own. When you speak of init scripts, this - by any standards - is not acceptable. A daemon should die at startup (when a fatal error occurs) or, if its functions come to a stop without a stop command, at least try to revive itself. Why do you want to use "updetach" when obviously you don't want to block other services till the PPP link is started? There are tenths of other ways to see if the ppp0 interface is really started or not (/etc/init.d/net.ppp0 status is the first that pops up in my mind).
(In reply to comment #9) > Why do you want to use "updetach" when obviously you don't want to block other > services till the PPP link is started? Ok, but... usually I set "maxfail 5" with "holdoff 4", after 5 tryes my home-server thinks: "holy s**t no internet... ok let's start ssh and ftp anyway" :)
why not start the ssh and ftp service (since in your configuration don't depend on Internet connectivity, don't see the reason of waiting ppp0 to come up) then do your connection error handler in cron (or better yet, in /etc/ppp/ip-up.local & ip-down.local)?
Alin, I agree about being persistent (meaning both daemons and humans ;-) ). I usually want to wait for the system to be fully functional, so I have "updetach" set. Just like Frittella said. And having read your response to him: Your suggestions mean meddling with the scripts more than the user would have to without maxfail 0. I don't want to get in trouble with my ISP either for connecting all the time during some half-outage or whatever reason the link doesn't come up. Furthermore, if I connect to often without getting through my account will be suspended and only be reset after at least 24 hours. Anyway, why enforce "maxfail 0" in the first place? Yes, the daemon might die after maxfail x (if x>0) attempts even with persistence activated. But let the user make his choice (and, thus, here comes my suggestion): - Make maxfail default to "0". Place a big, fat warning next to it like already in for "updetach". The average newbie won't touch the option but the more experienced user can do what he thinks is right. Gentoo is about choice. And it's not like this would be without precedent - both "persistent" and "maxfail" have been enforced only lately. Before the user could change them.
Okay, you want to set maxfail. It is an insane option (from an init script perspective) if you ask me, but I'll leave it to Roy. If Roy decides to make this change, all I ask is to append a "maxfail 0" in case it wasn't specified otherwise by the user.
Yes, appending maxfail in that case sounds good to me. Who is Roy, btw?
maintainer of the new baselayout
Created attachment 79013 [details, diff] Allows maxfail to be set Here's a patch against baselayout-1.12.0_pre15, although it should apply fine for pre13 too.
Created attachment 79014 [details, diff] Enabled maxfail and persist options New patch - this one should work. We also allow the persist option through as we set it anyway.
Roy, your patch looks good to me. Please add "maxfail 0" in net.example, along with a very big fat about messing with it.
(In reply to comment #18) > Please add "maxfail 0" in net.example, along with a very big fat about messing > with it. s/fat/fat warning/
Fixed in baselayout-1.12.0_pre16
