Search results

I found this bug report that distinguishes Proxmox as well as the difference between privileged and unprivileged containers. No resolution offered as the conversation implies this is a problem with Proxmox rather than Debian or needrestart.

While experience with package management and system design is the better foundation for knowing when to reboot a system, we use the needrestart tool as an additional guide and only as a guide. Some time ago I noticed the needrestart tool wants to always restart lxc-monitord.service and...

Some more information: with respect to my original post the cause is swap not unmounting. Today the server failed to reboot timely. I had enabled a debug console and confirmed the swap partition remained mounted. No clues in the logs. Again, just a normal swap partition, ZFS is not used. Before...

The host was rebooted. The log no longer exists. Edit: Next time the log will be redirected to /var/tmp.

At the moment, seems like the best route is manually shutdown containers before updating any pve package. pct list; for ct in $(pct list | awk '{print $1}' | grep -v VMID); do echo $ct; pct shutdown $ct; done; pct list

After updating libexpat1=2.2.0-2+deb9u3 and libpve-common-perl=5.0-55, we again got nailed by this problem. :( I ran the following to try to restart one container: lxc-start -n 160 -F -l DEBUG -o /tmp/lxc-160.log The results: lxc-start: 160: network.c: instantiate_veth: 106 Operation not...

Yes, but why? No, this happens on fully updated systems.

With the recent Debian packages updates, we experienced containers failing to restart. We've seen this before. The solution is mentioned at the end of this thread: find /sys/fs/cgroup/*/lxc/$CTID* -type d -print -delete pct start $CTID Does anybody know why this happens sporadically?

Just for the record, this reboot hang hit us again on this same server. No clues in the logs. Again, after 30 minutes the system finally rebooted. I suspect the 30 minutes is a systemd timeout. We have some NFS mount preconfigured in storage.cfg, but the mounts are disabled. The mounts are...

I notice on a reboot, such as a kernel update, the date stamp on /etc/pve/priv/authorized_keys and known_hosts change to the time of the file restoration from the database, which occurs when booting. I understand why this happens, but is there a way to preserve the date stamps? To me this is a...

Resolved. We had to login online, "Reissue" the subscription, and on the server run pvesubscription update. Root cause of the glitch unknown.

I hope I am missing the big picture somewhere. We have a valid Community subscription. I verified the subscription by logging in to https://shop.maurer-it.com. Our online account shows the subscription is valid to June 21, 2020. I suspect updates from yesterday, which included...

Yes, I discovered as much after I posted. :) Nominal security -- to terminate idle connections. Basically users who connect and then walk away, forgetting they are connected.

How do I shorten the idle timeout for the web browser interface? My understanding is the interface is controlled by pveproxy and the default idle timeout is 2 hours. I presume a brute force way to terminate an idle session is manually restart the pveproxy service. Thanks again. :)

Ah, so I was not missing anything obvious. :) Perhaps I misunderstand, but many users do not use clusters. Just nodes.

I hope I am missing the obvious. I looked through the wiki and admin manual Does Proxmox log configuration changes to guest systems? If so, where? For example, if I change the allocated RAM or CPU cores, does that change show up in any logs? Thanks again. :)

Nothing useful to post. The last two reboots did not hang for the infamous 30 minutes. A traditional swap partition created by the Proxmox installer. We don't use ZFS. The frustrating part now is I am "gun shy." I've been bitten three times by the 30 minute hang and am now reluctant to reboot...

Thank you! I disabled the three services. So far no noticeable problems. :)

Proxmox 5.4, fully updated, kernel: 4.15.18-12. We do not use OOB or clustering. pveversion output below. We have a Proxmox system that about every other reboot hangs at the "Reached target Reboot" stdout message. Left unattended, on a full-fledged hang the system finally reboots at about 30...

Wolfgang, Related to the OP's original question, which services can be disabled when not using clustering? I realize letting the related clustering services run causes no harm, but nonetheless, which services can be disabled? I'm guessing corosync.service, pve-ha-crm.service, and...