Is this PPPoE connects error anything to be concerned about?

Hi all,
Just a simple yes or no would do for this question, are the following errors anything to be concerned about when my PPPoE connects:

Failed to create pid file /var/run/pppd/ppp-ipfire.pid: No such file or directory
Failed to create pid file /var/run/pppd/ppp0.pid: No such file or directory

Hi @markadewet thanks for flagging this up.

I am afraid the answer is maybe, maybe not.

This message means that ppp was not able to create the pid file because the base directory had not been created.

Some ppp users have had this problem in the past and those users had the situation that because there was no pid their ppp was not able to start.

It seems that your system did start even without the pid file, otherwise your question would have been about why your ppp connection was failing to connect to the internet. rather than about log messages.

The issue with the directory structure is that a bug was created back in ppp-2.5.0 where the /var/run/ directory was stopped being defined for pid files or lock files and was no longer created on the basis that all distros would define and create them anyway. This was flagged up by some distros and users as a bug.

The ppp devs created a bug fix for this… The plan was for the fix to be released in ppp-2.5.1 but this release has failed to occur since the bug fix was implemented in October 2023.

Therefore I extracted a source tarball from the ppp git repo and created an update ppp-e1266c7 which was released into Core Update 185.

I believe that you are using CU185 so I would not expect to see that message anymore on your system.

Maybe the bug fix only got applied to the lock files and not to pid files, I am not sure.

Directory structures for pid and lock files are normally defined by the applications although the locations are usually pretty standard (but not 100%).

As you are getting this message then I am going to go back to the IPFire implementation of ppp and rather than depend on the ppp definition and creation of the directory base, I am going to look and see about defining and creating the locations in the installation build of ppp so that any required directories for lock files or pid files are always created as part of the install. That way we define a standard and make sure it is always in place.

@adamgibbo what thoughts do you have about this and are there any potential issues with what I am proposing to look at doing?

1 Like

@bonnietwin Thank you for your reply and happy I could provide information on a potential bug.
Yes I am on CU185 and my PPPoE does connect successfully so I have not really worried about these errors. Thank you for taking the time to break it down for me. Will await any update or feedback on this.

Reading, rather quickly, through the various issue reports on this bug in the ppp-repo issues section I have found that the pid file location is mentioned near the beginning of the issues report but not again after that. Everything after that, that I could see was related to the lock files.

So maybe the actual bug fix was only made for the lock files.

Doing some further searching and reading I have found the following statement

unable to create pid file: no such file or directory

You need to create the directory /var/run. On earlier Slackware distributions, this was a symbolic link to the /etc directory.

This is a warning. The PPP software will work normally in spite of this message. However, the PPP-off script depends upon this file. It is a good idea to create the directory or make the link to the appropriate location.

The posix header, paths.h, defines the location for the pid file under the name "_VAR_RUN". If you wish to use a different directory for PPP and others, change the value for this define and rebuild the software.

So ppp can startup even if it can’t create a pid file but it may not shutdown in the best way possible if there is no pid file, so I think still needs fixing.

Of course above statement was related to Slackware and we are looking at IPFire so they may not fully match but it does seem that ppp can start even if it can’t store its pid file somewhere.

1 Like

This message has been mentioned back in CU179 Testing feedback

https://community.ipfire.org/t/core-update-179-testing-evaluating-ppp-2-5-0/10227/4

However the fix for it was implemented in the final release of CU179 so not sure why you are seeing the problem now.

@adamgibbo had those pid errors back in CU179 Testing and he tested out my fix and found that the messages about the pid files no longer were shown.

Will have to investigate further. Must be some difference between the details of the ppp connection for @adamgibbo and @markadewet

I have just seen the difference.

The @adamgibbo ppp connection was looking for the pid file in
/var/run/

The @markadewet ppp connection was looking for the pid file in
/var/run/pppd/

So interesting different ppp clients can be looking for pid file storage in different placers.

The only thing I can think of is that if I define the pid storage as /var/run/pppd/ then the clients that want to store it in /var/run/ can do that and the ones that want to store it in /var/run/pppd/ can also do that.

What do you think @adamgibbo

1 Like

Hey @bonnietwin, I’ve just checked my own IPFire logs and it does still show that it failed to create pid file:

