У меня была та же проблема после многократного извлечения/подключения диска к одной VM. Спасибо, inetshell, эта команда решила проблему, поэтому было бы неплохо отметить эту тему как решенную.

Такая же проблема здесь. Есть какие-нибудь новости?

Что я сделал, чтобы "починить" проблему, это изменил файл /etc/lvm/lvm.conf. Нашел строку "obtain_device_list_from_udev" и изменил её с 1 на 0. Перезагружать не потребовалось. После этого изменения все операции с LVM, кажется, снова работают (пока что небольшой тест). Не уверен, насколько это безопасно, но это точно лучше, чем вручную запускать "udevadm trigger" каждый раз, когда какие-то операции с LVM зависали (даже простые, вроде запуска lvscan или vgscan).

Okay, let's break down these kernel hang reports and figure out what's likely happening in your system.

**Overall Situation**

You're experiencing kernel hangs (tasks blocked for extended periods, exceeding the timeout configured, typically 120 seconds).  The system isn't completely unresponsive – the kernel continues to run, but these specific tasks are stuck.  You've got *two* different tasks showing this behavior:

1.  `systemd-udevd`: This task is related to device management and hotplugging (adding/removing devices).
2.  `systemd-journald`:  This task is responsible for handling and storing system logs.

**Analyzing the First Hang: `systemd-udevd`**

*   **`schedule_preempt_disabled + 0xe/0x10`:** This is a significant clue.  It indicates that the task is waiting inside a critical section where preemption (allowing another task to run) is temporarily disabled.  This suggests that a lock is being held for a long time.
*   **`mutex_lock + 0x2c/0x30` and surrounding lines:**  These lines confirm the lock contention.  `mutex` stands for "mutual exclusion," a mechanism to protect shared resources from concurrent access.  The task is trying to acquire a mutex but is blocked because another task already holds it.
*   **`blkdev_get + 0xe0/0x140` and related lines:** This points to a problem related to accessing block devices (hard drives, SSDs, etc.). The `udev` daemon often needs to query block device information during device hotplug events. The fact that the task is blocked acquiring the block device suggests that there's a potential issue with the device itself, the device driver, or the communication between them.
*   **`do_sys_open + 0x177/0x280` and `__x64_sys_openat + 0x20/0x30`**:  This suggests that the udev daemon may be attempting to open a file, which is also blocked.

**Analyzing the Second Hang: `systemd-journald`**

*  `systemd-journald` hangs usually result from I/O issues when trying to write logs to storage, often to a network share or disk.  The stack trace suggests an issue with block I/O.

**Probable Causes and Troubleshooting Steps**

Based on these hangs, here's a prioritized list of potential causes and troubleshooting steps:

1.  **Storage I/O Problems (Most Likely)**:
   *   **Disk/SSD Health:** Run SMART (Self-Monitoring, Analysis, and Reporting Technology) tests on your hard drives/SSDs.  Many tools are available, such as `smartctl` (part of the `smartmontools` package on Linux).  Look for reallocated sectors, pending sectors, or other errors.
   *   **Network Share Issues (if applicable):** If your system is logging to a network share (e.g., NFS, Samba), verify network connectivity, share permissions, and disk space on the share server. Slow or unreliable network access will cause `journald` to hang.
   *   **Disk Contention:**  If multiple processes are heavily accessing the same disks, it could lead to contention and delays. Look for processes using excessive disk I/O using tools like `iotop`.
   *   **RAID Configuration:**  If you have a RAID array, check the RAID controller health, and that it is not experiencing errors.
   *   **Filesystem Corruption:** While less common, filesystem errors can interfere with I/O. Run `fsck` on your filesystems (boot offline first if necessary).

2.  **Device Driver Issues:**
   *   **Recent Driver Updates:** Did you recently update any device drivers (especially storage controllers or disk drivers)?  If so, try reverting to older drivers.
   *   **Driver Bugs:**  It's possible there's a bug in a device driver. Search online for known issues with your specific hardware and kernel version.

3.  **System Load / Resource Starvation:**
   *   **CPU, Memory:** While less probable with these specific traces, check CPU usage and memory usage.  If the system is consistently overloaded, it could indirectly contribute to delays.  Use tools like `top`, `htop`, or `free`.

4. **udev Rules:**
  *   Examine your `/etc/udev/rules.d/` directory for any custom rules. There may be a rule that is stuck in a loop or has a long-running operation, which is blocking the udev daemon.


**Tools and Commands**

*   `smartctl` (from `smartmontools`):  Check disk health.  (Example: `sudo smartctl -a /dev/sda`)
*   `iotop`: Monitor disk I/O usage per process.  (Requires root privileges)
*   `top`, `htop`: Overall system resource usage.
*   `dmesg`: Kernel log messages, which may contain error messages related to device drivers.
*   `journalctl`: System journal (alternative to `systemd-journald`).

**Debugging Steps:**

1.  **Check Disk Health First:** Start with `smartctl` on your disks.
2.  **Monitor I/O:** Use `iotop` to see which processes are generating the most disk activity.
3.  **Examine `dmesg`:** Look for any error messages related to disks or drivers.
4.  **Simplify udev rules (temporarily):**  Disable or comment out non-essential udev rules to see if that resolves the issue.

**Important Considerations:**

*   **Kernel Version:**  The kernel version (5.3.18-2-pve) is relatively old.  Consider upgrading to a newer, more stable kernel if possible. Newer kernels often contain bug fixes and improved driver support.
*   **System Configuration:** Provide more details about your system. What hardware are you using (especially storage controllers and disks)?  What operating system distribution are you running?  Are you using a virtual machine?
*   **Reproducibility:** Can you reliably reproduce these hangs? If so, that will make debugging much easier.



Let me know the results of your initial checks, especially the SMART status of your drives. The more information you can provide, the better I can help you diagnose the problem.

Вы запускать эту команду нужно только тогда, когда копирование/перемещение файлов почти завершено, где-то на 96 или 98%. Можно еще и udev в lvm.conf отключить, как описано выше, но помните, что я это особо не тестировал, поэтому не могу сказать, вызовет ли это какие-то проблемы или нет (то есть, не делайте так на продуктивных серверах). Пока что вручную запускать udevadm trigger на последнем этапе должно помочь.

PVE 6.2-4. Переход с HDD на SSD – та же проблема. Предупреждения были те же самые. admtrigger udev на 98%/99% сработал для меня. Спасибо за этот обходной путь.

У меня то же самое после обновления, но только при миграции с узла, который еще не обновлен, на обновленный. Команда udevadm trigger работает у меня. Пока что проблем нет при миграции между узлами с одинаковой "версией". Кстати, я столкнулся с этой проблемой во время обновления двух узлов из пяти во время "генерации Grub", и команда udevadm trigger тоже решила ее. Спасибо.

Тебе нужно выполнить команду udevadm trigger примерно на 98%, иначе она не сработает. Проблема возникает примерно на отметке в 95%. К этому моменту вся подсистема LVM перестаёт работать. Команды вроде lvdisplay и т.д. будут зависать. Запусти udevadm trigger, и LVM снова заработает. А когда LVM работает, работает и Proxmox ops. Можно отключить зависимость LVM от UDEV, обратившись к посту #9…