Android app support doesn't start after long uptime

ziellos · 27 November 2023 18:53

Again, after 25 days of uptime Android app support refuses to start.

     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
     1    32 days, 16:12:59 | Linux 4.19.188            Tue Dec 27 19:35:05 2022
     2    25 days, 16:18:35 | Linux 4.19.248            Wed Jul 12 14:47:01 2023
     3    25 days, 15:25:44 | Linux 4.19.248            Tue Sep 12 17:24:32 2023
->   4    25 days, 08:52:21 | Linux 4.19.248            Thu Nov  2 11:02:32 2023
     5    25 days, 03:11:28 | Linux 4.19.248            Sun Oct  8 08:50:43 2023
     6    25 days, 00:35:38 | Linux 4.19.248            Fri Jun  2 06:50:42 2023
     7    24 days, 23:32:13 | Linux 4.19.248            Mon May  8 07:18:02 2023
     8    24 days, 22:46:56 | Linux 4.19.248            Thu Apr 13 08:30:38 2023
     9    23 days, 03:53:04 | Linux 4.19.248            Sat Feb 25 10:35:06 2023
    10    12 days, 16:09:11 | Linux 4.19.248            Fri Mar 31 16:21:00 2023
----------------------------+---------------------------------------------------
1up in     0 days, 06:33:24 | at                        Tue Nov 28 02:28:17 2023
no1 in     7 days, 07:20:39 | at                        Tue Dec  5 03:15:32 2023
    up   336 days, 18:20:53 | since                     Sun Dec 25 17:03:50 2022
  down     0 days, 08:30:10 | since                     Sun Dec 25 17:03:50 2022
   %up               99.895 | since                     Sun Dec 25 17:03:50 2022

direc85 · 27 November 2023 21:23

Thank you for one more data point around the ~25 day mark!

I did a few quick calculations, it went like this

25 days in milliseconds → 2,160,000,000
Wait, what was uint32_max? → 4,294,967,295
Okay, what is int32_max? → 2,147,483,647
What’s int32_max milliseconds in days? → 24.855… days → close enough?

emva · 27 November 2023 22:10

Some days ago I was watching Stand-up Maths - Help, our train home is making 9 quintillion stops.

You might be on to something.

nas · 1 December 2023 14:21

@ziellos how did you get this “report” ??

Guys I am at day 14 and 1h uptime, means at 11 December I will reach 25 days of uptime. Is there anything I can do to help around the “target” day? Collect any logs / run any test etc ? let me know! Since this seems to happen once every 25 days we should grab any chance for debugging!

ziellos · 1 December 2023 14:46

This is the output of the uprecords utility, which is part of the uptimed package.

kan_ibal · 26 December 2023 08:26

I have met the same issue and logs but unfortunately restarting the phone doesn’t help.
Is there anything else I can do about this?

thigg · 26 December 2023 08:42

Did you hit it on 11th december?

thigg · 26 December 2023 08:48

This might be another issue if rebooting doesn’t help you can collect logs.
This wiki page should have the proper commands on it Testing Advice | Sailfish OS Documentation

You’ll want logcat for logs from inside android and devel-su journalctl for the sfos side

kan_ibal · 26 December 2023 11:04

Might be another but logs look very similar.
Since Android Appsupport doesn’t work at all a Logcat doesn’t work as well.

Additional information:

[root@Xperia10II system]# systemctl --failed
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION              
● aliendalvik.service          loaded failed failed Alien Dalvik             
● lxc@multi-user.service       loaded failed failed LXC Container: multi-user
● systemd-modules-load.service loaded failed failed Load Kernel Modules

[root@Xperia10II system]# systemctl status systemd-modules-load
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2023-12-26 11:54:25 CET; 13min ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 27908 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
 Main PID: 27908 (code=exited, status=1/FAILURE)

Dec 26 11:54:25 Xperia10II systemd-modules-load[27908]: Failed to lookup alias 'veth': Function not implemented
Dec 26 11:54:25 Xperia10II systemd-modules-load[27908]: Failed to lookup alias 'xt_CHECKSUM': Function not implemented
Dec 26 11:54:25 Xperia10II systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 11:54:25 Xperia10II systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
Dec 26 11:54:25 Xperia10II systemd[1]: Failed to start Load Kernel Modules.
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

