Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

libbpf-tools/sigsnoop : reporting signal number '17' for all signal sent by kill utility. #5057

Open
devidasjadhav opened this issue Jul 8, 2024 · 4 comments

Comments

@devidasjadhav
Copy link
Contributor

to test a PR I used sigsnoop with kill utility.
got signal value 17.
So I reverted that patch.
same result.

so I added bpf_printk and verified that value.

it was 17 even with bpf_printk.

Value in ctx-sig. is 17.

I am using Debian 11 with 6.1.0-11-amd64 kernel.

Steps to reproduce.

  1. run sigsnoop with pid. i.e ./sigsnoop -p 1234
  2. kill -n 19 1234
  3. kill -n 18 1234
  4. verify output of sigsnoop
TIME     PID     COMM             SIG       TPID    RESULT
22:56:55 50918   a.py             17        30434   0
22:56:59 50918   a.py             17        30434   0

@devidasjadhav
Copy link
Contributor Author

even tracepoint from tracefs shows same.
echo 1 > /sys/kernel/tracing/events/signal/signal_generate/enable

          sh-72340   [003] dN.2.  9457.683068: signal_generate: sig=17 errno=0 code=1 comm=python pid=1258 grp=1 res=1
        grep-72348   [002] dN.2.  9458.691583: signal_generate: sig=17 errno=0 code=1 comm=sh pid=72347 grp=1 res=0
          sh-72347   [004] dN.2.  9458.692029: signal_generate: sig=17 errno=0 code=1 comm=python pid=1258 grp=1 res=1
         cat-72352   [001] dN.2.  9459.257847: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72351 grp=1 res=0
        grep-72353   [003] dN.2.  9459.258953: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72351 grp=1 res=2
          wc-72354   [005] dN.2.  9459.259009: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72351 grp=1 res=2
        bash-72351   [004] dN.2.  9459.259594: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72350 grp=1 res=0
        expr-72355   [001] dN.2.  9459.263742: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72350 grp=1 res=0
        expr-72356   [003] dN.2.  9459.267340: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72350 grp=1 res=0
        expr-72357   [002] dN.2.  9459.270904: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72350 grp=1 res=0
        expr-72358   [003] dN.2.  9459.274404: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72350 grp=1 res=0
        expr-72359   [002] dN.2.  9459.277936: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72350 grp=1 res=0
        expr-72360   [003] dN.2.  9459.281515: signal_generate: sig=17 errno=0 code=1 comm=bash pid=72350 grp=1 res=0
        bash-72350   [005] dN.2.  9459.282323: signal_generate: sig=17 errno=0 code=1 comm=sh pid=72349 grp=1 res=0
          sh-72349   [003] dN.2.  9459.282712: signal_generate: sig=17 errno=0 code=1 comm=python pid=1258 grp=1 res=1

@devidasjadhav
Copy link
Contributor Author

surprisingly with -k its working fine.

So Now in my setup tracepoint version of code is not performing as expected.

Can @chenhengqi please verify if its working in your setup ?

@ZhangYet
Copy link
Contributor

ZhangYet commented Jul 29, 2024

Could I ask what platform you used to discover this problem?

I reproduced this on X86 vm by kill -19 pid, but saw nothing when kill -18 pid.

BTW I don't think this is a bug, just something we haven't understood in kernel.

And -k changed the probed function:

  1. with -k, sigsnoop traces some kill functions.
  2. without -k, sigsnoop traces trace_signal_generate.

@ZhangYet
Copy link
Contributor

I'm working on x86 platform.

// include/uapi/asm/signal.h
#define SIGCHLD		17
#define SIGCONT		18
#define SIGSTOP		19

And

// include/linux/signal.h
 *	|  SIGCHLD           |	ignore   	|
 *	|  SIGCONT           |	ignore(*)	|
 *	|  SIGSTOP           |	stop(*)(+)  	|

So when I test kill -18 {pid}, sigsnoop doesn't catch anything.

When I kill -19 {pid}, the process {pid} is stopped. When the process {pid} is stopped, it will call system call exit, in which calls exit_signals.

exit_signals-> do_notify_parent_cldstop -> __group_send_sig_info(SIGCHLD, &info, parent) -> send_signal.

syscall kill won't be called in this procedure, that's why you can catch SIGCHLD(17) without -k.

I'm using a 5.15 kernel.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants