When service is started prior to early init and if per-app memcg is enabled, service start will fail as the required directories for memcg isn't present viz /dev/memcg/apps.
Bug: 308818430
Test: th and CF OTA test with per-app memcg enabled
Change-Id: Ic65e8d179fbfb8e2135f2de5cc7c77d6c29ea7d2
Signed-off-by: Akilesh Kailash <akailash@google.com>
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>
This change will allow a later CL to wait for SIGCHLD without discarding
the SIGTERM information.
Bug: 308687042
Change-Id: I5b9ab4562060455573cd816cc48bf90576b39ab9
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Only report status information for the processes that are still running.
Additionally, make the logging output look better by starting the
process information from /proc start on a new line.
Fixes: ea595ba2a0 ("init: Log more information if stopping times out")
Change-Id: I3c882c364f11278087a78efb7a8e8fee8e582417
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Fix the following compiler warning:
//system/core/init:host_init_verifier clang++ host_init_verifier.cp
system/core/init/host_init_verifier.cpp:112:9: warning: ISO C++ requires field designators to be specified in declaration order; field 'pw_shell' will be initialized after field 'pw_uid' [-Wreorder-init-list]
.pw_uid = 0,
^~~~~~~~~~~
system/core/init/host_init_verifier.cpp:111:21: note: previous initialization for field 'pw_shell' is here
.pw_shell = static_shell,
^~~~~~~~~~~~
Change-Id: I930c668d7fb1d12ebe9307b1549776da71a9a95a
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Fix the following compiler warning:
system/core/init/init.cpp:754:57: warning: ISO C++ requires field designators to be specified in declaration order; field '' will be initialized after field 'sa_flags' [-Wreorder-init-list]
const struct sigaction act { .sa_handler = SIG_DFL, .sa_flags = SA_NOCLDSTOP };
^~~~~~~~~~~~~~~~~~~~~~~~
system/core/init/init.cpp:754:34: note: previous initialization for field '' is here
const struct sigaction act { .sa_handler = SIG_DFL, .sa_flags = SA_NOCLDSTOP };
^~~~~~~~~~~~~~~~~~~~~
Change-Id: I29e2d51dfdff85212a33eebfd51b241268cdfe9a
Signed-off-by: Bart Van Assche <bvanassche@google.com>
unit tests
1, Previous implementation has the staged prop application done in
property_service, which caused a number of unnecessary changes which
including exposing apis like AddPersistentProperty. In addition, it made
the property_service logic complicated. A better design is to have the
staged value application done while reading the persistent properties
from file. This way, no change to property service. In addition, unit
test is much cleaner and efficient.
2, add a unit test to lock down the behavior. Specifically, it locks down that when a prop is staged, it should be applied the next time when the persistent prop is loaded. In addition, it should lock down that other persistent props are not overwritten.
Bug: b/307752841, b/300111812, b/306062513
Change-Id: I43c603efbb803195065dda3f0bc2145716302bbc
The max_processes calculation is incorrect for KillProcessGroup because
the set of processes in cgroup.procs can differ between the multiple
reads in the implementation. Luckily the exact value isn't very
important because it's just logged. Remove max_processes from the API
and remove the warning about the new behavior in Android 11.
Note that we still always LOG(INFO) that any cgroup is being killed.
Bug: 301871933
Change-Id: I8e449f5089d4a48dbc1797b6d979539e87026f43
This fixes a bug introduced by I81b6bd984aad8f7ddec93ce74f4543e4f71be508
In the original CL, setting a sysprop `next_boot.<name>` and then
rebooting the device could remove all the persistent properties stored
in /data/property/persistent_properties. It happened because the
function `WritePersistentProperty` is called with a properties set which
is initialized as an empty set and then added with the properties which
had the next_boot prefix.
As a result...
Before the boot:
* persist.a = 1
* next_boot.b = 2
* next_boot.persist.c = 3
After the reboot:
* b = 2
* persist.c = 3
persist.a gets lost.
This change fixes the issue by populating properties set from the memory
and then save it to the file.
Bug: 306062513
Bug: 300111812
Test: do the following.
$ adb root
$ adb shell setprop persist.a 1
$ adb shell setprop next_boot.b 1
$ adb shell setprop next_boot.persist.c 1
$ adb reboot
$ adb shell getprop persist.a
1 // was (none) before this change
$ adb shell getprop b
1
$ adb shell getprop persist.c
1
$ adb reboot
$ adb shell getprop persist.a
1 // was (none) before this change
$ adb shell getprop b
// (none) because b isn't persisted. WAI.
$ adb shell getprop persist.c
1
Change-Id: I85d3777f9b32523b010e49b8ca53f4319dd2ce05
Certain applications may have their system properties overlaid with the
contents overlaid for appcompat purposes. Init must initialize the
appcompat folder, same as it does the standard folder.
Bug: 291814949
Test: manual
Change-Id: I6d239e0a10a1c81a05d4121e5fc2c41da5b3dbc4
Merged-In: I0c6a0f66dc543c6e861bc86a417e4feb5ecd7789
This SELinux option has been deprecated in the kernel since v5.7. In
v6.4, commit a7e4676e made any write to this file a no-op.
Since v4.4, the default value of 0 is set by the kernel. Skip the
setting of this value since we only support kernel >= 4.14.
Test: presubmit
Change-Id: Ied5945532e10b156dc0d9996b2a41a99d04e750b
Also, why are we accepting the completely made-up "RLIM_AS" but not the
real "RLIMIT_AS" in .rc files?
Bug: http://b/293894041
Test: treehugger
Change-Id: I18b10b6dd77265a9a14b88bfdf1cc0b474800a94
We've updated the glibc header (and musl will just use the bionic uapi
headers), so this is obsolete (and getting in the way of someone trying
to use the PERFMON capability).
Test: treehugger
Change-Id: Ife7ee076179e1db6246738aa41c2b82bd8546265
The initramfs.img from kernel builds do not store kernel modules under
_16k directory. Currently, init is programmed to only load kernel
modules from _16k dir if running on 16K page size kernel. Relax this
restriction so that booting on custom 16K kernel would work without
going through platform rebuild.
Test: th
Bug: 293313353
Bug: 300184677
Change-Id: I9ee3c74066ad9ec5127f1e8662f7c1273445994c
The macros isn't used anywhere but was a distraction when tracking down
/data mounting behaviour.
Test: build
Change-Id: Ie23574326cbebd7f515c8409e1dcb91a00cafc6f
Noticed while looking at riscv64. Looks like a bug, but actually nothing
we can do about it now or for the foreseeable future.
Bug: https://github.com/google/android-riscv64/issues/45
Test: treehugger
Change-Id: I2be81b2fd7095df40958a1f641d7b89cf5a8e41d
Improve the comment, and increase the "minimum maximum" to 24 --- we
only support 64-bit, and 64-bit never has less than 24 bits.
Bug: https://github.com/google/android-riscv64/issues/1
Test: treehugger
Change-Id: I478c7649aa19258352c908a449cabe12da94952c
OEM can add self-owned groups, but the system init cannot support if the group numbers are over than 12, relax some restrictions as appropriate.
Bug: b/296826987
Signed-off-by: Haichao Li <liuhc3@motorola.com>
Change-Id: I231d9f6c82e93c08bc97ca32df70e5b28760acbc
do_start() ignores ENOENT intentionally to avoid logspam. It's
implemented in ErrorIgnoreEnoent. However, without resetting errno,
ErrorIgnoreEnoent will ignore unrelated errors from Service::Start() due
to the sticking errono set from other commands.
Bug: 296821716
Test: launch_cvd
Change-Id: I71d3113bdb69bdca82e2ff4f3a793301749f6c08
ServiceList's services_update_finished flag was overlapped with the
global flag: is_default_mount_namespace_ready. Now DelayService() relies
on the is_default_mount_namespace_ready flag.
Add a service description with 'updatable' flag and invoke 'start
<name>' in 'on init' block (which comes before APEX activation).
See the log for "Cannot start an updatable service".
Bug: 293535323
Test: see the comment
Change-Id: I9341ba1a95d9b3b7c6081b530850d61f105f0a56
To support booting from both 4k/16k kernels, init need to tell which
kernel we are currently booting and load the right modules. To resolve
this issue, we store 16K modules into /lib/modules/`uname -r`_16k
directory.
Test: th
Bug: 293313353
Change-Id: I4a8296384537a71e16cd20e76e6c5dfb9074f574
It is expected that /metadata/ota/rollback-indicator and /metadata/gsi
don't always exist, so don't call selinux_android_restorecon() on them
when they don't exist. This eliminates the following error messages:
0 0 E selinux : SELinux: Could not get canonical path for /metadata/ota/rollback-indicator restorecon: No such file or directory.
0 0 E selinux : SELinux: Could not stat /metadata/gsi: No such file or directory.
Test: Booted Cuttlefish and verified the error messages are gone
Change-Id: I94c998556c85adde5f11f134178219ba7880c2be
create_apex_data_dirs() now uses GetApexListFrom(dir) in
apex_init_util.cpp.
This is essentially a refactoring, but there are a few behavioral
changes, which I think make more sense.
- Emits no error when opendir(/apex) fails.
- Emits errors when mkdir fails for each apex.
- Does not abort `perform_apex_config` even though create_apex_data_dirs
fails.
Bug: 293546778
Test: check /data/misc/apexdata/ after boot
Change-Id: I9d1a9710a6a626eec087c8c0fb1768667ffb036e
Reading .rc files from bootstrap APEXes causes "double loading".
This works for services because init just ignores duplicates. But it
emits error logs, which can mislead even though there's no actual
errors. Besides, for actions, duplicates can cause a problem when
commands are not idempotent.
So, when loading RC files from APEXes for the second time, we'd better
skip those bootstrap APEXes.
Bug: 290148081
Test: VendorApexHostTestCases
Change-Id: Ia630dbd14046064b5e5c612c01ebacf57091c8d4
To start an early_hal service from a bootstrap vendor apex, init now
reads .rc files from bootstrap apexes as well.
In this change, perform_apex_config command is re-purposed to support
bootstrap mode. Now we have some similarity between two apexd calls:
- for bootstrap apexes (in the bootstrap mount namespace):
exec_start apexd-bootstrap
perform_apex_config --bootstrap
- for normal apexes (in the default mount namespace):
restart apexd
...
wait_for_prop apexd.status activated
perform_apex_config
Note that some tasks in perform_apex_config are not needed in the
bootstrap. For example, we don't need to create apexdata directories
for bootstrap apexes.
Bug: 290148081
Test: VendorApexHostTestCases
Change-Id: I8f683a4dcd7cd9a2466a4b1b417d84c025c37761