[root@Xperia10II system]# systemctl status aliendalvik.service
● aliendalvik.service - Alien Dalvik
   Loaded: loaded (/usr/lib/systemd/system/aliendalvik.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/aliendalvik.service.d
           └─01-prevent-start.conf, 01-user.conf
   Active: failed (Result: protocol) since Tue 2023-12-26 11:59:21 CET; 8min ago
  Process: 29130 ExecStopPost=/usr/libexec/appsupport/stop-aliendalvik.sh (code=exited, status=0/SUCCESS)
  Process: 29081 ExecStart=/usr/libexec/appsupport/start-aliendalvik.sh (code=exited, status=0/SUCCESS)
  Process: 29067 ExecStartPre=/bin/sh -c while ! systemctl-user is-active lipstick.service 1>/dev/null; do sleep 1; done (code=exited, status=0/SUCCESS)
 Main PID: 29081 (code=exited, status=0/SUCCESS)

Dec 26 11:59:20 Xperia10II start-aliendalvik.sh[29081]: lxc-start: aliendalvik: start.c: do_start: 1291 Failed to setup container "aliendalvik"
Dec 26 11:59:20 Xperia10II start-aliendalvik.sh[29081]: lxc-start: aliendalvik: sync.c: sync_wait: 36 An error occurred in another process (expected sequence number 3)
Dec 26 11:59:20 Xperia10II start-aliendalvik.sh[29081]: lxc-start: aliendalvik: start.c: __lxc_start: 2053 Failed to spawn container "aliendalvik"
Dec 26 11:59:20 Xperia10II start-aliendalvik.sh[29081]: lxc-start: aliendalvik: tools/lxc_start.c: main: 308 The container failed to start
Dec 26 11:59:20 Xperia10II start-aliendalvik.sh[29081]: lxc-start: aliendalvik: tools/lxc_start.c: main: 314 Additional information can be obtained by setting the --logfile and --logpriority options
Dec 26 11:59:20 Xperia10II start-aliendalvik.sh[29081]: cat: can't open '/home/.android/data/alien_boot_completed': No such file or directory
Dec 26 11:59:20 Xperia10II stop-aliendalvik.sh[29130]: lxc-attach: aliendalvik: attach.c: get_attach_context: 403 Failed to get init pid
Dec 26 11:59:20 Xperia10II stop-aliendalvik.sh[29130]: lxc-attach: aliendalvik: attach.c: lxc_attach: 1430 Failed to get attach context
Dec 26 11:59:21 Xperia10II systemd[1]: aliendalvik.service: Failed with result 'protocol'.
Dec 26 11:59:21 Xperia10II systemd[1]: Stopped Alien Dalvik.

[root@Xperia10II system]# systemctl status lxc@multi-user.service
● lxc@multi-user.service - LXC Container: multi-user
   Loaded: loaded (/usr/lib/systemd/system/lxc@.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2023-12-26 10:24:51 CET; 1h 42min ago
     Docs: man:lxc-start
           man:lxc
  Process: 5852 ExecStart=/usr/bin/lxc-start -F -n multi-user (code=exited, status=1/FAILURE)
 Main PID: 5852 (code=exited, status=1/FAILURE)

kan_ibal · 6 January 2024 19:09

Does booting a SailfishOS recovery image via fastboot boot may break Android app support?

attah · 6 January 2024 19:55

Why (how!) would it?

kan_ibal · 6 January 2024 20:04

I don’t know but this was the only activity I have done when Android App support stopped working. Now I’m trying to regain /root space but with 790MB free Android App support still doesn’t start with errors as above.

ziellos · 4 February 2024 08:37

The issue happened again today after about 25 days of uptime.
During that period, I completely avoided to restart app support, so the problem is really related to uptime, not to the number of restarts or other interactions.

[defaultuser@Xperia ~]$ uprecords 
     #               Uptime | System                                     Boot up
----------------------------+---------------------------------------------------
     1    32 days, 16:12:59 | Linux 4.19.188            Tue Dec 27 19:35:05 2022
->   2    25 days, 22:23:15 | Linux 4.19.248            Tue Jan  9 11:11:17 2024
     3    25 days, 16:18:35 | Linux 4.19.248            Wed Jul 12 14:47:01 2023
     4    25 days, 15:25:44 | Linux 4.19.248            Tue Sep 12 17:24:32 2023
     5    25 days, 09:36:51 | Linux 4.19.248            Thu Nov  2 11:02:32 2023
     6    25 days, 03:11:28 | Linux 4.19.248            Sun Oct  8 08:50:43 2023
     7    25 days, 00:35:38 | Linux 4.19.248            Fri Jun  2 06:50:42 2023
     8    24 days, 23:32:13 | Linux 4.19.248            Mon May  8 07:18:02 2023
     9    24 days, 22:46:56 | Linux 4.19.248            Thu Apr 13 08:30:38 2023
    10    23 days, 03:53:04 | Linux 4.19.248            Sat Feb 25 10:35:06 2023
----------------------------+---------------------------------------------------
no1 in     6 days, 17:49:45 | at                        Sun Feb 11 03:24:17 2024
    up   405 days, 07:55:04 | since                     Sun Dec 25 17:03:50 2022
  down     0 days, 08:35:38 | since                     Sun Dec 25 17:03:50 2022
   %up               99.912 | since                     Sun Dec 25 17:03:50 2022

nephros · 4 February 2024 09:00

Hm, Windows XP has a max uptime of 49.7 days! That’s twice that!

SCNR.

(and yes, that’s because of an integer overflow.)

Is this related maybe?

github.com/systemd/systemd

RFE: on systems with a 32bit time_t check early on if we can query the system clock, if we cannot with ERANGE (i.e. time_t overflow) revert clock back to compiled in epoch

opened 03:58PM - 01 Nov 22 UTC

pauser0000001

RFE 🎁 pid1

### systemd version the issue has been seen with 251 ### Used distribution Op…enSuse ### Linux kernel version used 5.17 ### CPU architectures issue was seen on i686 ### Component systemd ### Expected behaviour you didn't see The disk structure was right (checked with fsck -f several times) but systemd was unable to mount any partition always saying the same error message: Failed to determine whether /proc (or/ sys or /dev o any other) is a mount point: Value too large for defined data type The only thing that happened is that the internal battery for the laptop clock died and the BIOS got default vaules. ### Unexpected behaviour you saw Failed to determine whether /proc is a mount point: Value too large for defined data type Failed to determine whether /sys is a mount point: Value too large for defined data type Failed to determine whether /dev is a mount point: Value too large for defined data type !!! Failed to mount early API filesystems. Freezing execution. ### Steps to reproduce the problem Remove the internal battery and try to start. ### Additional program output to the terminal or log subsystem illustrating the issue _No response_

ziellos · 4 February 2024 10:45

My wild guess is that’s a similar issue, but somehow related to lxc. Other services may be controlled without problems, Android app support (based on lxc) is the only one affected, at least in my experience.