From: Paul Eggert <eggert@cs.ucla.edu>
To: Po Lu <luangruo@yahoo.com>
Cc: bug-gnulib@gnu.org
Subject: Re: Android NDK r26 and utmpx
Date: Sat, 20 Jan 2024 19:04:30 -0800 [thread overview]
Message-ID: <2ef0d67a-8ac9-45f5-9544-b8863538d58f@cs.ucla.edu> (raw)
In-Reply-To: <87v87ntq4m.fsf@yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 271 bytes --]
Thanks for reporting that. Would something like the attached Gnulib
patch fix the Android issue?
This patch assumes that readutmp-like functions have never worked on
Android (always report nothing); is that the case?
I haven't installed this, or tested it on Android.
[-- Attachment #2: 0001-readutmp-port-to-Android-NDK-r26.patch --]
[-- Type: text/x-patch, Size: 4793 bytes --]
From 60aa07c1ccd5aa18a9f87997a51acc8507515ef1 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 20 Jan 2024 19:01:12 -0800
Subject: [PATCH] readutmp: port to Android NDK r26
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lib/readutmp.c (read_utmp_from_file) [__ANDROID__]:
Don’t bother trying to read from a real file, as this
has never worked with Android and the useless code
stops working on Android NDK r26.
---
ChangeLog | 8 ++++++++
lib/readutmp.c | 48 ++++++++++++++++++++++++------------------------
2 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index d8d2a13d9e..4533eaceb2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-01-20 Paul Eggert <eggert@cs.ucla.edu>
+
+ readutmp: port to Android NDK r26
+ * lib/readutmp.c (read_utmp_from_file) [__ANDROID__]:
+ Don’t bother trying to read from a real file, as this
+ has never worked with Android and the useless code
+ stops working on Android NDK r26.
+
2024-01-19 Bruno Haible <bruno@clisp.org>
fenv-environment: Fix for NetBSD/powerpc.
diff --git a/lib/readutmp.c b/lib/readutmp.c
index ae2e3ae8c6..59074d68c1 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -330,7 +330,27 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
# if READUTMP_USE_SYSTEMD || HAVE_UTMPX_H || HAVE_UTMP_H
-# if defined UTMP_NAME_FUNCTION /* glibc, musl, macOS, FreeBSD, NetBSD, Minix, AIX, IRIX, Solaris, Cygwin, Android */
+# ifdef __ANDROID__
+ /* On Android, there is no /var, and normal processes don't have access
+ to system files. Therefore use the kernel's uptime counter, although
+ it produces wrong values after the date has been bumped in the running
+ system. */
+ if ((options & (READ_UTMP_USER_PROCESS | READ_UTMP_NO_BOOT_TIME)) == 0
+ && strcmp (file, UTMP_FILE) == 0
+ && !have_boot_time (a))
+ {
+ struct timespec boot_time;
+ if (get_android_boot_time (&boot_time) >= 0)
+ a = add_utmp (a, options,
+ "reboot", strlen ("reboot"),
+ "", 0,
+ "", 0,
+ "", 0,
+ 0, BOOT_TIME, boot_time, 0, 0, 0);
+ }
+
+# elif defined UTMP_NAME_FUNCTION
+ /* glibc, musl, macOS, FreeBSD, NetBSD, Minix, AIX, IRIX, Solaris, Cygwin */
/* Ignore the return value for now.
Solaris' utmpname returns 1 upon success -- which is contrary
@@ -340,7 +360,7 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
SET_UTMP_ENT ();
-# if (defined __linux__ && !defined __ANDROID__) || defined __minix
+# if defined __linux__ || defined __minix
bool file_is_utmp = (strcmp (file, UTMP_FILE) == 0);
/* Timestamp of the "runlevel" entry, if any. */
struct timespec runlevel_ts = {0};
@@ -390,7 +410,7 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
#endif
UT_EXIT_E_TERMINATION (ut), UT_EXIT_E_EXIT (ut)
);
-# if defined __linux__ && !defined __ANDROID__
+# ifdef __linux__
if (file_is_utmp
&& memcmp (UT_USER (ut), "runlevel", strlen ("runlevel") + 1) == 0
&& memcmp (ut->ut_line, "~", strlen ("~") + 1) == 0)
@@ -406,7 +426,7 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
END_UTMP_ENT ();
-# if defined __linux__ && !defined __ANDROID__
+# ifdef __linux__
/* On Alpine Linux, UTMP_FILE is not filled. It is always empty.
So, fake a BOOT_TIME entry, by getting the time stamp of a file that
gets touched only during the boot process.
@@ -449,26 +469,6 @@ read_utmp_from_file (char const *file, idx_t *n_entries, STRUCT_UTMP **utmp_buf,
}
# endif
-# if defined __ANDROID__
- /* On Android, there is no /var, and normal processes don't have access
- to system files. Therefore use the kernel's uptime counter, although
- it produces wrong values after the date has been bumped in the running
- system. */
- if ((options & (READ_UTMP_USER_PROCESS | READ_UTMP_NO_BOOT_TIME)) == 0
- && strcmp (file, UTMP_FILE) == 0
- && !have_boot_time (a))
- {
- struct timespec boot_time;
- if (get_android_boot_time (&boot_time) >= 0)
- a = add_utmp (a, options,
- "reboot", strlen ("reboot"),
- "", 0,
- "", 0,
- "", 0,
- 0, BOOT_TIME, boot_time, 0, 0, 0);
- }
-# endif
-
# if defined __minix
/* On Minix, during boot,
1. an entry gets written into /var/run/utmp, with ut_type = BOOT_TIME,
--
2.40.1
next prev parent reply other threads:[~2024-01-21 3:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87v87ntq4m.fsf.ref@yahoo.com>
2024-01-21 1:46 ` Android NDK r26 and utmpx Po Lu
2024-01-21 3:04 ` Paul Eggert [this message]
2024-01-21 3:38 ` Po Lu
2024-01-21 4:04 ` Paul Eggert
2024-01-21 5:11 ` Po Lu
2024-01-21 16:54 ` Bruno Haible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ef0d67a-8ac9-45f5-9544-b8863538d58f@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=bug-gnulib@gnu.org \
--cc=luangruo@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).