11:47:38        pppd[xxxx]:     Plugin pppoe.so loaded.
11:47:38        pppd[xxxx]:     PPPoE plugin from pppd 2.5.1-dev
11:47:38        pppd[xxxx]:     pppd x.x.x-dev started by user, uid x
11:47:38        pppd[xxxx]:     Failed to create pid file /var/run/pppd/ppp-sys.pid: No such file or directory
11:47:43        pppd[xxxx]:     Max-Payload: 1500
11:47:43        pppd[xxxx]:     PPP session is 23
11:47:43        pppd[xxxx]:     Connected to xx:xx:xx:xx:xx:xx via interface redx
11:47:43        pppd[xxxx]:     Using interface pppx
11:47:43        pppd[xxxx]:     Failed to create pid file /var/run/pppd/pppx.pid: No such file or directory
11:47:43        pppd[xxxx]:     Failed to create pid file /var/run/pppd/ppp-sys.pid: No such file or directory
11:47:43        pppd[xxxx]:     Connect: pppx <--> redx
11:47:43        pppd[xxxx]:     CHAP authentication succeeded
11:47:43        pppd[xxxx]:     CHAP authentication succeeded
11:47:43        pppd[xxxx]:     peer from calling number xx:xx:xx:xx:xx:xx authorized
11:47:43        pppd[xxxx]:     local IP address xx.xx.xx.xx
11:47:43        pppd[xxxx]:     remote IP address xx.xx.xx.xx
11:47:43        pppd[xxxx]:     primary DNS address xxx.xxx.x.xxx
11:47:43        pppd[xxxx]:     secondary DNS address xxx.xxx.x.xxx

But, it doesn’t appear to be affecting anything. I’ll have a proper look later on.

[Edit]

For info I’m running Core-Update 186 Development Build: master/6158761b

Thanks,
A G

Thanks @adamgibbo . That’s interesting.

Maybe that change from /var/run/ to /var/run/pppd/ occurred in the ppp-e1266c7 release that I did and I missed it.

Your message now shows the directory /var/run/pppd/ whereas the original flagged message in the other post thread was /var/run/

I will check through the .configure options to see what I need to change or add and when I have figured it out I will do an update into what will become CU187

I have a feeling that creating the /var/run/pppd/ directory might resolve the log noise.

I’ll test it later on.

Maybe. It would be good if you can test that.

I have confirmed that the run dir location in the latest ppp I installed changed from /var/run/ to /var/run/pppd/

The problem looks to be that in the red networking initscript where the ppp is started it has the pid location hardcoded to /var/run/

https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/networking/red;hb=98278fef4c3321387c1673bddaa652fb0adb922d#l461
PPPOE_CMD="/usr/sbin/pppoe -p /var/run/ppp-ipfire.pid.pppoe -I $PPP_NIC"

I think that if I change the -p option so that the line ends up

PPPOE_CMD="/usr/sbin/pppoe -p /var/run/pppd/ppp-ipfire.pid.pppoe -I $PPP_NIC"

then the pid will try to be put in the right place. Otherwise we have pid files trying to be placed in both /var/run/ and /var/run/pppd/ which doesn’t seem good.
I probably also need in the same script to create the pppd directory in the /var/run/ directory.

Hopefully getting close to understanding and fixing this for CU187.

1 Like

I will also need to update the connection scheduler script as that also explicitly specifies /var/run/ and needs to have that changed to /var/run/pppd/

1 Like

Hi @adamgibbo
There is an alternative I could do. All the above is causing a lot of changes to IPFire because it has the pid file specified in /var/run/ and if I miss any location where it has been specified then it could break other things.

So I could just change the ppp build configure option to have the runtimedir changed back to /var/run/ as it was previously to the ppp-e1266c7 version. Then the majority of things stay as they are and it is just the command to ppp in the build to tell it where it should have the runtimedir.

That seems a much better choice to me.

EDIT:
Sorry:
Everywhere I have mentioned runtimedir I really meant runstatedir

1 Like

An extra ./configure option has been added which I had missed.

If --with-runtime-dir=DIRECTORY is not specified then the runtime dir for pid files is by default set at /var/run/pppd/

However if --with-runtime-dir=/var/run is specified then the runtime dir for pid files is set to /var/run/

The above occurs irrespective of what setting is defined for
–localstatedir=DIR or
–runstatedir=DIR

even though those are the same directories.

Anyway I think I now know how to fix it by defining
--with-runtime-dir=/var/run
in the configure options.

This will then use /var/run/ for the pid files and lock files and the directory is available and nothing else in IPFire needs to be changed because of this change.

Having said that it will be good if this can be evaluated by someone using ppp when CU187 goes to Testing Release.

2 Likes

Patch has been submitted into dev mailing list

https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/2FS2QYPU665YWNCSHLWWRWXZVOI3RJFQ/

2 Likes

I test almost all releases in the testing channel, so I’ll report back here.

Perhaps this is something which can be left until IPFire 3, assuming that the testing goes ok.

Thanks for your work, Adolf.

1 Like

I’ve tested the latest testing release and I can confirm that the log noise has been resolved and hasn’t had any impact on PPPoE connectivity on my system.

Thanks for you work @bonnietwin, as always.

A G

2 Likes

@adamgibbo Thank you, sir, for checking and thank you to @bonnietwin for submitting the patch.