[SOLVED] nano odd behaviour in LXC

dik23

Well-Known Member
Apr 3, 2011
102
1
56
I have a bash script in one of my LXC which involves the opening of a file at a certain line using nano +LINE

This had recently stopped working and the file is now opened at the top as if the +LINE wasn't entered. This is true for all users in that LXC and is the same if I do nano +LINE manually.

What I have discovered is that if I exit the LXC and use the container's nano to edit a file outside the container the line option works as expected. ie

Code:
/rpool/data/subvol-xxx/bin/nano +3 text.txt

Any ideas?



pveversion -v
Code:
proxmox-ve: 5.1-42 (running kernel: 4.13.16-2-pve)
pve-manager: 5.1-49 (running version: 5.1-49/1e427a54)
pve-kernel-4.13: 5.1-44
pve-kernel-4.13.16-2-pve: 4.13.16-47
pve-kernel-4.13.16-1-pve: 4.13.16-46
corosync: 2.4.2-pve3
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.0-8
libpve-apiclient-perl: 2.0-4
libpve-common-perl: 5.0-30
libpve-guest-common-perl: 2.0-14
libpve-http-server-perl: 2.0-8
libpve-storage-perl: 5.0-18
libqb0: 1.0.1-1
lvm2: 2.02.168-pve6
lxc-pve: 3.0.0-2
lxcfs: 3.0.0-1
novnc-pve: 0.6-4
proxmox-widget-toolkit: 1.0-14
pve-cluster: 5.0-24
pve-container: 2.0-21
pve-docs: 5.1-17
pve-firewall: 3.0-7
pve-firmware: 2.0-4
pve-ha-manager: 2.0-5
pve-i18n: 1.0-4
pve-libspice-server1: 0.12.8-3
pve-qemu-kvm: 2.11.1-5
pve-xtermjs: 1.0-2
pve-zsync: 1.6-15
qemu-server: 5.0-24
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.7-pve1~bpo9
 
No one have any ideas? The nano thing isn't a massive problem in itself but I am concerned about what else might not be functioning as it should.
 
What happens if you use joe instead of nano in your script (after installing the joe editor package in your container)?
Code:
joe +3 file.txt
 
joe places the cursor at line 3 as expected

purge and reinstall nano and I'm still on line 1 not 3
 
So, the cursor moves to line 3 in joe but not in nano when you run your script inside the container?
 
Anyone else have any ideas?

As I mentioned before nano thing isn't a massive problem in itself but I am concerned about what else might not be functioning as it should. Nano worked fine up until a week or two ago.
 
check that the nano your executing in the container is actually the nano binary you expect? maybe there is some sort of wrapper or alias that messes with it?
 
apt-get purge nano && apt-get install nano

whereis nano
nano: /bin/nano /usr/bin/nano /usr/bin/X11/nano /usr/share/nano /usr/share/man/man1/nano.1.gz

less /bin/nano
"/bin/nano" may be a binary file. See it anyway?

It's definitely a binary file!

ls -lah /usr/bin/nano
lrwxrwxrwx 1 root root 9 Oct 1 2012 /usr/bin/nano -> /bin/nano

ls -lah /usr/bin/X11/nano
lrwxrwxrwx 1 root root 9 Oct 1 2012 /usr/bin/X11/nano -> /bin/nano
 
pveversion -v posted here

LCX is running

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
 
I can reproduce this in a Jessie container - maybe something is broken in some old version of nano (or a library it uses)?
 
I have 14.04.5 running on metal here. Nano doesn't have this problem, nano +3 text.txt opens on the 3rd line.

So it seems to me that it's LXC that is causing this
 
Are the bash versions on your container, host and bare metal the same? (bash --version)
 
Proxmox VE
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)

14.04 LXC
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

14.04 metal
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

EDIT:

nano is the exact same version on metal as LXC:

GNU nano version 2.2.6 (compiled 14:12:08, Oct 1 2012)
(C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
2008, 2009 Free Software Foundation, Inc.
Email: nano@nano-editor.org Web: http://www.nano-editor.org/
Compiled options: --disable-wrapping-as-root --enable-color --enable-extra --enable-multibuffer --enable-nanorc --enable-utf8
 
seems like the value of $TERM influences nano, with TERM=linux (the default for "pct exec" and "pct enter"), it does not jump to the line. with TERM=vt102 (the default for the console) it does. how are you running nano when you say "in the container"? what's the value of $TERM?
 
  • Like
Reactions: dik23 and moxfan
I am running nano after pct enter N but the same is true when using pct exec

I think you've found the problem. If I do TERM=xterm-256color inside LXC I get the expected result when I do nano +3 text.txt

How is it possible to permanently alter TERM?


LXC
echo $TERM
linux

ProxmoxVE
echo $TERM
xterm-256color

Metal
echo $TERM
xterm-256color
 
if you execute a script inside of your container you can simply add a line there with
Code:
TERM=xterm
 
seems like the value of $TERM influences nano, with TERM=linux (the default for "pct exec" and "pct enter"), it does not jump to the line. with TERM=vt102 (the default for the console) it does. how are you running nano when you say "in the container"? what's the value of $TERM?
Good find, Fabian. I can confirm that the same error happens inside an openVZ container.

With LXC, the default TERM can be set permanently in the config file for the container.
Code:
cat /var/lib/lxc/105/config
.......
lxc.environment = TERM=vt100
.......

Both TERM=vt100 and TERM=vt102, as well as TERM=xterm, eliminate the error.

By the way, 'joe' (short for "Joe's Own Editor", a 'pico' clone that can be installed in modern distros) is not affected by the value of the TERM environment.
 
  • Like
Reactions: Ihor and dik23

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!