#216 syncterm 1.7 starts to eat cpu when aborted abruptly

[Errol Casey]

When syncterm is aborted it seems to get hung and starts eating cpu and generating cpu load.

The processes are killed when I'm on vpn and it is abruptly terminated without syncterm exiting.

So it is self-inflicted but seems that it should not become a cpu hog...

[sbbs@vmi1943160 ~]$ ps -ef | grep syncterm
sbbs 994225 982181 84 Jan05 ? 2-02:19:45 /home/sbbs/repo/src/syncterm/gcc.linux.x64.exe.release/syncterm
sbbs 1155215 1155172 86 Jan06 ? 1-02:47:46 /home/sbbs/repo/src/syncterm/gcc.linux.x64.exe.release/syncterm
sbbs 1252688 1252645 48 Jan07 ? 06:29:57 /home/sbbs/repo/src/syncterm/gcc.linux.x64.exe.release/syncterm
sbbs 1317797 1317741 0 00:07 pts/3 00:00:00 grep --color=auto syncterm
[sbbs@vmi1943160 ~]$ killall -9 syncterm
[sbbs@vmi1943160 ~]$ uptime
00:07:41 up 9 days, 8:47, 1 user, load average: 6.22, 4.53, 3.54

[Anonymous]

What do you mean by "When syncterm is aborted" and "it is abruptly terminated without syncterm exiting"

What exactly is being done?

[Stephen James Hurd]

Possibly attaching gdb to one of the processes and providing the output of thread apply all bt would show where the issue is. If I can reproduce the issue, I can fix it.

[Stephen James Hurd]

Ok, assuming you were SSHing to the linux box over the VPN, running SyncTERM from there and the VPN drops, I may have fixed it fixed in git now, and the fix will be part of 1.8-rc2 (and eventually v1.8).

Please test when you have a change and let me know how it goes!

[Errol Casey]

I recompiled from syncterm git tree and reports version 1.8b is this the same as 1.8-rc2 ?

I saw similar cpu issue, not as drastic but top showed 90+ percent cpu utilizatio and load between 2-3.

Wanted to be sure i'm using latest.

[Stephen James Hurd]

So "1.8b" is basically any build from master between releases. As long as you download it after the change, it has the change in it. The -rcX builds are a specific git commit and never change. rc2 has not yet been released due to me finding some new bugs I need to fix before the 1.8 release.

Can you confirm that my assumption was correct though? I'm still mostly guessing at exactly what's happening, and I would expect that if the change I made used the right assumptions, it would have completely solved the issue.

Can you spell out the exact steps you use to reproduce? My previous assumption was something like this:

1. Connect to LinuxBox over SSH on a VPN connection.
2. Run SyncTERM on LinuxBox in curses mode (SyncTERM says "Curses" after the version).
3. Disconnect VPN
4. Reconnect to VPN, SSH back to LinuxBox, syncterm processes are using high CPU.

Please let me know exactly what is happening since it seems that wasn't it.

[Anonymous]

I'm on a mbp and vpned to work. I connect to my Linux VPS via web based terminal because I use non standard ssh port which is not allowed through the vpn.

Once connected to the VPS I run syncterm in in curses mode; and I get disconnected or disconnect forgetting to close my syncterm session.

ttyd is the web based terminal. https://github.com/tsl0922/ttyd

strace shows the following activity of the old process
read(0, "", 1) = 0
ioctl(0, FIONREAD, 0x7ffcab37bcac) = -1 EIO (Input/output error)
ioctl(0, FIONREAD, 0x7ffcab37bcac) = -1 EIO (Input/output error)
poll([{fd=0, events=POLLIN}], 1, 10) = 1 ([{fd=0, revents=POLLIN|POLLERR|POLLHUP}])
read(0, "", 1) = 0
ioctl(0, FIONREAD, 0x7ffcab37bcac) = -1 EIO (Input/output error)
ioctl(0, FIONREAD, 0x7ffcab37bcac) = -1 EIO (Input/output error)
poll([{fd=0, events=POLLIN}], 1, 10) = 1 ([{fd=0, revents=POLLIN|POLLERR|POLLHUP}])
read(0, "", 1) = 0
ioctl(0, FIONREAD, 0x7ffcab37bcac) = -1 EIO (Input/output error)
ioctl(0, FIONREAD, 0x7ffcab37bcac) = -1 EIO (Input/output error)
poll([{fd=0, events=POLLIN}], 1, 10) = 1 ([{fd=0, revents=POLLIN|POLLERR|POLLHUP}])
read(0, "", 1) = 0
ioctl(0, FIONREAD, 0x7ffcab37bcac) = -1 EIO (Input/output error)
ioctl(0, FIONREAD, 0x7ffcab37bcac) = -1 EIO (Input/output error)^Cstrace: Process 2598141 detached

lsof of the process shows the pts seems to have been deleted

syncterm 2598141 sbbs 0u CHR 136,6 0t0 9 /dev/pts/6 (deleted)
syncterm 2598141 sbbs 1u CHR 136,6 0t0 9 /dev/pts/6 (deleted)
syncterm 2598141 sbbs 2u CHR 136,6 0t0 9 /dev/pts/6 (deleted)

So maybe due to the ttyd session getting aborted/hung it is confusing syncterm ?

I have to restart the ttyd session obviosuly, since the underlying connection was broken by the vpn disconnect.

Let me know what else i can collect or explain. Thanks for your time and effort in investigating this.

[Errol Casey]

Deuce the above anonymous post was from me. Forgot to login first. I attached a gdb trace like you had originally requested.

I'll do more testing tomorrow while at work, and let you know if I see any difference. Rebuild after you announced 1.8-rc2 so I think I have the latest.

[Stephen James Hurd]

Ah, thanks, I'm digging in to this, and it looks like the thing that I thought I already fixed... trying to come up with another theory, it looks like curses may not actually be telling me there's an error. :(

[Stephen James Hurd]

Aha! The strace was key, thank you VERY much for including it. Committing a fix now, should be ready for you to verify tomorrow!

[Errol Casey]

Fixed! Great.

Tested twice and both types the process was gone. I have one in a defunct process state, but that was from previous version before your last fix!

Thanks so much. This will help with mysterious load issues on my VPS!

[Stephen James Hurd]

Fix confirmed, closing.

Thanks for the report and following up!