7

I've discovered that if I go into "copy mode" or "scrollback mode" in a byobu screen, detach from it and leave it running, the buffer will fill up and eventually block the process I'm running in the screen. (Presumably because the process is prevented from writing to stdout, since there's no one to consume the bytes.)

This behaviour is kind of devastating. Is it possible to for instance

  1. Automatically exit copy / scrollback mode upon detaching from the screen,

    or

  2. Let the position of the view which is in copy / scrollback mode move forward once the buffer is full, to allow for the process to continue executing

Happy to hear of any advice on this.

Improve this question
4
  • Looked into the src. Appears this would require a patch to gnu-screen. Same for tmux. There's just nothing for byobu to latch onto to handle it for you. =/ Patch seems fairly straightforward: when last client disconnects, drop all copy-mode windows into regular mode OR when client disconnects and was viewing a copy-mode window, drop that window into regular mode. It's just not something that already exists. Also, I have new respect for tmux, that code appears well organized.
    – Andrew Domaszek
    Mar 9, 2015 at 6:44
  • This seems so strange to me. Screen/tmux are often used for servers, scrollback mode is not an obscure feature, servers often log stuff regularly on stdout and the buffer will eventually fill up. This must be a really common problem! May I ask, can you reproduce this, or is it a misconfiguration on my part?
    – aioobe
    Mar 9, 2015 at 9:32
  • 1
    I can reproduce it. Easiest way is to start a big compile (glibc, gcc, libreoffice, etc) and then switch to scrollback & detach. It's one of the reasons I very rarely use scrollback mode. You're correct as to the cause as well, the output FIFO is full so it is stalled waiting to write.
    – Andrew Domaszek
    Mar 9, 2015 at 12:01
  • Thanks Andrew, I really appreciate this. Sum up your comments in an answer if you're interested in the bounty.
    – aioobe
    Mar 9, 2015 at 12:11

1 Answer 1

Reset to default
4
+250

Your assessment is correct, the program running within the scrollback-mode window is stopping because its output buffer is full and it is suspended waiting to write. This behavior is both correct and desirable; the user entered scrollback mode to view the screen contents but as you have noticed, this is not convenient nor obvious when the session is detached.

Unfortunately it appears to be a missing feature in both gnu-screen and tmux. byobu wouldn't be able to fix it in a wrapper because it can't detect the scrollback state of a given window, nor can it break a window out of it using external commands, though it could send commands to the terminal like the user would, were it able to detect or remember the scrollback state. Neither screen nor tmux appear to include a feature to enable automatically reverting from scrollback mode when the terminal is detached. A patch would be required.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .