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.

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

 

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,

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.

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.

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.

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,

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.

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.

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.

Hi,

that's me again after a recent very bad sysrq incident on my system (I was away for a couple of days and the system went down for this time).

 

I count > 5000 "sysrq: HELP" messages  this time, 77 requests for loglevel changes (to 0, 4 or 8), 9 "show regs" requests, 1  "show state" and 4 "dump ftrace buffer" request. All this during 30 mins.

 

The UART / USB converter was connected to ttyS0, but the PC on the other end was off.

 

But I shall add that I also have connected the status output line of my UPS to ttyS1 (this is an "UPSPACK_V3" board that watches the 5V input and has a Li polymer battery connected). 

 

Could it also be that this system sends spurious BREAK commands that issue a SysRq event? And if yes: Is there a simple way to watch this interface? Maybe by temporarily logging the UPS board's UART Tx?    

 

Greetings.

Was the auditd disabled ?  Without it is difficult to see where the sysrq comes from.

 

Re. monitoring ttyS1: you could try use screen:

 

sudo screen /dev/ttyS1 9600

 

Replace 9500 if needed with the baud rate configured in the UPS

Hi @loeriver,

Yes, it depends a bit on what brand/type and how you connect the USB to serial converter. The ones i use to monitor the serial console on all my SBCs have these spurious events as well, even when I do not connect the +5Vdc on the serial/UART end. For me they are sometimes preventing a full board shutdown as they seem to leach power to the SBC (not sure how this is happening electrically, perhaps some pull-ups allowing current to flow from RX into the Vcc of the board?).

You could try to remove the dongle from the system to see if that has any effect to rule this out completely.

Groetjes,

Hi,

just to give a maybe final feedback on this topic: Although it is not a really satisfying solution, I decided to switch off the sysrq functionality by setting kernel.sysrq=0 in /etc/sysctl.conf.

 

This was 1 month ago and there were no sysrq events in my logs since then. So for now this is a "good enough" solution for me.

 

Thank you all for your support, I learned again a lot ...