Long running headless TWIN hangs [on 32-bit system] about twin HOT 10 CLOSED

NOTE: I now have long running headless TWINs on i386, AMD64, ARM32 and ARM64. I have a watch dog process that will give me some idea of how long the TWIN server remains responsive. All four devices are running the same trio of programs in their headless sessions.

from twin.

This is odd. This must be a regression as i have had TWIN running on my Odroid XU4(Ubuntu), Odroid U2(ARCH), Raspberry pi 1/2/3 (Raspbian), Dell Inspiron 8600 (pentium m and Opensuse Tumbleweed) for long period of times. I will recompile and test. I had twin running for over 167 days with no issues on the odroid xu4.

from twin.

Sweet! What version of TWIN are you running? I'm running the latest from branch master (0.9.0++).

When I setup my tests this morning I found the hung TWIN had survived the kill and was still happily dead. And then I was amused that the next TWIN I started took over its socket. ;-) So I kill -9d it. So I have a fresh test running to see what happens.

from twin.

I had a similar problem, i.e. twin server not responding, and surviving even a kill, while analyzing issue #75 on 32-bit arm.
After I fixed that issue, this one disappeared too - at least for me.

Let's both continue keeping an eye on it.

from twin.

Yes, I suspect the incorrect buffer sizes could lead to this sort of behavior. :-D Although its been running great for the last four days. I'm going to shut it down and restart it on all devices with the new code. Now for a "TWIN" to bind them all...

from twin.

@cosmos72 I think you fixed this when fixing the other issue. I've had several long lived sessions. The only reason their life was cut short was due to installing upgraded TWIN. :-) Over three days on the last set of runs. One lets me know if it goes down by its light display failing. But I also routinely ping them through one of the services I'm hosting in TWIN. Things have been rock solid since the fix for issue #75.

A couple other interesting notes:

1. I launched TWIN to run a large rsync (few hundred gigs). I left it spilling file names it was transferring (-hv). Killed my terminal and logged back in, twattach'd and it had run to completion! Good job!
2. I had originally launched that TWIN session running through xterm. The older xterm does a splendid job rendering the TWIN display. The newer one, not so much. I'll have to see if that can be fixed. Anyhow I've seen this happen a few times: I launched my rsync in a maximized twterm. Then launched an editor to concurrently update a backup job script. One little twterm, overlapping a large full screen twterm. When the output from the rsync gets rapid it causes the edit job to become somewhat unresponsive and the cursor to disappear for periods. Hard to work a screen-oriented editor without knowing where the cursor is and not knowing if your keystrokes are getting through. :-) I killed the xterm, re-twattach'd from twin --hw=X,font=vga + twterm running full screen (HD). The cursor behaved and the terminal I/O was responsive! So twin --hw=X... + twterm is a superior terminal experience to plain ol' xterm. :-D

And that also means my backup job survived multiple terminal disconnects and the running programs ran to completion in headless mode.

I'd call this fixed until I see it break again. But it wasn't that hard to break before. Thanks!

from twin.

Good!

About your note on running twin --hw=tty inside an xterm: IIRC it's known that xterm is not the fastest terminal around,
and during intense activity the cursor will inevitably jump around - writing to a terminal intrinsically moves the cursor, and there's no way to avoid it. Putting the cursor back to where it's supposed to be drawn usually helps, but only up to a certain point.

One thing you can try to improve the responsiveness is to use --hw=tty,slow (you can get the full list of supported options with the recently added option --hw=tty,help)

from twin.

I can't say I ever thought to speed-test terminals... that's an interesting thought. But kudos to you for making twterm faster! You gotta document that --hw=tty,help somewhere in the source package! A shame the other drivers don't support it...

from twin.

I can't say I ever thought to speed-test terminals... that's an interesting thought. But kudos to you for making twterm faster!

Thanks :)

You gotta document that --hw=tty,help somewhere in the source package!

I will. That's why I added it in the first place.

A shame the other drivers don't support it...

Currently fixing that too.

from twin.

Thanks!

from twin.