PHP-FPM processes hang in UFS-state

[Konstantin Belousov]

On Sat, Oct 24, 2020 at 09:40:09PM +0300, Christos Chatzaras wrote:
> 
> 
> > On 24 Oct 2020, at 21:13, Konstantin Belousov <kostikbel at gmail.com> wrote:
> > I do not remember about 12.1.  I certainly not aware of anything in 12.2.
> > Quota is less tested than non-quota.  One of the backtraces in your dump
> > indicates that a quota file lock was preventing other thread to make a
> > progress.
> 
> Can you tell me where I see this file lock about quota? I search https://www.coderz.gr/ufs/procstat.txt <https://www.coderz.gr/ufs/procstat.txt> and didn't find it.

   30 100097 syncer              -                   mi_switch+0xe2 sleepq_wait+0x2c sleeplk+0x185 lockmgr_xlock_hard+0x1f5 __lockmgr_args+0x2bf ffs_lock+0xa5 VOP_LOCK1_APV+0x7c _vn_lock+0x44 vget+0x4a qsync+0x99 ffs_sync+0x7d5 sync_fsync+0x10f VOP_FSYNC_APV+0x7c sched_sync+0x379 fork_exit+0x83 fork_trampoline+0xe

> 
> 
> Also "10.6. Debugging Deadlocks" write "The recipe below is especially useful if you suspect that a deadlock occurs in the VFS layer. Add these options to the kernel configuration file.".  Do I have to compile new kernel with these options enabled or I can try with my GENERIC kernel?
> 
> If I understand correctly because the system doesn't panic but keeps running I have to make it panic using "sysctl debug.kdb.panic=1" to create the core dump. Then after the system boots I run "kgdb /boot/kernel/kernel /var/crash/vmcore.0". Then I run the commands described in "10.6. Debugging Deadlocks". Am I right?

No, the commands are for ddb.