Occasional hangup when attaching to existing session.

Bug #1329783 reported by William Ting on 2014-06-13
38
This bug affects 8 people
Affects Status Importance Assigned to Milestone
byobu
Medium
Dustin Kirkland 

Bug Description

When I try to attach to an existing session, sometimes byobu hangs with the following on screen:

╭─wting@noa ~ ‹python-2.7.3›
╰─➤ byobu
Attaching: [screen____23803.byobu]

Sending variable: ['screen', '-S', u'23803.byobu', '-X', 'setenv', 'XDG_SESSION_COOKIE', 'fa1d14dd639c4c7845b457d200000001-1402667578.594595-890466949']
Sending variable: ['screen', '-S', u'23803.byobu', '-X', 'setenv', 'SSH_AUTH_SOCK', '/home/ting/.config/byobu/.ssh-agent']
Sending variable: ['screen', '-S', u'23803.byobu', '-X', 'setenv', 'SSH_AGENT_PID', '3357']

Waiting for an indefinite period of time doesn't seem to help.

Version: 5.74

Dustin Kirkland  (kirkland) wrote :

Hi there, thanks for the report.

Can you give me any more hints, as to how I might reproduce this problem?

Changed in byobu:
assignee: nobody → Dustin Kirkland  (kirkland)
importance: Undecided → Medium
status: New → Incomplete
Jon Davies (jon-hedgerows) wrote :

the only hint I can give to reproducing this is to keep connecting to existing sessions, and eventually it gets stuck. I get this pretty much every time it sticks, which is perhaps 1 in 10 times? I'm connecting using PuTTY, byobu is configured to launch at login.

Any hints as to how to diagnose what's going on here would be appreciated.

----cut here----
Using username "[redacted]".
Authenticating with public key "[redacted]"
Attaching: [screen____3604.boot]

Sending variable: ['screen', '-S', u'3604.boot', '-X', 'setenv', 'DISPLAY', 'localhost:10.0']
Sending variable: ['screen', '-S', u'3604.boot', '-X', 'setenv', 'XDG_SESSION_COOKIE', 'ab5e6992b69fe53a40ff4ca20000018c-1409305469.288543-1364373822']

Download full text (3.1 KiB)

Hi,
I can confirm that this happens on CentOS as well.

Using username "cody".
<email address hidden>'s password:
Send automatic password
Attaching: [screen____1933.byobu]

^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^A^A^A

This happens periodically. Sometimes, I ctrl-c when logging in and it will automatically end up back at bash instead of byobu. This gives me some insight. Normally, I just restart my host but this is getting annoying.

Using username "cody".
<email address hidden>'s password:
Send automatic password
^C'import site' failed; use -v for traceback
Attaching: [screen____1933.byobu]

^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C
Using username "cody".
<email address hidden>'s password:
Send automatic password
^Ccody@hosting:[~]$ ^C
cody@hosting:[~]$ ^C

cody@hosting:[~]$ w
 20:13:59 up 1 day, 8:48, 9 users, load average: 0.94, 0.72, 0.64
cody@hosting:[~]$ ps aux | grep byobu
cody 1933 0.0 0.1 135684 18212 ? Ss Oct21 1:20 SCREEN -S byobu -c /usr/share/byobu/profiles/byoburc /usr/bin/byobu-shell
cody 4774 0.0 0.0 106196 1576 pts/0 S+ 03:26 0:00 /bin/sh -e /usr/local/bin/byobu-select-session
cody 4800 0.0 0.0 118792 1176 pts/0 S+ 03:26 0:00 1933.byobu
cody 20387 0.0 0.0 106196 1576 pts/5 S+ 20:08 0:00 /bin/sh -e /usr/local/bin/byobu-select-session
cody 20413 0.0 0.0 118792 1184 pts/5 S+ 20:08 0:00 1933.byobu
cody 21296 0.0 0.0 106196 1572 pts/7 S+ 20:12 0:00 /bin/sh -e /usr/local/bin/byobu-select-session
cody 21322 0.0 0.0 118792 1180 pts/7 S+ 20:12 0:00 1933.byobu
cody 21709 0.0 0.0 103244 876 pts/8 S+ 20:12 0:00 grep byobu
cody 28261 0.0 0.0 106196 1576 pts/3 S+ 18:35 0:00 /bin/sh -e /usr/local/bin/byobu-select-session
cody 28287 0.0 0.0 118792 1180 pts/3 S+ 18:35 0:00 1933.byobu
cody 32599 0.0 0.0 106196 1576 pts/6 S+ 19:31 0:00 /bin/sh -e /usr/local/bin/byobu-select-session
cody 32625 0.0 0.0 118792 1180 pts/6 S+ 19:31 0:00 1933.byobu

If I try to go back into byobu now, it appears to lock up as normal. I can try killing all byobu sessions.

cody@hosting:[~]$ byobu --version
byobu version 5.86
WARNING: ulimit -u is too low
Screen version 4.00.03 (FAU) 23-Oct-06

I thought maybe it was because of the ulimit being too low (default 1024), I changed it to 10240, then tried to reopen byobu.

cody@hosting:[~]$ ulimit -u 10240 ;byobu --version
byobu version 5.86
Screen version 4.00.03 (FAU) 23-Oct-06
cody@hosting:[~]$ byobu --version
byobu version 5.86
Screen version 4.00.03 (FAU) 23-Oct-06
cody@hosting:[~]$ byobu
Attaching: [screen____1933.byobu]

I hit ctrl-z and it allowed me to background byobu.

Decided to kill all byobu via root and then went back to my account. Works fine now.

Seems as though screen is locking up.
I'm not super smart on understanding what I'm doing, but this is what I k...

Read more...

Alistair Muldal (alimuldal) wrote :

I'm seeing something similar using the tmux backend:

alistair@cjagpu3:~$ byobu
Attaching: [tmux____1]

Sending variable: ['tmux', 'setenv', '-t', '1', 'DISPLAY', 'localhost:10.0']

At this point it just hangs. My system details are below:

alistair@cjagpu3:~$ byobu --version
byobu version 5.74
tmux 1.8
alistair@cjagpu3:~$ uname -a
Linux cjagpu3 3.13.0-49-generic #83-Ubuntu SMP Fri Apr 10 20:11:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Sir_Magic (h-j-bijlsma) wrote :

I am seeing the same symptoms... About one in 10 logins get stuck at the 'sending variable' part

Though I continue my session using ctrl-z (probably sending something to the background by doing so)

byobu version 5.87
Screen version 4.03.01 (GNU) 28-Jun-15

3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt9-3 (2015-04-23) i686 GNU/Linux

Murukesh Mohanan (murukesh) wrote :

Further odd behaviour: When this happens, and I quit the SSH connection using <Enter>~. (SSH escape code), and reconnect, (I have an alias that goes: `ssh -Xt "$@" byobu-screen`), sometimes it starts a new byobu session instead of connecting to the old one, which hangs around like a zombie.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers