host:
pveversion
pve-manager/7.4-3/9002ab8a (running kernel: 5.15.104-1-pve)

turnkey template:
nextcloud 17.2.1

container is unprivilidged and has nesting enabled both at creation time and runtime.

When logging in for the first time using the console feature of the procmox GUI. The first init sequence starts and I am asked to enter a password for adminer.

As soon as I hit enter after typing the password the screen freezes. Only hitting backspace will show the following;

Traceback (most recent call last):   File               │  
│ "/usr/lib/python3/dist-packages/libinithooks/dialog_wrap │  
│ per.py", line 82, in wrapper     retcode = method("      │  
│ " + text, *args, **kws)   File                           │  
│ "/usr/lib/python3/dist-packages/dialog.py", line 3130,   │  
│ in passwordbox     return                                │  
│ self._widget_with_string_output(   File                  │  
│ "/usr/lib/python3/dist-packages/dialog.py", line 1719,   │  
│ in _widget_with_string_output     code, output =         │  
│ self._perform(args, **kwargs)   File                     │  
│ "/usr/lib/python3/dist-packages/dialog.py", line 1518,   │  
│ in _perform     exit_code, output =                      │  
│ self._handle_program_exit(child_pid,   File              │  
│ "/usr/lib/python3/dist-packages/dialog.py", line 1484,   │  
│ in _handle_program_exit                                  │  
│ self._wait_for_program_termination(child_pid,   File     │  
│ "/usr/lib/python3/dist-packages/dialog.py", line 1430,   │  
│ in _wait_for_program_termination     raise DialogError(  │  
│ dialog.DialogError: dialog-like terminated due to an     │  
│ error: the dialog-like program exited with status 3      │  
│ (which was passed to it as the DIALOG_ERROR environment  │  
│ variable). Sometimes, the reason is simply that dialog   │  
│ was given a height or width parameter that is too big    │  
│ for the terminal in use. Its output, with leading and    │  
│ trailing whitespace stripped, was: 

 

I have been troubled by something similar in the past and then the conclusion was to enable nesting. But the fact that I have this time around whilst still running into this wall suggests there is mroe wrong with my setup than obvious at first glance.

I have enough resources allocated to the container so that should not be a bottleneck.

Any suggestions on how to proceed in determining the root cause would be much welcomed ;)

Forum: 
Jeremy Davis's picture

Firstly, apologies for slow response. I've been away and am still catching up...

The error message (python stacktrace) relates to the "dialog" program crashing, most likely because it (automatically) resized to an invalid valid. So I'm fairly sure that it is unrelated.

I just tried to recreate your issue locally (applied all available PVE updates and downloaded a fresh copy of the TurnKey Nextcloud 17.2.1 template first). I just used the defaults and it "just works" for me?! FWIW (after updates and before my test) I have the same Proxmox version as you:

root@pve ~# pveversion
pve-manager/7.4-3/9002ab8a (running kernel: 5.15.107-1-pve)

I do have a newer kernel version than you. Whilst I wouldn't expect the kernel version to cause this, perhaps it's worth updating just in case it's some weird edge case bug?

Also, out of interest, here is the config for my container:

root@pve ~# cat /etc/pve/local/lxc/127.conf
arch: amd64
cores: 2
features: nesting=1
hostname: JED-TEST-nextcloud
memory: 1024
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.1,hwaddr=36:B3:5A:A9:06:E7,ip=192.168.1.127/24,type=veth
ostype: debian
rootfs: local-lvm:vm-127-disk-0,size=8G
swap: 512
unprivileged: 1

You can find the same thing by catting /etc/pve/local/lxc/VM_ID.conf - where VM_ID is the VM ID number (i.e. mine is 127).

As you can see, mine is both nested and unprivileged.

Looking back at your past posts, this seems very similar to the previous issues you have reported. The specific issue you've reported here (hanging when setting Adminer user password) is consistent with MySQl (actually MariaDB) not running. TBH, unless you made a mistake (and it's not actually nested when you thought it was) I'm stumped on what could be causing this issue for you.

To try to troubleshoot, you could try getting into the container from the PVE host via the CLI. I.e.:

pct enter VM_ID

Again, where VM_ID is the VM ID of your container. Then check to see if my guess is right (that MariaDB isn't running) via systemctl. FWIW here's all the output of those commands on my system:

root@pve ~# pct enter 127
root@JED-TEST-nextcloud ~# systemctl status mariadb
* mariadb.service - MariaDB 10.5.18 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2023-05-03 00:57:38 UTC; 30min ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
   Main PID: 393 (mariadbd)
     Status: "Taking your SQL requests now..."
      Tasks: 8 (limit: 38418)
     Memory: 121.9M
        CPU: 1.574s
     CGroup: /system.slice/mariadb.service
             `-393 /usr/sbin/mariadbd

May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03  0:57:38 0 [Note] Server socket created on IP: '127.0.0.1'.
May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03  0:57:38 0 [Note] Reading of all Master_info entries succeeded
May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03  0:57:38 0 [Note] Added new Master_info '' to hash table
May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03  0:57:38 0 [Note] /usr/sbin/mariadbd: ready for connections.
May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: Version: '10.5.18-MariaDB-0+deb11u1'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Debian 11
May 03 00:57:38 JED-TEST-nextcloud systemd[1]: Started MariaDB 10.5.18 database server.
May 03 00:57:38 JED-TEST-nextcloud mariadbd[393]: 2023-05-03  0:57:38 0 [Note] InnoDB: Buffer pool(s) load completed at 230503  0:57:38
May 03 00:57:38 JED-TEST-nextcloud /etc/mysql/debian-start[420]: Upgrading MySQL tables if necessary.
May 03 00:57:38 JED-TEST-nextcloud /etc/mysql/debian-start[455]: Checking for insecure root accounts.
May 03 00:57:38 JED-TEST-nextcloud /etc/mysql/debian-start[465]: Triggering myisam-recover for all MyISAM tables and aria-recover for all Aria tables

If the "Active:" line of your output is anything other than "active (running)", then please share the output of:

journalctl -u mariadb

Plus also the output of the container config as I noted above.

I finally found some time to upgrade the host and I am ending up in the same situation I am afraid.

I have some more time now to try a vanila debian container and see how that goes.

#pveversion
pve-manager/7.4-3/9002ab8a (running kernel: 5.15.107-1-pve)

#cat /etc/pve/local/lxc/301.conf
arch: amd64
cores: 4
features: nesting=1
hostname: nextcloud2
memory: 2048
net0: name=eth0,bridge=vmbr0,hwaddr=C6:B5:CB:95:5B:2B,ip=dhcp,ip6=dhcp,tag=5,type=veth
ostype: debian
rootfs: local-zfs:subvol-301-disk-0,size=8G
swap: 512
unprivileged: 1

#on first boot / init of container
the symtom and error message is simalor to my first post

#systemctl status mariadb


mariadb.service - MariaDB 10.5.18 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-05-05 07:44:04 UTC; 2min 5s ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 248 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    Process: 266 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 289 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, sta>
    Process: 663 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 667 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
   Main PID: 432 (mariadbd)
     Status: "Taking your SQL requests now..."
      Tasks: 9 (limit: 38274)
     Memory: 87.6M
        CPU: 283ms
     CGroup: /system.slice/mariadb.service
             └─432 /usr/sbin/mariadbd

May 05 07:44:04 nextcloud2 mariadbd[432]: 2023-05-05  7:44:04 0 [Note] /usr/sbin/mariadbd: ready for connections.
May 05 07:44:04 nextcloud2 mariadbd[432]: Version: '10.5.18-MariaDB-0+deb11u1'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Debian 11
May 05 07:44:04 nextcloud2 systemd[1]: Started MariaDB 10.5.18 database server.
May 05 07:44:04 nextcloud2 /etc/mysql/debian-start[675]: Looking for 'mariadb' as: /usr/bin/mariadb
May 05 07:44:04 nextcloud2 /etc/mysql/debian-start[675]: Looking for 'mariadb-check' as: /usr/bin/mariadb-check
May 05 07:44:04 nextcloud2 /etc/mysql/debian-start[675]: This installation of MariaDB is already upgraded to 10.5.18-MariaDB.
May 05 07:44:04 nextcloud2 /etc/mysql/debian-start[675]: There is no need to run mysql_upgrade again for 10.5.18-MariaDB.
May 05 07:44:04 nextcloud2 /etc/mysql/debian-start[675]: You can use --force if you still want to run mysql_upgrade
May 05 07:44:04 nextcloud2 /etc/mysql/debian-start[705]: Checking for insecure root accounts.
May 05 07:44:04 nextcloud2 /etc/mysql/debian-start[715]: Triggering myisam-recover for all MyISAM tables and aria-recover for all Aria tables

Jeremy Davis's picture

Deep apologies for my super slow turnaround on this. I've had some (non-TurnKey related) crisis to deal with and I've really only been able to keep up with paid support and a bit of dev work behind the scenes to unblock some other team members. But I'm back at the desk now and hopefully should be back on top of things within the next day or 2.

Anyway, the weirdest part is that the most recent output you've shared looks like it's running fine!? (Albeit it's only been running about 3 minutes).

I wonder if it's a ZFS issue? Perhaps I'm getting confused, but I recall someone else having issues with our templates on PVE (which I also couldn't reproduce) was also using ZFS? Perhaps there is something weird going on there?

Also, if you want to test TKL against vanilla Debian, be sure to install MariaDB etc too.

Add new comment