kernel: ... sysrq: HELP messages in log

[loeriver]

From time to time I see a message like this in my log files:

 

2025-06-05T11:29:33.367636+02:00 bananapipro2 kernel: [934985.549250] sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z) replay-kernel-logs(R)

 

The system continues to work (although I remember that it stooped at this point in older releases).

 

Is there any action required? I am afraid that this could stop my system which is running unattended for longer periods usually.

 

I am running v25.2.2 for Banana Pi Pro running Armbian Linux 6.12.20-current-sunxi.

[IBV]

Hi,

 

it looks like you or a process is triggering the SysRq key.

For example, If I press Alt + PrtSc (SysRq) + h, I see the same message in dmesg.

 

https://en.wikipedia.org/wiki/Magic_SysRq_key

 

[djurny]

Hi @loeriver,

Check your serial console, as sending a serial <BRK> will trigger the Magic Sysrq sequence.

For example, using `tio` to connect to a serial console, I can invoke the Magic Sysrq help test with <ctrl>-t + B + <enter>.

Perhaps your serial port has it's RX line shorted to ground?

Groetjes,

[loeriver]

Hi,

thank you for your comments, at least I learned about the SysRq sequence this way.

 

I actually have no clue which process should send this sequence, an hardware issue of the RX line seems also unlikely to me (very short wire to the RS232-USB converter).

 

The only additional observations:

 

-it is a rare event, 24x7 system, most recent events:

• Jun 9th: at the end of a shutdown sequence
• Jun, 5th: no obviously related entries in syslog before it
• May, 28th: no obviously related entries in syslog before it
• May, 24th: at the end of a shutdown sequence
• May, 23rd: at the end of a shutdown sequence
• May 22nd: at the end of a shutdown sequence

-it always occurs in pairs, timestamps separated by some µs, e.g. 16:50:49.191219 and 16:50:49.191355

 

Meanwhile on v25.5.1 for Banana Pi Pro running Armbian Linux 6.12.30-current-sunxi.

 

I guess I will have to live with this effect, which is not harmful as long as the system continues to run.

 

Greetings.

[IBV]

You could try to install auditd and check what it says when the event appears. Maybe it will tell you which process is sending the event:

$ sudo apt install auditd
$ sudo auditctl -w /proc/sysrq-trigger -p w -k sysrq_watch

The second command is creating a watch on sysrq-trigger for write events, called sysrq_watch.

You can query check this watch with:

$ sudo ausearch -k sysrq_watch

See what you can find when you detect another trigger of the sysrq key.

[loeriver]

Thank you for this very helpful hint. I have installed auditd, I thought I have to systemctl (start, enable) auditd also to have it watching: but this seems to have been done by the install cmd already, as it is running.

 

As I saw a burst of  7225 (!) sysrq messages in the log for 2025-06-18, between 08:55 and 09:50 again I am rather nervous about this topic. Since then no new messages again. Mysterious ...

 

Greetings.

[djurny]

Hi Loeriver,

Where is the other end of your USB serial dongle connected to? Can you check there if the dongle had disappeard from the USB bus and re-appeared around the same time?

In my "professional" life we have had workstations mysteriously reboot whenever we would power cycle the device hosting the USB to serial device.

Even though you say it's not related, if this is still mysterious, best to check under each stone...

Groetjes,

[loeriver]

Hi and thank you for the advice. 

The USB end of the dongle goes to my desktop PC. I compared the time stamps of the last issue and found that the PC was actually switched off during the last issue, having been switched on 10 minutes after the last sysrq log entry.

 

So for the moment I will watch the findings of auditd, although the startup msgs from yesterday looked somewhat suspicious (?):

 

2025-06-23T18:23:09.799581+02:00 bananapipro2 systemd[1]: Starting auditd.service - Security Auditing Service...
2025-06-23T18:23:09.910646+02:00 bananapipro2 auditd[18408]: Audit daemon is low on disk space for logging
2025-06-23T18:23:09.911684+02:00 bananapipro2 auditd[18408]: Audit daemon is suspending logging due to low disk space.
2025-06-23T18:23:09.912308+02:00 bananapipro2 auditd[18408]: No plugins found, not dispatching events
2025-06-23T18:23:09.917468+02:00 bananapipro2 auditd[18408]: Init complete, auditd 3.0.9 listening for events (startup state enable)
2025-06-23T18:23:10.181350+02:00 bananapipro2 systemd[1]: Started auditd.service - Security Auditing Service.

 

Greetings.

[IBV]

15 hours ago, loeriver said:

2025-06-23T18:23:09.910646+02:00 bananapipro2 auditd[18408]: Audit daemon is low on disk space for logging
2025-06-23T18:23:09.911684+02:00 bananapipro2 auditd[18408]: Audit daemon is suspending logging due to low disk space.

You need to check the disk space, apparently you are out of space and the daemon is not logging.

[loeriver]

Thank you - I should have checked w/ df. The reason is that /var/log is mapped to /dev/zram1 which is 47M for my system and auditd.conf requested space_left=75 (MiB, that is). I changed this to space_left=25% and admin_space_left=5%. No it starts to log something at least.