- "shutdown critical" prevents killing the service during
shutdown. And the service will be started if not running.
- Without it, services will be killed by SIGTERM / SIGKILL during shutdown.
- Even services with "shutdown critical" will be killed if shutdown
times out.
- Removes ueventd and vold from hard coded list. Each service's rc will
be updated to add "shutdown critical". watchdogd is still kept in the list.
bug: 37626581
Test: reboot and check last kmsg
Change-Id: Ie8cc699d1efbc59b9a2561bdd40fec64aed5a4bb
The exec_service documentation was difficult to read, clarify it.
Tests:
Run grip.py to verify that the markdown still works correctly.
Run aspell to verify spelling.
Change-Id: I29bdd456f3d3ea2a91c9d4772bd09a5a195f97a9
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Also renames "early mount" to "first stage mount" to prevent confusion
with "mount_all --early", which is run in the init second stage.
Also creates a base class: FirstStageMount and two derived classes:
FirstStageMountVBootV1 and FirstStageMountVBootV2 to replace/refactor
existing functions:
- early_mount() -> DoFirstStageMount() and FirstStageMount::DoFirstStageMount()
- vboot_1_0_early_partitions -> FirstStageMountVBootV1::GetRequiredDevices()
- vboot_2_0_early_partitions -> FirstStageMountVBootV2::GetRequiredDevices()
- vboot_1_0_mount_partitions ->
FirstStageMount::MountPartitions() and
FirstStageMountVBootV1::SetUpDmVerity()
- vboot_2_0_mount_partitions ->
FirstStageMount::MountPartitions() and
FirstStageMountVBootV2::SetUpDmVerity()
Bug: 37413399
Test: first stage mount /vendor with vboot 2.0 (avb) on bullhead
Test: first stage mount /system with without verity on bullhead
Test: first stage mount /vendor with with vboot 1.0 on sailfish
Change-Id: I6584bdf7d832c9fbc8740f97c9b8b94e68a90783
In the past, I had thought it didn't make sense to have multiple
Action classes with identical triggers within ActionManager::actions_,
and opted to instead combine these into a single action. In theory,
it should reduce memory overhead as only one copy of the triggers
needs to be stored.
In practice, this ends up not being a good idea.
Most importantly, given a file with the below three sections in this
same order:
on boot
setprop a b
on boot && property:true=true
setprop c d
on boot
setprop e f
Assuming that property 'true' == 'true', when the `boot` event
happens, the order of the setprop commands will actually be:
setprop a b
setprop e f
setprop c d
instead of the more intuitive order of:
setprop a b
setprop c d
setprop e f
This is a mistake and this CL fixes it. It also documents this order.
Secondly, with a given 'Action' now spanning multiple files, in order
to keep track of which file a command is run from, the 'Command'
itself needs to store this. Ironically to the original intention,
this increases total ram usage. This change now only stores the file
name in each 'Action' instead of each 'Command'. All in all this is a
negligible trade off of ram usage.
Thirdly, this requires a bunch of extra code and assumptions that
don't help anything else. In particular it forces to keep property triggers
sorted for easy comparison, which I'm using an std::map for currently,
but that is not the best data structure to contain them.
Lastly, I added the filename and line number to the 'processing
action' LOG(INFO) message.
Test: Boot bullhead, observe above changes
Test: Boot sailfish, observe no change in boot time
Change-Id: I3fbcac4ee677351314e33012c758145be82346e9
Currently if a process sets the sys.powerctl property, init adds this
property change into the event queue, just like any other property.
The actual logic to shutdown the device is not executed until init
gets to the action associated with the property change.
This is bad for multiple reasons, but explicitly causes deadlock in
the follow scenario:
A service is started with `exec` or `exec_start`
The same service sets sys.powerctl indicating to the system to
shutdown
The same service then waits infinitely
In this case, init doesn't process any further commands until the exec
service completes, including the command to reboot the device.
This change causes init to immediately handle sys.powerctl and reboot
the device regardless of the state of the event queue, wait for exec,
or wait for property conditions.
Bug: 37209359
Bug: 37415192
Test: Init reboots normally
Test: Update verifier can reboot the system
Change-Id: Iff2295aed970840f47e56c4bacc93001b791fa35
this will make the implementation more cleaner,
and has error message output when failed on some operations
also add the O_TRUNC flag explicitly for the open function
called in write_file.
And add more test on read_file and write_file functions
Bug: 36726045
Test: manual with hikey
Test: boot and init tests on bullhead
Test: cast with fugu, per b/36726045
Merged-In: If3c30a2fff58cfece2fcd27e69c30382146e6808
Change-Id: If3c30a2fff58cfece2fcd27e69c30382146e6808
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
- Run shutdown animation during shutdown if surfaceflinger is
available / running.
- services necessary for animation should be added to animation
class.
- Keep debugging tools while non-critical services are terminated:
logd, adbd, tombstoned
bug: 36526187
Test: many reboots
Change-Id: I758f700a622c6005f3df9f29de2b55270055ad4d
Exec services may also want to set other service flags such as
priority. Instead of expanding the exec syntax to handle this, create
a new command, exec_start, that will treat an existing service
definition as an exec service. The new exec_start command will start
the service then halt init from executing further commands until the
service has exited.
This change additionally encapsulates the waiting_for_exec logic into
ServiceManager and removes the ambiguous 'bool' return value from
Reap() which previously indicated if a Reaped service was an exec
service or not.
Bug: 36511808
Bug: 36102163
Test: Bullhead boots, services run with exec_start as they do exec.
Change-Id: I44f775cf1c1dd81d5c715f44fdc150c651a2c80a
Add support of multiple class names in service, so that related services
can be grouped together. By doing this, we can start/stop some services
for special purpose. For example, early zygote, early boot animation
and etc.
Bug: 36535312
Test: marlin boots with defined classes
Change-Id: Ifeaaf034fd836816e24f3775bece53ea83faada6
writepid takes a list of space delimited files. Make this clear in
the documentation, following the format for repeated fields used in
the rest of the file.
Test: N/A
Change-Id: I5bbe453fcb54f060d3cc5a82e9b38d3091a1ece3
this will make the implementation more cleaner,
and has error message output when failed on some operations
also add the O_TRUNC flag explicitly for the open function
called in write_file.
And add more test on read_file and write_file functions
Test: manual with hikey
Change-Id: Ifc1086a20e85db6980b497b1150a8a7952e672d6
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
Normally 'writepid' is used to add a process to a particular cpuset. However
certain systems with big/small cores might need to specify a default cpuset for
system processes which do not explicitly specify one. Add an option to use
'ro.cpuset.default' system property to specify default cpuset for system processes
which do not explicitly write to /dev/cpuset/... with 'writepid' option.
The cpuset name specified in ro.cpuset.default is just the cpuset name, e.g.
'/system-background', '/foreground', or simply '/' for the "root" cpuset.
Bug: 28550814
Test: `m -j32` succeeds for aosp_sailfish-eng. Phone boots successfully.
Also tested manually with debug trace messages on emulator with different
combinations of values for 'ro.cpuset.default'.
Change-Id: I501727fa5ee3f4bb7a938fa104b81a404b616633
There are many use cases from vendors to exec service in background and then
use a shell scriprt to wait for the command done.
This CL is to add a wait_for_prop command to suppor those use cases.
Bug: 34746108
Test: on marlin
Change-Id: Ia81290b0928f9d375710d2daa546714f0cd65b72
