Call trace:
#0 __lll_lock_wait_private () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007f95c059f9d7 in _L_lock_638 () from /lib64/libc.so.6
#2 0x00007f95c059f8b6 in _nl_expand_alias
#3 0x00007f95c059dad8 in _nl_find_domain
#4 0x00007f95c059d22e in __dcigettext
#5 0x00007f95c059c05f in __GI___dcgettext
#6 0x00000000004032b3 in signal_handler (signo=15) at display.c:54
#7 <signal handler called>
#8 __memcpy_sse2 () at ../sysdeps/x86_64/memcpy.S:104
#9 0x00007f95c05d9934 in __GI__IO_getline_info
#10 0x00007f95c05d99b8 in __GI__IO_getline
#11 0x00007f95c05e2a5d in __GI_fgets_unlocked
#12 0x00007f95c059f478 in read_alias_file
#13 0x00007f95c059f97a in _nl_expand_alias
#14 0x00007f95c059dad8 in _nl_find_domain
#15 0x00007f95c059d22e in __dcigettext
#16 0x00007f95c059c05f in __GI___dcgettext
#17 0x0000000000403a8d in reset_global () at global.c:410
#18 0x0000000000402605 in main at display.c:650
The above call trace happens when the ps process is suspending, and the
signal SIGTERM is sent to the ps process at the same time.
Just cancel the SIGTERM and SIGHUP handler when suspending to prevent
the problem.
Signed-off-by: liutie <liutie4@huawei.com>
Signed-off-by: fu.lin <fulin10@huawei.com>
e9445a07cf