Router deadlock on reboot

For Developers
1

Router in the state not responding to the ethernet and even console. After looking into logs, I see that before router deadlocked it executed two scripts almost simultaneously:

script 1: “reboot” (the first in the order)

script 2: “ifdown internet; sleep 1; ifup internet” (second, in 2 ms after script 1)

The command list above is simplified; the actual scripts have more commands and diag output into the file (and btw hangup may happen in those logging I/O operations too). The “reboot”” script finished “before” “if” script logged finish. What I can certainly say that ifdown has completed, but no info if ifup has started (no respective log entries - but this may happen because of volumes were unmounted).

Last syslog records on the mounted volume (not root fs) are:

Sat Apr 11 01:18:40 2026 authpriv.info dropbear[3008]: Early exit: Terminated by signal
Sat Apr 11 01:18:40 2026 daemon.notice netifd: internet (20766): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "internet" } (Permission denied)
Sat Apr 11 01:18:40 2026 daemon.notice netifd: Interface 'internet' is now down

I have tried to run

reboot & { ifdown internet; sleep 1; ifup internet; } &

several times but did not achieve to reproduce the case.

I also tried running those full scripts with logging several times in same manner, unable to reproduce. System reboots and gets up.

This programmatic design is relatively old, and must have happened before, and this is first time I have got deadlock (bad coincidence of something?).

I have no idea what exactly have caused the issue (not enough info logged) but decided to ask here.

  1. Do you have any idea what may have happened? Or: may what I explain be the cause of deadlock, or I am certainly looking into the wrong place?
  2. Any advice how to prevent this deadlock - because resolving it requires physical access to router to power cycle it. The first thing comes to my mind is in any of these scripts create lock file, with reboot script not removing the lock file at all (because ifdown/ifup won’t matter anymore). Better ideas?

Edit: another, better questions I (almost) never thought about.

  • What is the right way to perform reboot? I recall some time ago playing with it if you do not let script with reboot command to finish, reboot does not happen: e.g. something like “reboot; while true; do sleep 1; done” just hangs the script without reboot happening and thus system deadlocks if in single-user mode (e.g. in system initialization scripts).
  • How asynchronous is it?
  • Is there any way to prepare system for issuing reboot to ensure new (user) processes are not allowed to be spawned and resource grabbing prevented at the time I issue reboot command?
2

reboot definitely takes a while to finish. I will normally do reboot ; sleep 99d to ensure I do not continue executing while reboot is happening.

Can you separate when the two events happen, using sleep or tweaking the time on a cron job?

3

It would help to know what OpenWrt release you are running and on what type of device. I am aware of at least one actual deadlock that was fixed in 25.12, but it was specific to a particular Ethernet device, and I'm not sure it would trigger on shutdown unless it was triggered while the system was still starting up.

That being said, are you sure it's a deadlock vs just a hang? "deadlock" has specific meaning in this context and hangs can happen for a variety of other reasons. The reason I ask is because deadlocks have specific things that can be done to debug them, but unknown hangs could be pretty much anything.

To answer some of your questions about the reboot command: reboot itself has some options, but the default behavior is to sync the filesystem, send a TERM signal to the init process and then exit. For OpenWrt, the init process is procd, which reacts to that signal by doing the following:

  1. reopen the console on its stdio, stdout, and stderr
  2. run all the shutdown (K) scripts in /etc/rc.d, which will, among other things, shut down dropbear, take the network down, and unmount all filesytems (in that order)
  3. kills all remaining processes with TERM signal, then KILL signal
  4. performs the syscall to actually reboot the kernel

#1 may be the reason you observe the console becoming unresponsive. #2 is the reason why reboot won't work if you execute it in an init script and don't ever exit that script, since procd is waiting for that script to exit (or maybe all the init scripts, I'm not sure) before it can go on to run the shutdown scripts. It's also why it's not practical to prevent new processes from running.

If you really need to reboot without letting anything else run, you can do reboot -f, but I really don't recommend it. That will reboot right away without shutting anything down or unmounting filesystems.