Was able to add a work around to networking/telnetd.c in function make_new_session()

Addition of
    signal(SIGINT, SIG_DFL);

near line 330 seems to work.

(In reply to comment #0)
> If tail -f <filename> is used on busybox 1.16.0 in a telnet session, then you
> want to stop it using ctrl+c it does not work.

Does Ctrl-C work for other applets started in the telnet session, such as bare "cat" from shell prompt?

> (Ctrl+c does work if using
> UART console, and ctrl+c does work when using less in telnet to prove that my
> telnet client is configured correctly).

busybox's less installs SIGINT handler. Therefore, it might be unaffected by bad SIG_IGN.

(In reply to comment #1)
> Was able to add a work around to networking/telnetd.c in function
> make_new_session()
> 
> Addition of
>     signal(SIGINT, SIG_DFL);
> 
> near line 330 seems to work.

If this helps, it means that SIGINT is set to SIG_IGN. Can you verify this by using this line instead?

      bb_error_msg("Prev INT handler:%p", signal(SIGINT, SIG_DFL));

If it will print "1", then the setting was SIG_IGN indeed.
If this is the case, we need to figure out where it was set.

telnetd does not change SIGINT handling. (Please check it with strace to be sure). It must be its parent process then. Where do you launch telnetd from?

> Where do you launch telnetd from?

telnetd is launched from /etc/rc3.d/S009telnetd -> /etc/init.d/telnetd during initialization.

I need answers to all of my questions, not just the last one.

> Addition of
> >     signal(SIGINT, SIG_DFL);
> > 
> > near line 330 seems to work.
> 
> If this helps, it means that SIGINT is set to SIG_IGN. Can you verify this by
> using this line instead?
> 
>       bb_error_msg("Prev INT handler:%p", signal(SIGINT, SIG_DFL));
> 
> If it will print "1", then the setting was SIG_IGN indeed.
> If this is the case, we need to figure out where it was set.

This would be the most crucial test. If the printed value would be 1, then the parent process which starts telnetd is to blame: it sets SIGINT to SIG_IGN. Please find out which process is the parent, and where/why it sets SIGINT to be ignored.

In this case "signal(SIGINT, SIG_DFL)" is just a work-around: it's the parent process' responsibility to not mangle execution environment of the child. (For one, there are many more ways how parent can do bad things: it can mask signals, it can leave stray open file descriptors, etc.)

Thank you for the analysis, will take a look at the parent process to see where if sets SIGINT to SIG_IGN

Closing, since the problem appears to be external to tail. Reopen if you have new information.