Reduce the time spent in WaitToBeReaped() by waiting for SIGCHLD instead
of waiting for 50 ms.
Bug: 308687042
Change-Id: I5e259fdd22dec68e45d27205def2fc6463c06ca3
Signed-off-by: Bart Van Assche <bvanassche@google.com>
From the unique_fd.h header file: "unique_fd's operator int is
dangerous, but we have way too much code that depends on it, so make
this opt-in at first."
From the Google C++ style guide: "Do not define implicit conversions."
See also go/cstyle#Implicit_Conversions.
Hence this CL that disables unique_fd::operator int().
Change-Id: I28d94755d5408f63e5819da8d1cbc285057f867f
Signed-off-by: Bart Van Assche <bvanassche@google.com>
In microdroid, APEXes are passed as block devices from host, and then
mounted directly, without using /data. Unmounting APEXes on reboot is
for clean unmount of /data, so it's not needed in microdroid.
This skips unmounting in microdroid to remove unnecessary SELinux
denials.
Bug: 256793087
Test: run microdroid and reboot, see no denials happen
Change-Id: Iaf737876f5ab5de5e8f76ed8bb0963cc25d73a80
Thermal shutdown could be due to tskin temperature or
battery temperature. Pass reason while rebooting the
system to reflect properly in boot.reason
Bug: 238464124
Test: Build and boot on device. Check reboot reason
for thermal shutdown and battery thermal shutdown with
thermal warmreset enabled.
Change-Id: I192562fed48ae7da7843e383362cd22a76ce479f
APEX configs have supported only 'service' definitions. For those
services relying on 'on' trigger actions, we had to have separate config
files installed in read-only partitions (e.g. /system/etc/init).
This was suboptimal because even though APEXes are updatable, read-only
partitions are not.
Now, 'on' is supported in APEX configs. Putting 'on' trigger actions
near to service definitions makes APEX more self-contained.
'on' trigger actions loaded from APEX configs are not sticky. So, events
happens before loading APEX configs can't trigger actions. For example,
'post-fs-data' is where APEX configs are loaded for now, so 'on
post-fs-data' in APEX configs can't be triggerd.
Bug: 202731768
Test: atest CtsInitTestCases
Change-Id: I5a01d9c7c57b07955b829d6cc157e7f0c91166f9
Don't start shutdown critical service or turn off
backlight, when ro.init.shutdown_animation=true
Bug: 196511757
Test: config ro.init.shutdown_animation=true and build
shutdownanimation.zip to /system/media/
Signed-off-by: zengshuchuan <zengshuchuan@allwinnertech.com>
Change-Id: I5932b7281af630e80247048a70fe1b24f536d1d9
[Description]
In the Quiescent Reboot process,
the android init process will pass the reboot target name "quiescent"
to the kernel through reboot syscall.
Kernel will write the boot-quiescent flag
to the misc partition to notify the bootloader.
When rebooting, bootloader will be added to
bootargs androidboot.quiescent=1 to notify android .
In the new version of GKI,
the filp_open function is not allowed
so that it is impossible to write the quiescent flag
in the Kernel to the misc partition.
https://android-review.googlesource.com/c/kernel/common/+/1705108
/1..29/android/abi_gki_aarch64_mtk#b641
Bug: 192634025
Test:
adb reboot quiescent
adb shell setprop sys.powerctl reboot,quiescent
Change-Id: I5ac982a1f16df39fa6bf567729a18ca8225f21f2
It's possible that CONFIG_ZRAM_WRITEBACK is y,
but userspace doesn't set the /sys/block/zram0/backing_dev,
so its value is 'none'.
It's the same with "CONFIG_ZRAM_WRITEBACK is not set".
Change-Id: I2df89ceee68e4685deef5113bada21be96779e9b
Signed-off-by: shisiyuan <shisiyuan@xiaomi.com>
'/sys/block/zram0/backing_dev' will exist even if zram is not swapped on in some devices. And there is no reason to ensure that zram is swapped on if '/sys/block/zram0/backing_dev' exists. So, if we want to kill backing_dev during userspace reboot, we should check if zram is swapped on first.
TEST: as follow
- adb root
- adb shell swapoff /dev/block/zram0
- adb shell echo 1 > /sys/block/zram0/reset
- adb shell setprop test.userspace.reboot.flag 1
- adb reboot userspace
- (wait reboot ending) adb shell getprop test.userspace.reboot.flag (1 will be show if successful)
Signed-off-by: luwei9 <luwei9@xiaomi.com>
Change-Id: Icca569cf8d64bc024b867dae2ab789fc9e76445a
This test spawns several services backed by /system/bin/yes executable,
and then stops them either while SIGTERM or SIGKILL.
Ideally we want to unit test more of reboot logic, but that requires a
bigger refactoring.
Test: atest CtsInitTestCases
Bug: 170315126
Bug: 174335499
Change-Id: Ife48b1636c6ca2d0aac73f4eb6f4737343a88e7a
Instead of operating on raw pointers, init now uses name of the
services as it's primary identifier. Only place that still uses
vector<Service*> is StopServices.
In addition, ServiceList::services() function is removed, which should
help avoiding similar bugs in the future.
Bug: 170315126
Bug: 174335499
Test: adb reboot
Test: atest CtsInitTestCases
Change-Id: I73ecd7a8c58c2ec3732934c595b7f7db814b7034
Merged-In: I73ecd7a8c58c2ec3732934c595b7f7db814b7034
Ignore-AOSP-First: fixing security vulnerability
(cherry picked from commit 8d6ae2dd8a)
Instead of operating on raw pointers, init now uses name of the
services as it's primary identifier. Only place that still uses
vector<Service*> is StopServices.
In addition, ServiceList::services() function is removed, which should
help avoiding similar bugs in the future.
Bug: 170315126
Bug: 174335499
Test: adb reboot
Test: atest CtsInitTestCases
Change-Id: I73ecd7a8c58c2ec3732934c595b7f7db814b7034
Ignore-AOSP-First: fixing security vulnerability
Store pertinent information about userspace reboot events in the case
of failure. This information is any services which failed to stop
cleanly, the output of the default fstab and /proc/mounts, and
a list of mounts which failed to unmount. This information is only
stored as necessary (i.e. mount information will not be stored if
everything unmounted, even if some services failed to stop).
Added new /metadata/userspacereboot directory to persist this
information. Information older than 3 days will be deleted.
Test: adb reboot userspace with sigterm/sigkill timeouts set to
very low values
Test: Manual test of storing all other information
Bug: 151820675
Change-Id: I6cfbfae92a7fc6f6c984475cad2c50c559924866
Having mounted apexes with loop back devices backing files on /data
partition will prevent clean unmount of it. Unmounting them and tearing
down loop devices should minimize the risk of that.
Note that it won't fix the issue completely, as there are a few (~2-3)
processes that keep restarting even after SIGKILL is sent. Which means
that they can still hold references to apexes on /data partition. But
in practice probability of this is quite low.
Test: adb reboot
Test: put tzdata apex in /data/apex/active && adb reboot
Bug: 158152940
Change-Id: I4624567b3d0f304dba4c6e37b77abd89e57411de
Init starts ueventd in the default mount namespace to support loading
firmware from APEXes.
Bug: 155023652
Test: devices boots
adb$ nsenter -t (pid of ueventd) -m ls /apex
=> shows all APEXes
Change-Id: Ibb8b33a07eb014752275e3bca4541b8b694dc64b
To ensure we can shutdown cleanly, and don't hang an outstanding
requests to a FUSE host daemon that has already exited.
Bug: 153411204
Test: inspect logs during shutdown
Change-Id: I8e6479bd54dbc1fc85b087617aa6b16be9f15a3b
The exit of init panics the system *after* process context (mm, stack,
...etc.) are recycled, according to Linux kernel's 'do_exit'
implementation. To preserve most init process context for debugging,
triggers the panic via proc-sysrq explicitly.
Note: after this change, there will be no "Attempt to kill init" panic
when androidboot.init_fatal_panic is set.
Test: Insert data abort fault in init, the full process context is
preserved in memory dump captured after panic.
Bug: 155940351
Change-Id: I3393bd00f99b8cb432cfa19a105b7d636b411764
(cherry picked from commit be1cf9006a)
The exit of init panics the system *after* process context (mm, stack,
...etc.) are recycled, according to Linux kernel's 'do_exit'
implementation. To preserve most init process context for debugging,
triggers the panic via proc-sysrq explicitly.
Note: after this change, there will be no "Attempt to kill init" panic
when androidboot.init_fatal_panic is set.
Test: Insert data abort fault in init, the full process context is
preserved in memory dump captured after panic.
Bug: 155940351
Change-Id: I3393bd00f99b8cb432cfa19a105b7d636b411764
Since this function is used in userspace reboot, we need to be more
diligent with error handling, e.g.:
* If init fails to read /sys/block/zram0/backing_dev, then fail and
fallback to hard reboot.
* Always call swapoff.
* Always reset zram.
* Tear down loop device only if zram is backed by a loop device.
Test: adb reboot userspace
Bug: 153917129
Change-Id: I4709da1d08cf427ad9c898cfb2506b6a29f1d680
Merged-In: I4709da1d08cf427ad9c898cfb2506b6a29f1d680
(cherry picked from commit a840d405eb)
Since this function is used in userspace reboot, we need to be more
diligent with error handling, e.g.:
* If init fails to read /sys/block/zram0/backing_dev, then fail and
fallback to hard reboot.
* Always call swapoff.
* Always reset zram.
* Tear down loop device only if zram is backed by a loop device.
Test: adb reboot userspace
Bug: 153917129
Change-Id: I4709da1d08cf427ad9c898cfb2506b6a29f1d680
Similarly to other recovery mechanisms, timeout is controlled by a
read-only property that can be configured per-device.
Test: adb root
Test: adb shell setprop init.userspace_reboot.started.timeoutmillis 2
Test: adb reboot userspace
Bug: 152803929
Change-Id: Id70710b46da798945ac5422ef7d69265911ea5ef
Merged-In: Id70710b46da798945ac5422ef7d69265911ea5ef
(cherry picked from commit d05535485f)
Similarly to other recovery mechanisms, timeout is controlled by a
read-only property that can be configured per-device.
Test: adb root
Test: adb shell setprop init.userspace_reboot.started.timeoutmillis 2
Test: adb reboot userspace
Bug: 152803929
Change-Id: Id70710b46da798945ac5422ef7d69265911ea5ef
Devices in the lab are hitting an issue where they're getting stuck
likely in the sync() call in DoReboot() before we start the reboot
monitor thread and before we shut down services.
It's possible that concurrent writing to RW file systems is causing
this sync() call to take essentially forever. To protect against
this, we need to remove this sync(). Note that we will still call
sync() after shutting down services.
Note that the service shutdown code has a timeout and there is a
reboot monitor thread that will shutdown the device if more than 30
seconds pass above that timeout. This change increases that timeout
to 300 seconds to give the final sync() calls explicitly more time to
finish.
Bug: 150863651
Test: reboot functions normally
Test: put an infinite loop in DoReboot and the the reboot monitor thread
triggers and shuts down the device appropriately
Merged-In: I6fd7d3a25d3225081388e39a14c9fdab21b592ba
Change-Id: I6fd7d3a25d3225081388e39a14c9fdab21b592ba
(cherry picked from commit 10615eb397)
Devices in the lab are hitting an issue where they're getting stuck
likely in the sync() call in DoReboot() before we start the reboot
monitor thread and before we shut down services.
It's possible that concurrent writing to RW file systems is causing
this sync() call to take essentially forever. To protect against
this, we need to remove this sync(). Note that we will still call
sync() after shutting down services.
Note that the service shutdown code has a timeout and there is a
reboot monitor thread that will shutdown the device if more than 30
seconds pass above that timeout. This change increases that timeout
to 300 seconds to give the final sync() calls explicitly more time to
finish.
Bug: 150863651
Test: reboot functions normally
Test: put an infinite loop in DoReboot and the the reboot monitor thread
triggers and shuts down the device appropriately
Change-Id: I6fd7d3a25d3225081388e39a14c9fdab21b592ba
