CODEWITHSUNDEEP
androidcyanogenmod
LazyBones
LazyBones

Reputation: 107

Enabling logcat in init.rc

I'm appending init.rc in Android root with:

service logcat /system/bin/logcat -v long -f /mnt/sdcard/logcat.log

This solution doesn't generate any logs. The logcat.log file doesn't exist.

How can i start gathering logcat output through init.rc ?

Upvotes: 3

Views: 7980

Answers (2)

user7680587
user7680587

Reputation: 95

If we need to start the logcat and collect all the log buffers after on post-fs-data/boot completed from init.rc you can use below code in init.rc file.

on property:dev.bootcomplete=1
   start logging

on post-fs-data
   start logging

    service logging /system/bin/logcat -b all -v threadTime -f /data/directory_name/log -r 100000 -n 9
        user system
        group root system log
        disabled

Upvotes: -3

Brenton Camac
Brenton Camac

Reputation: 81

A couple of things that could be causing problems above: 1. you defined your service to be called logcat. That looks awfully close to what might be a reserved/pre-existing name. I would choose a more distinguished service name. 2. there is no explicit start trigger for the service, hence its entirely dependent on the context in which its defined (i.e. which init phase). Pick the wrong phase (i.e. too early) and /mnt may not even exist. 3. the service will by default be running as root and thus the logcat.log file will be rw only by root. Not good to run processes as root. And not good to force readers to be root in order to read the log file.

Here the approach I've used to achieve what you're looking to do.

Problem: Ordinarily, Android log messages remain in the kernel’s (volatile) memory only and thus doesn’t survive across reboots.

Solution: To retain those log messages across reboots requires them to be written to persistent storage (i.e. the filesystem). The following code defines such a service that is started by Android during init.

Step 1, define a service that the Android init process will spawn to do this activity. This goes in init.rc. 

service persistentLogging /system/bin/logcat -r 1024 -n 9 -v threadTime -f /cache/logs/log
    user system
    group system log
    disabled

Notes about the above:

  1. it creates a service called persistentLogging (that will be referred to in the second step below) by the start trigger.
  2. it requests logcat to do a rolling log file (consisting of 10 files / 1Mb each) in directory - /cache/logs (i.e. log, log.1, log.2, … log.9). Adjust to suit your needs.
  3. the service is to run as system user. This means the log file will be read+write only by system. If your app has system privileges then you’ll be able to read the log file. I’ve also defined the service to be in the log group too since that seems appropriate although since the files are not readable by group its a moot point.
  4. the service is initially disabled. It will be started by a trigger defined below
  5. the service is NOT oneshot. Hence, should it die, Android will attempt to restart it.

Step 2, define a trigger for starting the service. This also goes in your init.rc file.

on post-fs
    mkdir /cache/logs 0775 system log
    start persistentLogging

Notes about the above:

  1. the commands are triggered during the ‘post-fs’ phase so that they occur after filesystem partitions have been mounted and when other system directories are having their permissions changed. Ideally, this service should start as late as possible because its not important or used by any other start-up activity.
  2. the trigger first creates the target directory before starting the service. Remember the mkdir command syntax is defined by the init.rc language. In Android this syntax is not a sh syntax eventhough it looks a lot like it.
  3. eventhough the above logging service doesn’t start until the post-fs phase of init, it will nevertheless dump all logging information since the beginning of kernel's startup as these log messages are already in the kernel buffers and this logging service is merely copying those messages to a file.
  4. although both code fragments above ultimately need to appear in init.rc file, it is more maintainable if those additions are made to the init.${ro.hardware}.rc file defined for the device. e.g. init.freescale.rc which is automatically included by init.rc.

Upvotes: 5

Related Questions