ppp icon indicating copy to clipboard operation
ppp copied to clipboard

stderr redirects to connect-errors

Open betulum opened this issue 2 months ago • 10 comments

From chat man page: "If chat is being run by pppd, and pppd is running as a daemon (detached from its controlling terminal), standard error will normally be redirected to the file /var/log/ppp/connect-errors"

Why actual log file path ( /var/log/ppp/connect-errors or /etc//ppp/connect-errors) is defined at compile time ? I want to reset this option via command-line parameters instead of recompiling PPP

betulum avatar Nov 06 '25 13:11 betulum

@paulusmack, @jkroonza, @enaess, @chipitsine: What do you think?

Neustradamus avatar Nov 16 '25 23:11 Neustradamus

lrwx------ 1 root root 64 Nov 17 07:06 /proc/5026/fd/0 -> 'socket:[1741403202]'
lrwx------ 1 root root 64 Nov 17 07:06 /proc/5026/fd/1 -> /dev/null
lrwx------ 1 root root 64 Nov 17 07:06 /proc/5026/fd/2 -> /dev/null

Where pid 5026 is in fact a pppd instance.

I don't use the chat program. So everything here is speculation:

From pathnames.h:

110 #define PPP_PATH_CONNERRS       PPP_PATH_VARLOG  "/connect-errors"

The ONLY use of this is in device_script() in pppd/main.c where this bit of code sits:

1821     if (log_to_fd >= 0)
1822         errfd = log_to_fd;
1823     else
1824         errfd = open(PPP_PATH_CONNERRS, O_WRONLY | O_APPEND | O_CREAT, 0644);

So technically I think you can use the logfd option to achieve the desired.

Having said that, I'd be in support for a option such as "connecterrlog" specifically to redirect the connect and disconnect scripts to, which should supersede logfd in the case of those scripts. Will push a PR momentarily.

jkroonza avatar Nov 17 '25 08:11 jkroonza

what is wrong with hard coding, i.e. defining in compile time

chipitsine avatar Nov 17 '25 09:11 chipitsine

It's inflexible.

jkroonza avatar Nov 17 '25 09:11 jkroonza

but it is simple. and predictable

chipitsine avatar Nov 17 '25 09:11 chipitsine

flexibility itself is complication. there must be another reason, not just flexibility

chipitsine avatar Nov 17 '25 09:11 chipitsine

flexibility itself is complication. there must be another reason, not just flexibility

Whilst I don't disagree with the premise of your statement, for me the fact that someone asked for it and it's a minor complication is good enough. The option does remain privileged such as to avoid a normal user being able to override say /etc/passwd.

jkroonza avatar Nov 17 '25 09:11 jkroonza

yep, it even in theory opens a possibility to override some system file.

so, if there're reasons behind that, it worth implementing. if there're no reason, let's keep it as is

chipitsine avatar Nov 17 '25 10:11 chipitsine

@betulum this is now up to you.

Yes, this option can benefit from work in another PR that's still WIP (I'm bogged down on time to loop back to that).

jkroonza avatar Nov 17 '25 10:11 jkroonza

Since the connector script is passed to /bin/sh, you can redirect its stderr anywhere you like simply by putting e.g. "2>/path/to/file" at the end of the connector script.

paulusmack avatar Dec 05 '25 21:12 paulusmack

@betulum: Have you seen the @jkroonza PR and comments?

  • https://github.com/ppp-project/ppp/pull/575

Neustradamus avatar Dec 14 '25 10:12 Neustradamus