Another alternative would be to add a logwrapper-type flag to the init
service-spawning code which handles logwrapper's duties without needing to
go through another executable.  That being said, my feeling towards
logwrapper is generally that it's a useful debugging feature that should
not make its way to user devices, with the proper logging API given
consideration instead for each service to determine what really ought to be
logged.

On Wed, Sep 16, 2015 at 11:01 AM Joshua Brindle <[email protected]>
wrote:

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

Reply via email to