After introducing ro.boot.serialconsole=0, the console will no longer be
spawned, but a step was missed to disable the service to prevent
respawns.
Bug: 266982931
Bug: 223797063
Bug: 267428635
Change-Id: I12b159eaa1999781aec31c05ce431b55e2ba4017
We could combine this with the existing log, but I
wouldn't want to make that appear later.
Ironically, adding this log to try to reduce logs.
Bug: 36785118
Test: :) adb logcat -d | grep "started service" | wc -l
131
Change-Id: I38f4e9740871aa256eef0c62e897038eb46871a5
For many years, services declaring "console" would only be started if the
console device specified by androidboot.console= was present under /dev.
However, they would also be started if the /dev/console node existed.
This fallback causes problems with newer GKI kernel images which now
hard-code "console=ttynull" via CONFIG_CMDLINE, which essentially means
/dev/console always exists, even though this console points nowhere.
It also causes problems on devices where the androidboot.console was not
the same as the kernel dmesg console ("console="), such as cuttlefish,
because those platforms could not simultaneously enable kernel logging
but disable the interactive serial console feature. The framework just
assumed both would be muxed on the same serial port. Cuttlefish had a
workaround, to use "androidboot.console=invalid" to avoid the fallback,
but this doesn't work on devices which still want to mux the kernel logs
and interactive serial console.
This change resolves the issue in a better way, by introducing a new
boolean property called "androidboot.serialconsole". Setting this to "0"
will disable the console services, regardless of whether the
/dev/console or /dev/${ro.boot.console} devices exist. Older kernels
and bootloaders don't need to set this and can rely on the old behavior
in init, but bootloaders booting newer kernels must set it to avoid the
"performance is impacted" message due to console services being started.
Bug: 266982931
Bug: 223797063
Bug: 267428635
Test: "launch_cvd" with "androidboot.console=invalid" removed;
See the "performance is impacted" message.
Test: "launch_cvd" with "androidboot.serialconsole=0";
The "performance is impacted" message is gone.
Change-Id: Iaad4d27ffe4df74ed49606d3cabe83483c350df4
If a service specifies gentle_kill, attempt to stop it will send SIGTERM
instead of SIGKILL. After 200ms, it will issue a SIGKILL.
Bug: 249043036
Test: atest CtsInitTestCases:init#GentleKill
Added in next patch
Change-Id: Ieb0e4e24d31780aca1cf291f9d21d49cee181cf2
From
https://android-build.googleplex.com/builds/tests/view?testResultId=TR66328435937757440&invocationId=I00700010119503421:
system/core/init/init_test.cpp:219: Failure
Failed
Value of: service->Start()
Actual: createProcessGroup(0, 15611) failed for service 'console'
Expected: is ok
The above error message does not contain enough information to
root-cause the test failure. Hence this CL that makes an error message
more informative.
Bug: 262090304
Change-Id: I09929b2f2aabf1eec4d90ec93234a9e968888da4
Signed-off-by: Bart Van Assche <bvanassche@google.com>
process_cgroup_empty_ is used to indicate that a service is already
killed or not. If cgroup support lacks, services cannot be killed
because process_cgroup_empty_ is always true.
This change fixes it by not assigning process_cgroup_empty_ as true.
Instead, make KillProcessGroup send signals even when cgroup is
disabled. Also DoKillProcessGroupOnce() is updated so it returns a number of killed processes, excluding already dead processes. This behavior agrees with its name (DoKillProcessOnce), and it prevents regression upon missing cgroups, because kill(-pgid) will always
"succeed" so KillProcessGroup will loop even when all processes are
already dead.
Bug: 257264124
Test: boot microdroid, see services are terminated
Change-Id: I19abf19ff1b70c666cd6f12d0a12956765174aaa
Make it easier to diagnose service failures.
Bug: 213617178
Change-Id: I27135cb32b6a98b2fe24ab2324dffbf5b591fdd5
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Revert commit 14f9c15e05 ("init: Add more diagnostics for signalfd
hangs") because:
* That commit was intented to help with root-causing b/223076262.
* The root cause of b/223076262 has been fixed (not blocking SIGCHLD
in all threads in the init process).
Test: Treehugger
Change-Id: I586663ec0588e74a9d58512f7f31155398cf4f52
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Multiple tests in CtsInitTestCases, e.g. RebootTest#StopServicesSIGKILL,
can trigger the following race condition:
* A service is started. This involves calling fork() and also to call
RunService() in the child process. RunService() calls setpgid().
* Service::Stop() is called and calls KillProcessGroup().
KillProcessGroup() calls kill(-pgid, SIGKILL) before the child process
has called setpgid(). pgid is the process ID of the child process. The
kill() call fails because setpgid() has not yet been called.
Fix this race condition by adding a setpgid() call in the parent process
and by waiting from the parent until the child has called setsid() if a
console is attached.
Bug: 213617178
Change-Id: Ieb9e6908df725447e3695ed66bb8bd30e4e38aa9
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Make the code easier to read by introducing symbolic names for the
constants used by Service::Start() for communication between the parent
and child processes.
Bug: 213617178
Change-Id: I3e735e149682fa9df2ed57f75eb5a67d7c68bd92
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Revert commit 9c61dad67e in preparation of
introducing a second interprocess communication channel.
Bug: 213617178
Change-Id: I2959a3902a1b994cca2ac99855be1fc60d63bcbb
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Multiple tests in CtsInitTestCases, e.g. RebootTest#StopServicesSIGKILL,
can trigger the following race condition:
* A service is started. This involves calling fork() and also to call
RunService() in the child process. RunService() calls setpgid().
* Service::Stop() is called and calls KillProcessGroup().
KillProcessGroup() calls kill(-pgid, SIGKILL) before the child process
has called setpgid(). pgid is the process ID of the child process. The
kill() call fails because setpgid() has not yet been called.
Fix this race condition by adding a setpgid() call in the parent process
and by waiting from the parent until the child has called setsid() if a
console is attached.
Bug: 213617178
Test: Cuttlefish + atest 'CtsInitTestCases'
Change-Id: I6931cd579e607c247b4f79a5b375455ca3d52e29
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Prepare for using the interprocess communication channel in two
directions.
Bug: 213617178
Change-Id: Ic78a3d8a2ec1f808fa5b4c4b198051655ee1b0ec
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Multiple tests in CtsInitTestCases, e.g. RebootTest#StopServicesSIGKILL,
can trigger the following race condition:
* A service is started. This involves calling fork() and also to call
RunService() in the child process. RunService() calls setpgid().
* Service::Stop() is called and calls KillProcessGroup().
KillProcessGroup() calls kill(-pgid, SIGKILL) before the child process
has called setpgid(). pgid is the process ID of the child process. The
kill() call fails because setpgid() has not yet been called.
Fix this race condition by adding a setpgid() call in the parent process
and by waiting from the parent until the child has called setsid() if a
console is attached.
Bug: 213617178
Test: Cuttlefish + atest 'CtsInitTestCases'
Change-Id: I4c55790c2dcde8716b860aecd57708d51a081086
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Prepare for introducing a second interprocess communication channel by
introducing the class InterprocessFifo. Stop using std::unique_ptr<> for
holding the pipe file descriptors. Handle EOF consistently.
Bug: 213617178
Change-Id: Ic0cf18d3d8ea61b8ee17e64de8a9df2736e26728
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The documentation added by commit c9c0bbac53 ("init: Add task_profiles
init command") mentions that the task_profiles keyword sets process
attributes. Make the implementation of that keyword match the
documentation.
Change-Id: Ia080132f16bfc2488f8c25176d6aed37a2c42780
Signed-off-by: Bart Van Assche <bvanassche@google.com>
We are planning to remove cgroups from the Micrdroid kernel, since the
entire VM belongs exclusively to a single owner, and is in the control
of the cgroups on the host side.
This patch expoxes CgroupAvailable API from libprocessgroup, and changes
init to query the CgroupAvailable API before doing any
cgroups/task_profiles related work.
Bug: 239367015
Test: run MicrodroidDemoApp
Test: atest --test-mapping packages/modules/Virtualization:avf-presubmit
Change-Id: I82787141cd2a7f9309a4e9b24acbd92ca21c145b
Prepare for migration of the blkio controller to the v2 cgroup hierarchy
by applying the NormalIoProfile when starting a service. While the
NormalIoProfile is automatically applied when the blkio controller is
mounted in the v1 hierarchy, this is not the case for the v2 hierarchy.
Bug: 213617178
Change-Id: I3cad288a31aa2692e10c778ae1e5fdd04acd66d7
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Passed apex file name to service. The file name will be parsed
to determine 1) whether the service is from an apex; 2) apex name
Bug: 236090201
Change-Id: I2c292c0c067f4bf44bb25b1f80e4f972b94f7258
servicemanager/hwservicemanager are pre-apexd services but still wants
to see VINTF fragments from APEXes, especially from /data.
Like ueventd, these services need to be started in "default" mount
namespace.
Bug: 237672865
Test: m && boot
Change-Id: I0266c5be5530a1a07f8ffa23a26186d45a55613f
We have a case where a service is requested to be started and does
not appear to be running, but we see no indication that it is
actually starting. This log should be enough information to see
if init is in a bad state.
Bug: 232297944
Test: doesn't add too much spam
~/android/aosp/system/core/init :) adb logcat -d | grep "requested start" | wc -l
42
Change-Id: Ic07f250c98b200b9e5b4432200c3668c6ca0ff35
When system_server crashes or gets killed, it causes zygote to kill
itself, which in turn leads to killing all processes in the same
process group (all apps). This leaves empty process groups because
system_server is not there to remove them.
Purge empty process groups when init detects zygote death.
Bug: 228160715
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0ce27eea28f8713e52033bbec2d5363a7b8ff5db
This adds three more diagnostics to stuck exec services:
1. /proc/pid/fds is dumped
2. /proc/pid/status is dumped
3. HandleSignalFd is called to see if a SIGCHLD got stuck somewhere
Bug: 223076262
Test: while (1) in linkerconfig
Ignore-AOSP-First: diagnostics
Change-Id: Ida601d86e18be9d49b143fb88b418cbc171ecac6
During process startup, system creates a process group and places the
new process in it. If process group creation fails for some reason, the
new child process will stay in its parent's group. This poses danger
when the child is being frozen because the whole group is affected and
its parent is being frozen as well.
Fix this by treating group creation failure as a fatal error which would
prevent the app from starting.
Bug: 227395690
Test: fake group creation failure and confirm service failure to start
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I83261bef803751759c7fd709bf1ccd33ccad3a0b
This adds two new diagnostics. First, signalfd reads are now non-blocking. If the read takes more than 10 seconds, we log an error.
Second, init now wakes up from epoll() every 10 seconds. If it waits on an "exec" command for more than 10 seconds, it logs an error.
This change will be reverted as soon as we get feedback.
Bug: 223076262
Test: device boots
Change-Id: I7ee98d159599217a641b3de2564a92c2435f57ef
The Service::Start() method is so long that its length negatively
affects readability of the code. Hence this patch that splits
Service::Start().
Test: Booted Android in Cuttlefish.
Change-Id: I5a6f587ecc5e6470137de6cceda7e685bce28ced
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The Service::Start() method is so long that its length negatively
affects readability of the code. Hence this patch that splits
Service::Start().
Test: Booted Android in Cuttlefish.
Change-Id: I972f4e60844bb0d133b1cca1fd4e06bb89fc5f37
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The Service::Start() method is so long that its length negatively
affects readability of the code. Hence this patch that splits
Service::Start().
Test: Booted Android in Cuttlefish.
Change-Id: Ib8e1e87fbd335520cbe3aac2a88d250fcf3b4ff0
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The SetTaskProfiles() call modifies cgroup attributes. Modifying cgroup
attributes can only succeed after the cgroups and cgroup attributes have
been created. Hence this patch that makes the child process wait until
the parent has finished creating cgroups and activating cgroup
controllers.
Bug: 213617178
Test: Without this patch the migration to the v2 hierarchy does not work reliably. With this patch applied, the migration to the v2 hierarchy works reliably.
Change-Id: I80a7c0a35453d8fd89ed798d077086aa8ba9ea17
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Remove the class_start_post_data and class_reset_post_data commands,
since they aren't used anymore. They were only used on devices that
used FDE (Full Disk Encryption), via actions in rootdir/init.rc. These
actions have been removed, since support for FDE has been removed.
There is no use case for these commands in vendor init scripts either.
Keep the mark_post_data command, since DoUserspaceReboot() uses the
post-data service flag even on non-FDE devices.
Bug: 191796797
Change-Id: Ibcd97543daa724feb610546b5fc2a0dd7f1e62e7
Currently there is no socket for daemon instances launched during the
selinux phase of init. We don't create any sockets due to the complexity
of the required sepolicy.
This workaround will allow us to create the socket with very minimal
sepolicy changes. init will launch a one-off instance of snapuserd in
"proxy" mode, and then the following steps will occur:
1. The proxy daemon will be given two sockets, the "normal" socket that
snapuserd clients would connect to, and a "proxy" socket.
2. The proxy daemon will listen on the proxy socket.
3. The first-stage daemon will wake up and connect to the proxy daemon
as a client.
4. The proxy will send the normal socket via SCM_RIGHTS, then exit.
5. The first-stage daemon can now listen and accept on the normal
socket.
Ordering of these events is achieved through a snapuserd.proxy_ready
property.
Some special-casing was needed in init to make this work. The snapuserd
socket owned by snapuserd_proxy is placed into a "persist" mode so it
doesn't get deleted when snapuserd_proxy exits. There's also a special
case method to create a Service object around a previously existing pid.
Finally, first-stage init is technically on a different updateable
partition than snapuserd. Thus, we add a way to query snapuserd to see
if it supports socket handoff. If it does, we communicate this
information through an environment variable to second-stage init.
Bug: 193833730
Test: manual test
Change-Id: I1950b31028980f0138bc03578cd455eb60ea4a58
This reverts commit 1c51525f66 because it
accidentally made reboot_on_failure be a no-op for all services. This
is because Reap() itself calls KillProcessGroup() on devices with a
vendor level >= R, which in turn sets SVC_STOPPING. I had overlooked
this somehow, probably because I didn't consider that a service can
consist of multiple processes.
It turns out that real FDE devices don't actually need the above commit
because FDE devices aren't allowed to have updatable apexes enabled, and
without updatable apexes enabled, apexd exits automatically and
therefore doesn't have to be stopped. This can be verified by using the
aosp_cf_x86_phone_noapex build target, rather than aosp_cf_x86_phone
which I had used for testing before. So just revert it for now.
Bug: 194370048
Change-Id: I90eddf2a87397449b241e5acaaa8d4a4241d73a9
