Project

General

Profile

Actions

Bug #1214

closed

Ironman launcher locking up over time

Added by Hammel 7 months ago. Updated 17 days ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
General
Target version:
Start date:
07 May 2025
Due date:
% Done:

100%

Estimated time:
Severity:
01 - Critical

Description

This might be due to logs filling up /tmp.
If not that, get libleak to work on Pibox and use it to check for leaks.


Related issues

Related to PiBox - Feature #1215: Create a package for libleak and remote loggingClosedHammel12 May 2025

Actions
Blocked by PiBox - Feature #1217: Utilize latest features of BuildrootClosedHammel28 Jul 2025

Actions
Actions #1

Updated by Hammel 7 months ago

Once remote logging is enabled by .opkg package, use piboxLoggerSetFlags(LOG_F_SYSLOG) to route logs to remote log host.

This can be used in launcher and any other app that uses libpibox:log. It should be added as an command line option.

Actions #2

Updated by Hammel 7 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10
Actions #3

Updated by Hammel 7 months ago

There are only 4 PiBox/Ironman apps running that might cause this:

  • piboxd
  • imrest
  • appmgr
  • launcher

imrest seems the most likely candidate, but all of them should probably tested for leaks.

Actions #4

Updated by Hammel 3 months ago

  • Blocked by Feature #1217: Utilize latest features of Buildroot added
Actions #5

Updated by Hammel 3 months ago

I need libleak added as a package (RM #1215), but that can't happen until I finish updating Buildroot to utilize some new features (RM #1217).

Actions #6

Updated by Hammel about 1 month ago

Note: UI lockup occurred two days ago as shown by date/time field. Verified ssh does not work either.
Remote logging would need to be enabled manually. There is no opkg for this.

Logging setup:
  • piboxd: off
  • imrest: off
  • appmgr: on
  • launcher: on

Retesting with appmgr and launcher logging on. Will revisit daily to check on size of logs.

Note:

Logs after boot:

$ ls -l /tmp/
-rw-r--r--    1 root     root           965 Dec 31  1969 appmgr.log
-rw-r--r--    1 nobody   nobody       23065 Nov  3 17:53 launcher.log

Logs after a few minutes:

)$ ls -l /tmp/
-rw-r--r--    1 root     root           965 Dec 31  1969 appmgr.log
-rw-r--r--    1 nobody   nobody       60271 Nov  3 17:55 launcher.log

So launcher could definitely be filling up tmp space.

Actions #7

Updated by Hammel about 1 month ago

  • Related to Feature #1215: Create a package for libleak and remote logging added
Actions #8

Updated by Hammel 17 days ago

  • Status changed from In Progress to Closed
  • % Done changed from 10 to 100

It a couple of weeks, but with the logs enabled for launcher the /tmp directory eventually filled to 100% and then the system locked up.
So this could be handled by the following.

  1. Force logging into /media/data/logs
  2. Enable a log rotation that prevents logs from getting too large.

But that's not really necessary because the logging is for debugging only and isn't a runtime issue. So just remember to turn off debugging and all will be fine.

Closing issue without any updates.

Actions

Also available in: Atom PDF