[Varnish 6.x] "varnishhist" produces "Assert error in do_curses(), varnishhist.c line 392: Condition((curs_set(0)) != ERR) not true. Aborted"

[fevangelou]

Steps to Reproduce (for bugs)

Running "varnishhist" produces the following error:

Assert error in do_curses(), varnishhist.c line 392:
                                                      Condition((curs_set(0)) != ERR) not true.
                                                                                               Aborted

...and fails to run. Varnish serving is not affected in any way.

If it helps, Varnish was upgraded from a previous version provided by the Ubuntu 20.04 repos into the latest in the 6.x series provided by packagecloud.io/varnishcache/ (using the auto install option with curl -s https://packagecloud.io/install/repositories/varnishcache/varnish66/script.deb.sh | sudo bash).

The applied VCL config validates just fine for the record (I doubt it's related either way, just mentioning).

Your Environment

• Version used: varnishd (varnish-6.6.1 revision e6a8c860944c4f6a7e1af9f40674ea78bbdcdc66)
• Operating System and version: Ubuntu Server 20.04.3 LTS
• Source of binary packages used (if any): https://packagecloud.io/varnishcache/

[fevangelou]

Adding a few extra details:

The above error occurs on Ubuntu Server 18.04.6 LTS as well, with the same Varnish version varnishd (varnish-6.6.1 revision e6a8c860944c4f6a7e1af9f40674ea78bbdcdc66).

Tested on dedicated servers as well as LXC-based containers (via Proxmox), Ubuntu 18.04 & 20.04, on the same version of Varnish which was updated just today to 6.6.1.

Unlike the 20.04 based servers, the ones on 18.04 were upgraded from the "varnish64" branch of https://packagecloud.io/varnishcache/.

[nigoroll]

@fevangelou thank you for the report. This has triggered because we added 0d4966b404e33d7f973b9c15e44561fd71151c3e deliberately to understand if we run into any curses issues. Can you please help us understand your environment better? How are you using the terminal? What is the value of your TERM variable? Do you use a non-standard termcap file? Does this change if you change the window size?

[fevangelou]

Stock terminal that comes with Ubuntu Server. No customizations whatosever.

For Ubuntu 20.04 specifically, it's whichever Bash version comes with the OS (updated). In my case: GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu). And echo $TERM reports xterm-color.

For Ubuntu 18.04 it's GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu) and echo $TERM again reports xterm-color.

Also:

Do you use a non-standard termcap file?

Nope.

Does this change if you change the window size?

Changing the terminal's size does not change anything to the error message (and Varnishhist still doesn't work).

Is there some new requirement to install an additional library (e.g. libncurses5 or libncurses6)?

[nigoroll]

Thank you, that is interesting. The failing call should turn off the cursor and we do not understand why that fails. Does using a different TERM setting change anything, for example could you try

export TERM=xterm

or

export TERM=vt100

?

[fevangelou]

I can confirm that setting TERM to xterm restores varnishhist, but vt100 produces the same error as with xterm-color. Tested on both Ubuntu 18.04 & 20.04.

[fevangelou]

More feedback on this...

I use Panic Coda's terminal to access my servers. So xterm-color comes from it obviously. Varnishhist worked just fine with this terminal in the past.

If use my macOS' terminal, echo $TERM returns xterm-256color and this DOES work with varnishhist just fine.

[nigoroll]

Thank you. So I presume you have a workaround now. We will look after fixing this one way or another.

[fevangelou]

Yes, of course. And thank you for the insights.

It's interesting how varying TERM can be depending on the terminal app one uses.

E.g. macOS 10.7+ Terminal.app uses xterm-256color. Coda apparently uses xterm-color due to some b/c with macOS releases before 10.7.

On the other hand, Termius uses just xterm (again assumingly for better b/c compatibility with other systems) while iTerm2 or Tabby (previously "Terminus") or Alacritty all use xterm-256color.

For anyone dealing with this issue, thankfully, this can be solved by patching your ssh config file with:

Host *
    RemoteCommand          TERM=xterm-256color $SHELL
    RequestTTY             yes