After upgrade to F42 screen buffer overflows

Ask Fedora
,
1

After I’ve updated several machines to F42, my rc-local.service exits when running screens. It creates the first one, and then exists as buffer overflow.
If I run it manually it also reports buffer overflow. ie simple command uname -a

# screen -S d -X screen 3 bash -c 'uname -a; exec bash'
*** buffer overflow detected ***: terminated
Aborted (core dumped)
#

Is this a screen (5.0.0-2.fc42) bug?
systemctl status rc-local.service shows:

Process 22909 (screen) of user 0 dumped core.
                                                       
                                                       Module /usr/bin/screen from rpm screen-5.0.0-2.fc42.x86_64
                                                       Module libcap-ng.so.0 from rpm libcap-ng-0.8.5-4.fc42.x86_64
                                                       Module libeconf.so.0 from rpm libeconf-0.7.6-1.fc42.x86_64
                                                       Module libaudit.so.1 from rpm audit-4.0.3-2.fc42.x86_64
                                                       Module libpam.so.0 from rpm pam-1.7.0-4.fc42.x86_64
                                                       Module libtinfo.so.6 from rpm ncurses-6.5-5.20250125.fc42.x86_64
                                                       Stack trace of thread 22909:
                                                       #0  0x00007f674bd53e5c __pthread_kill_implementation (libc.so.6 + 0x72e5c)
                                                       #1  0x00007f674bcfaabe raise (libc.so.6 + 0x19abe)
                                                       #2  0x00007f674bce26d0 abort (libc.so.6 + 0x16d0)
                                                       #3  0x00007f674bce36f3 __libc_message_impl.cold (libc.so.6 + 0x26f3)
                                                       #4  0x00007f674bde0389 __fortify_fail (libc.so.6 + 0xff389)
                                                       #5  0x00007f674bddfce4 __chk_fail (libc.so.6 + 0xfece4)
                                                       #6  0x00007f674bde1949 __strncpy_chk (libc.so.6 + 0x100949)
                                                       #7  0x000055c9a6b47835 main (/usr/bin/screen + 0x3835)
                                                       #8  0x00007f674bce45f5 __libc_start_call_main (libc.so.6 + 0x35f5)
                                                       #9  0x00007f674bce46a8 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x36a8)
                                                       #10 0x000055c9a6b49205 _start (/usr/bin/screen + 0x5205)
                                                       ELF object binary architecture: AMD x86-64
2

I’d assume it’s a bug you can report it in the Fedora bug tracker against screen.
See How to file a bug :: Fedora Docs

1 Like
3

Thanks I have filed a bug report, as no recent updates have made any changes

4

no activity in the bug report for 5+ days. Strange that anyone else doesn’t observe this, as I have same issue now on 5 upgraded F42 machines

5

I have not seen screen started as a service like you are doing.
Something about doing that is leading to the issue, and as I assumes its rare to do that no one else sees the problem.

I’ve always used screen to protect from a connection breaking.

1 Like
6

No I don’t start screen as a service. This log is from rc-local.service, where I execute few screen commands (create few screens and send some commands inside) so I can see status later when I login, and don’t need to create all screen everytime reboot happens.

7

Running in rc-local IS running screen as a service.

1 Like
8

Does screen have access to a tty device in your rc-local.service?
Maybe the lack of a tty is the issue if that is the case?

9

Oh and I wonder if you can solve the problem of priming your terminal with info without using scereen.

Off the top of my head put the info into a file and on login cat that file.
You can do that with a couple of lines in .bash_profile, with a check to only do it if on a real tty.

1 Like
10

I’m sorry but I don’t quite understand your questions. I do not know if rc-local.service has access to to tty device. But I have 40+ servers (approx half F40/41 half Ubuntu 24.4) and I run screen commands on all of them (with rc-local.service) and never had troubles until upgrade to F42.
The actual “buffer overflow” is shown if I isue command directly from the terminal as root user, whereas if I just run screen -S ScrName it works fine and I can add new screens within without problem. I also get buffer overflow when trying to send command to existing screen.
It is interesting that 1st screen gets created always after reboot.
I’m waiting to maybe new screen update, but nothing yet even after 3 kernel updates in F42.

11

but I remember now when updating a couple of laptops to F42 and I created screen locally, and then trying to enter it remotely from different computer and I couldn’t detach it. and vice versa, when I created screen remotely, then I couldn’t detach it on actual machine. So it may well be something connected to tty, though I know very little about ttys

12

The tty command returns the tty for a process.
What do you get in the working systems vs. F42 rc-local?

13

I’ve ran tty on different machines and within screen, outside of screen, and via crontab script and I just get different number of pts

root@pzb:/etc# tty 
/dev/pts/4
root@pzb:/etc#

whereas running from crontab I get

root@dg6:/etc# cat /tmp/tty.txt 
not a tty
root@dg6:/etc#

and I get same result in F41, F40. So something else must have changed. Most obvious to me is new screen command which was upgraded to 5.0.0 and still no update.
But I get buffer overflow also when running screen command directly from terminal, so it’s not environmental variables I would presume

14

I expected that you should see no tty report in a systemd service.
As screen only works for a tty, I assume, that likely explains why this does not work.

15

I’m sorry but how it explains why it doesn’t work? And how come it works in F41-?

16

Do you still have a f41 system to experiment with?

I have two thought, (1) I did not expect this to work (2) there must be a more robust way to achieve what you want without using screen.

1 Like
17

Yes I have plenty F40, F41 running, but I can’t just restart them to check if rc.local is working.
I do still have some issues with running screen via rc.local, as not all variables are loaded in this screen, but more or less is OK for most of screens, but for the ones that I work in, I just do exit and CTRL-A C to create a new one and it works.
Well I’ve been using screen for 25+ years and serves me well, especially if I have some programs that run in podman due to incompatibilities with newer Fedora libs, virtualmachine…so I see some history when I log in. I do also have scripts that send emails on any changes that server do, so I know it’s possible to be without screen, but why if it’s working well. And it looks it’s being developed as F42 jumped to version 5.0.0.
normally i issue screen command like this

  screen -dmS d bash -c 'btm; exec bash'
  screen -S d -X screen 1 bash -c 'nvtop; exec bash'
  screen -S d -X screen 2 bash -c 'lscpu; sensors; exec bash'
  screen -S d -p 2 -X stuff $'su - ollama\n'
  screen -S d -p 2 -X stuff $'sudo podman compose\n'

Different server has different things running, but each have min 5-6 screens initialized on boot, so I don’t need to recreate the every reboot.
Hope this explains a bit more why I use screen and I like to start it on reboot

18

5 years ago I was doing similar things with screen, but always started from a user login. I would avoid using rc.local – maybehttps://superuser.com/questions/1276775/systemd-service-python-script-inside-screen-on-boot has some useful ideas.