Nick Kralevich wrote:
If I understand correctly, this doesn't solve Kukjin's problem. Normally if
an init service prints a line to stdout / stderr, the line is sent to
/dev/null. Logwrapper works by redirecting stdout / stderr to logcat
instead of to /dev/null.
Persisting the log files doesn't do anything if the logs never make it to
the logger. Persisting the log files isn't recommended because it wastes
disk space and persists log entries across reboots, and is contrary to our
best practices.
Instead of using logwrapper, the relevant code should be fixed so it uses
proper logging API calls, instead of stdout / stderr.
We've tried a number of times to handle logwrapper
* https://android-review.googlesource.com/58300
* https://android-review.googlesource.com/70480
* https://android-review.googlesource.com/98186
but each time it caused more problems than it solved. The recommended
solution is to just remove any logwrapper entries. For example, if you have
the service:
service foo_util /system/bin/logwrapper /system/bin/foo
it should be changed to
service foo_util /system/bin/foo
Why not make a logwrapper domain and have init transition to logwrapper
and have logwrapper transition to foo domain?
The logwrapper domain can have very few permissions, just enough to exec
and transition to other domains.
-- Nick
On Wed, Sep 16, 2015 at 9:46 AM, Jeffrey Vander Stoep<[email protected]>
wrote:
Try logpersist for userdebug/eng builds:
$ adb shell logpersist.start --help
logpersist.cat - dump current logcat logs
logpersist.start - start logcatd service
logpersist.stop [--clear] - stop logcatd service
$ adb shell logpersist.start
logcatd
logd 4785 1 3300 1200 __skb_recv 0000000000 S
/system/bin/logcat
This combines logcat and kmsg and stores them in /data/misc/logd/
On Wed, Sep 16, 2015 at 8:40 AM 배국진<[email protected]> wrote:
Dear Google.
I have a question for logwrapper on M OS.
It looks that we cannot use logwrapper on M OS, could you give a guide
for it ?
Please correct me if I'm wrong.
We can not use logwrapper service on M OS because of init Neverallow Rule.
AOSP file context : /system/bin/logwrapper u:object_r:system_file:s0
Vendor init.rc: service AAA /system/bin/logwrapper /system/bin/AAA
Vendor file_context and policy
: /system/bin/AAA u:object_r:AAA_exec:s0
init_daemon_domain(AAA)
The other problem is that vendor cannot change the aosp file_context due
to new CTS,testAospFileContexts
Do you like not to use "service logwrapper ..." ? or only use at eng
binary ?
- Neverallow Rule
# init should never execute a program without changing to another domain.
neverallow init { file_type fs_type }:file execute_no_trans;
AOSP file context : /system/bin/logwrapper u:object_r:system_file:s0
Thanks, Kukjin.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
