[Solved] anything in base that automatically reboots the system?

[GNUser]

My home wireless router is a repurposed 64-bit laptop running TCL13. The other day my wife lost wifi connection in the middle of an online class. When the issue came to my attention, everything seemed fine but when I SSH'd into the router I saw that, based on output of the  uptime  command, the router had rebooted in the middle of her class.

An unexpected reboot happened at least one more time since then: I rebooted the router approximately 72 hours ago, but when I SSH into the router and run  uptime  I get only 19 hours of uptime.

I have very few extensions loaded on the router (forum error, see attached), so I doubt an extension is rebooting the system without my knowledge.

SSH password authentication is disabled (keypair authentication is required) and only my user (user "bruno") is allowed to SSH into the router, so someone/something from the internet rebooting my router without my permission seems highly unlikely.

Is there anything in TCL base that automatically reboots the system? Can you think of any other explanation for unexpected reboots?

[tacpilot]

My guess would be hardware issue, but just in case
look at the TC logs for any info gleaned just before shutdown.

Other than TC,
I would make sure the fans and heat sinks are clear of lint and
fans spinning. look in the bios for any timers or power/thermal
state action setting or any NIC controls that may be present.

If the laptop is old and the internal battery is shot and you are
running it solely off its power supply make sure all the connections
to the power supply are secure and/or is not failing to where it may
be glitching off for a blink with bios set to auto reboot on power failure.

[GNUser]

Hi, tacpilot. Thanks for the input.

Hardware failure is a good idea. The laptop is always connected to power adapter but it does still have its original (old and low capacity) battery. I would expect a hardware or power issue to lead to a poweroff rather than a reboot, but I will replace the battery just in case.

Checking TC log entries might be more difficult because only my /opt directory is persistent, so I would expect any log entries from a previous reboot command to have been lost.

This morning I remastered the base system (corepure64.gz) and deleted /sbin/reboot and /sbin/halt (which are just links to busybox). Now the only way to reboot is to run "busybox reboot" as root (or with sudo). If an intruder or misbehaving daemon just runs "reboot" or "halt", then they will actually be running shell scripts that I wrote and that will log a bunch of things to my persistent /opt directory. Hehehe.

[tacpilot]

You may also look at bios power settings to see if you can set it to stay off on  power failure.
This way if intermittent power is the issue .., then the system will just stay off ..
This may help narrowing it to hardware and not some reboot option.

[curaga]

A kernel panic would reboot in one minute by default (configurable), but power loss sounds more likely.

[Rich]

Hi GNUser
Before replacing the battery, yank the power cord. If the battery keeps the laptop running for 15-20 minutes, you can save the expense
of replacing it for the time being.

I'm not aware of anything in Tinycore that would reboot the system, unless maybe a cron job was setup to do that.
You could also look into redirecting/forwarding  syslog  and/or  dmesg  messages to a persistent file or another machine through your LAN.

[GNUser]

Thank you all for the valuable insights!

Rich, I will test the battery as you suggested before investing in a replacement.

Curaga, I didn't realize a kernel panic would trigger a reboot. This is very good to know. Are kernel panics logged? If so, where to? Perhaps I could create a persistent symlink (via mydata.tgz) from log's normal location to a file in my persistent /opt.

[tacpilot]

A kernel panic would reboot in one minute by default (configurable), but power loss sounds more likely.

Thermal issues due to failing fans and/or clogged heat sinks and/or failing thermal pad/compound
can possibly cause kernel panic when components start reaching their thermal limits.

[Rich]

Hi GNUser
I'm certain kernel panics are logged in dmesg. I'm pretty sure they would also show up in syslog.

Code: [Select]

tc@E310:~/Scripting/RecordScan$ syslogd --help
BusyBox v1.29.3 (2018-12-19 15:29:37 UTC) multi-call binary.

Usage: syslogd [OPTIONS]

System logging utility
(this version of syslogd ignores /etc/syslog.conf)

        -n              Run in foreground
        -R HOST[:PORT]  Log to HOST:PORT (default PORT:514)
        -L              Log locally and via network (default is network only if -R)
        -C[size_kb]     Log to shared mem buffer (use logread to read it)
        -O FILE         Log to FILE
        -s SIZE         Max size (KB) before rotation (default 200KB, 0=off)
        -b N            N rotated logs to keep (default 1, max 99, 0=purge)
        -l N            Log only messages more urgent than prio N (1-8)
        -S              Smaller output
        -D              Drop duplicates
tc@E310:~/Scripting/RecordScan$
Maybe you could start syslog something like this to catch what happens:

Code: [Select]

syslogd -D -s 0 -O /opt/`date +"%Y%m%d%H%M%S"`.logThat will create a log file whose name is a timestamps of when  syslogd  started in your persistent directory.
It will also create a new log file on every restart.

Note:
    Those are  backticks  found on the  ~  key around the date command, not single quotes.

[GNUser]

That's a great idea, Rich. I've removed  syslog  from my boot commands. Going forward I'll start  syslog  using the command you suggested (as a line in /opt/bootlocal.sh).

This problem is all but solved. If it's a battery issue, I'll know later today when I do some tests. If it's an unauthorized reboot from a rogue daemon or an SSH intruder, it will get logged. If it's a kernel panic it will get logged.

If I discover anything interesting I'll update the thread. Thank you all.

[GNUser]

A quick update: The laptop's battery is so old that it holds no charge whatsoever. However, it is not responsible for the unexpected reboots.

When I yank the power cord, laptop dies immediately. Quickly plugging it back in does not cause laptop to turn back on. So it seems that a brief power failure would cause a poweroff, not a reboot.

So, concerning the unexpected rebbots, it seems I've narrowed the list of suspects to occasional kernel panics, a background process, or (less likely) an SSH intruder.

[gadget42]

...
So, concerning the unexpected reboots, it seems I've narrowed the list of suspects to occasional kernel panics, a background process, or (less likely) an SSH intruder.

don't rule out hardware issues. have had both laptops and desktops that developed "sudden shutdown and/or reboot syndrome" at varying equipment ages. sometimes the condition was solved by a thorough cleaning(down to a stripped motherboard-level wash) and reassembling(naturally this involves what some describe as "reseating" the board-level cards/modules/sub-assemblies/etc) but occasionally the condition remained a mystery as it becomes impractical to troubleshoot to the smc level.

thermal issues have been covered ad nauseam since bbs days so that should be a no-brainer.

hey, great repurposing nevertheless! kudos!

[CNK]

If it's caused by kernel panics and not associated with any recent software changes, I'd expect that to be caused by a hardware fault.

I'd run Memtest86 to see whether the RAM might be getting dodgy. It could equally be the CPU, or in my experience it's most often the chipset in which case what's failed will be some soldered-on chip that you can't replace. Though you'll have to swap the CPU to be sure of that last one.

[patrikg]

If you look at the bios in the computer, some bios support the power on feature when power comes back in the cord.

[Rich]

Hi patrikg
That has already been ruled out:

... When I yank the power cord, laptop dies immediately. Quickly plugging it back in does not cause laptop to turn back on. ...