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 -- 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]. > -- Nick Kralevich | Android Security | [email protected] | 650.214.4037
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
