Thanks for the prompt response!
I've attached the requested files, zipped up. There are many ZFS operations resulting in failed: got timeout, mostly if not exclusively occurring during backup jobs.
I routinely get replication job failures between the hosts in my 2-node Proxmox cluster. I have grown accustomed to ignoring them as they always recover on the next run. Is there a way to avoid these failures? I'm thinking of staggering the replication schedule between the two hosts, as they...
List active tasks:
root@host:~# cat /var/log/pve/tasks/active
UPID:host:12345678:90ABCDEF:FEDCBA09:vzclone:133:root@pam: 0
UPID:host:DEADBEEF:FEEDBAC4:09876543:vzsnapshot:133:root@pam: 1 12345678 OK
...
Identify task's "sorting character" - the last digit of the task's unique reference string...
I think I figured this out, thanks to some more searching and finding these posts:
https://www.reddit.com/r/Proxmox/comments/i9xfoj/hotplugging_passthrough_usb_devices_to_lxc/
https://monach.us/automation/connecting-zwave-stick-under-lxc/...
This would modify permissions only for the endpoint that matches the rule spec (SUBSYSTEMS, KERNEL, PID, VID). The Bus/device IDs can change based on where the device is plugged in (or even after a reboot? Not sure), so I'd avoid depending on them. The way I understand the hierarchy is that...
I have two systems with a UPS connected via USB, which I pass-through to an LXC container with the corresponding management software (apcupsd, pwrstatd). However, on both systems, I have a problem if the USB connection is ever disconnected - the LXC container can no longer read the USB...
I think the more typical way to do this is to use udev rules. Or at least that's what I do for my UPS management container. I created the following file:
/etc/udev/rules.d/50-apcups.rules
SUBSYSTEMS=="usb", KERNEL=="hiddev*", ATTRS{idVendor}=="051d", ATTRS{idProduct}=="0002", GROUP="100000"...
I ran into this issue on a backup with multiple disks, which each had the @vzdump snapshot. I was able to delete all of them using:
zfs destroy -r tank@vzdump
Maybe there could be an option to automatically destroy any existing @vzdump snapshot prior to backup. I've had this happen several times.
Got it to work with pve-guests.service, but I did have to add a delay (using ExecStartPre) to give the mail server time to start up. Here's my final config (which successfully delivers mail for both start & shutdown):
[Unit]
Description=Send email at system Start and Stop
Wants=postfix.service...
Another wrench in this is that my mail server may be running in a container on the host, so I would also want to start this systemd service after VMs & containers have started. Which service is that? lxc.service, pve-guests.service?
Looks like in @Stoiko Ivanov 's patch here, pve-cluster is modified to start before the MTA. So, my example above could be changed to only depend on the MTA (postfix)?
Piggy-backing off this thread:
https://forum.proxmox.com/threads/pvemailforward-loses-emails-if-mail-server-is-not-available.108893/post-495825
How should I set up the dependencies for a systemd service to ensure mail delivery during startup & shutdown of the system? From the thread linked...
Glad you were able to reproduce! I'm going to piggy back off this discussion in another thread to answer my other question about how to configure a systemd service to guarantee mail delivery during startup/shutdown (as far as the system dependencies are concerned).
Interesting. So you're saying that if the cluster file system is not available when postfix is started, pvemailforward doesn't know where to forward the mail? That makes sense to me. Can this be fixed simply by returning an error code to postfix?
I've attached the boot log from the journal...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.