Search results

Yes, that does work as well. Thanks, you're a star!

ices2 does not use systemd setsid gave the same result, however nohup does work! Thank you very much for your input :cool: One final question. Any idea why this has only been an issue with LXC? I have pretty much the exact same setup running on an Azure instance and have never had any...

Thanks for getting back. I'm getting the same results:

Occasionally I'm having issues when trying to exit CTs that I've used pct enter to enter. I usually use ctrl-d to exit but I've found that typing exit gives the same result. I have cloned one of the CTs to 100 and am using to test this. When I exit the terminal hangs as in the image below...

That's the one. Thanks. Any news on when a fix will be stable?

ps -ef|grep -i defunct root 5911 25477 0 13:36 pts/10 00:00:00 grep -i defunct ps -edalf |grep " Z " 0 S root 6531 25477 0 80 0 - 3197 pipe_w 13:36 pts/10 00:00:00 grep Z

pve-zsync seems to have got stuck last night pve-zsync list SOURCE NAME STATE LAST SYNC TYPE CON 1000 1000 ok 2018-09-11_22:32:48 lxc ssh 1001 1001 ok...

Thanks for getting back Is this true for a zvol on both sides of pve-zsync? ie Can I also take a snapshot of the receive side without the pve-zsync snapshots clashing?

If I have pve-zsync running every 15 minutes using, for example, --maxsnap 2 and take a snapshot backup that takes 6 hours will the snapshot created by the backup interfere with the removal of pve-zsync snapshots? Do I need to pve-zsync disable in this situation?

Thanks :)

My containers are not obeying their allocated swap. For example container 111 has been allocated 128MB swap. arch: amd64 cores: 1 cpulimit: 1 cpuunits: 100 hostname: XXX memory: 2048 net0: name=eth0,bridge=vmbr0,gw=10.0.0.1,hwaddr=36:1F:BC:1B:78:47,ip=10.0.0.111/32,type=veth ostype: ubuntu...

Thank for this guys. One last thing, lxc.environment in /var/lib/lxc/N/config resets the the LXC is restarted. Is there a way to make it permanent? Can it be set in /etc/lxc/default.conf or should it be added to /etc/pve/lxc/N.conf?

Happy Birthday, keep up the good work!! :)

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?

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...

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

This only became a problem in the last couple of weeks

pveversion -v posted here LCX is running

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...

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.