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
Add a new service flag SVC_STOPPING which tracks whether a service is
being manually stopped by init, and make the "reboot_on_failure" service
setting not apply when SVC_STOPPING is set.
This is needed for devices that use FDE, because otherwise the device
reboots during the following init script fragment:
on property:vold.decrypt=trigger_shutdown_framework
class_reset late_start
class_reset main
class_reset_post_data core
class_reset_post_data hal
... because that stops all services, including apexd which has been
marked with reboot_on_failure since
https://android-review.googlesource.com/c/platform/system/apex/+/1325212.
So init was killing apexd, then rebooting the device because apexd
"failed" due to having been killed. Making reboot_on_failure not apply
when init stops a service itself fixes the problem.
This is one of a set of changes that is needed to get FDE working again
so that devices that launched with FDE can be upgraded to Android 12.
Bug: 186165644
Test: Tested FDE on Cuttlefish
Change-Id: I599f7ba107e6c126e8f31d0ae659f0ae672a25e4
init starts services in "bootstrap" mount namespace until the "default"
mount namespace is ready even when init's current mount namespace is
"default".
apexd and linkerconfig are those processes to set up the mount
namespaces: apexd activates apexes and linkerconfig generates linker
configs.
Previously apexd is allowed to be started in the "current" namespace by
checking its "service name"(it should be "apexd"). But there can be a
certain environment apexd is started in a different way. For example, in
microdroid, apexd is started using "exec -- /system/bin/apexd --vm"
because it wants to run in a different execution mode.
So, instead of checking the service name, its executable's path is
checked against to allow apexd to be started in the current mount
namespace.
Bug: 179342589
Test: MicrodroidTestCase (microdroid boots)
Test: cuttlefish boots
Change-Id: I7c2490e15d481c28ddf382d2d3fdf58a78e467ec
Any service which is executed when Runtime apex is mounted, but
linkerconfig is not updated can fail to be executed due to missing
information in ld.config.txt. This change updates init to have a status
variable which contains if current mount namespace is default
and APEX is not ready from ld.config.txt, and use bootstrap namespace if
it is not ready.
Bug: 181348374
Test: cuttlefish boot succeeded
Change-Id: Ia574b1fad2110d4e68586680dacbe6137186546e
Revert submission 1563392-remove_art_from_bootstrap
Reason for revert: Bug: 179002105
Reverted Changes:
I65e2a2089:Remove ART APEX from the bootstrap apexes
Ic20df80e2:Remove ART APEX from the bootstrap apexes
Change-Id: I474ab95805c5ca28e0bba91f3d226e8db5a7a9ea
For user who would like to retain the crash symptom and avoid device
from power cycle for live debugging, set
init.svc_debug.no_fatal.<svc_name> to "true" to skip FATAL reboot.
Bug: 177593855
Change-Id: I0bdb6191e5963c08e1ea301a60060acf916dd49b
Also includes new --out_<partition> flags for
system,system_ext,product,vendor,odm
to allow host_init_verifier to work with a collection of init rc files.
Test: host_init_verifier --out_system=... --out_vendor=...
where vendor contains an init rc file that overrides a service
present in system. Observe parse failure and non-zero exit.
Bug: 163089173
Change-Id: I520fef613e0036df8a7d47a98d47405eaa969110
The critical services can now using the interface `critical
[window=<fatal crash window mins>] [target=<fatal reboot target>]` to
setup the timing window that when there are more than 4 crashes in it,
the init will regard it as a fatal system error and reboot the system.
Config `window=${zygote.critical_window.minute:-off}' and
`target=zygote-fatal' for all system-server services, so platform that
configures ro.boot.zygote_critical_window can escape the system-server
crash-loop via init fatal handler.
Bug: 146818493
Change-Id: Ib2dc253616be6935ab9ab52184a1b6394665e813
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
Introduce new command to allow setting task profiles from inside .rc
script. This is to replace usage of writepid when a service is trying
to join a cgroup. Usage example from a .rc file:
service surfaceflinger /system/bin/surfaceflinger
task_profiles HighPerformance
Bug: 155419956
Test: change .rc file and confirm task profile is applied
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I0add9c3b363a7cb1ea89778780896cae1c8a303c
There was an email thread about this recently, and I've been asked many
times.
For instance, if this error wasn't attributed, denials a service is
hitting would be attributed to init, and that's a recipe for disaster.
Secondarily, thinking about SELinux whenever you write a new service is
good.
Bug: N/A
Test: N/A
Change-Id: Ib9d2c5d8947375a0d4c33ecf3d075caef6b41f70
Users of libinit_test_utils must include all libraries that it uses.
If it uses libinit, then there is a large number of libraries that
must be included. To avoid this, make libinit_test_utils only use
init_common_sources and the small number of required libraries that go
along with those sources. Additionally, expose these sources as a
default for users of libinit_test_utils.
Test: build
Change-Id: I224fa7e0590d073e4cd40412b5dcb6f72a64b6bf
Since I was there, added two more properties to reset, and switched
ordering of sys.init.updatable_crashing and
sys.init.updatable_crashing_process_name setprops to make sure that
process name is already set when apexd/PackageWatchdog get's notified
about sys.init.updatable_crashing.
Also fixed a typo in what HandleUserspaceReboot function.
Test: adb reboot userspace
Bug: 135984674
Change-Id: I954ec49aae0734cda1bd833ad68f386ecd808f73
As part of Watchdog-triggered rollback logging, it would
be useful to know the service which has caused
updatable_crashing to be set. Store this in a new property
sys.init.updatable_crashing_process_name.
Test: manual
Bug: 138782888
Change-Id: Iffa38b2b746abbb5d823a8d69b7b8d2456836f4e
Such services will be re-parsed and added back to the service list
during post-fs-data stage.
Test: adb reboot userspace
Test: atest CtsInitTestCases
Bug: 145669993
Bug: 135984674
Change-Id: Ibb393dfe0f101c4ebe37bc763733fd5d981d3691
Init is no longer a special case and talks to property service just
like every other client, therefore move it away from property_set()
and to android::base::SetProperty().
In doing so, this change moves the initial property set up from the
kernel command line and property files directly into PropertyInit().
This makes the responsibilities between init and property services
more clear.
Test: boot, unit test cases
Change-Id: I36b8c83e845d887f1b203355c2391ec123c3d05f
~2007 a change was added that would allow oneshot services to
daemonize by not killing their process group. This was a hack at the
time, and should certainly not be needed now. I've resisted removing
the behavior however, as it hadn't caused any issues.
Recently, it was detected that the cgroups that these processes belong
to, would exist forever and therefore leak memory. Instead of simply
removing the cgroups when empty, this provides a good opportunity to
do the right thing and fix this behavior once and for all.
The new (correct) behavior only happens for devices with vendor images
built for Android R or later. Init will log a warning to dmesg when
it detects this difference in behavior has occurred.
Bug: 144545923
Test: boot CF/Coral and see no difference in behavior.
Test: boot CF with a service that daemonizes and see the warning.
Change-Id: I333a2e25a541ec0114ac50ab8ae7f1ea3f055447
Previously, we assumed that TriggerShutdown() should never be called
from vendor_init and used property service as a back up in case it
ever did. We have since then found out that vendor_init may indeed
call TriggerShutdown() and we want to make it just as strict as it is
in init, wherein it will immediately start the shutdown sequence
without executing any further commands.
Test: init unit tests, trigger shuttdown from init and vendor_init
Change-Id: I1f44dae801a28269eb8127879a8b7d6adff6f353
init should be able to register native services with lmkd so that they
can be killed when needed. Only processes with oom_score_adjust not
equal to the default -1000 will be registered with lmkd because with the
score that low the process is unkillable anyway.
Inform lmkd when a registered process is killed so that the record can be
removed.
Change init.rc to start lmkd during init phase so that it is there to
register other services.
Replace hardcoded oom_score_adj values with appropriate definitions.
Bug: 129011369
Test: boot and verify native service registration
Change-Id: Ie5ed62203395120d86dc1c8250fae01aa0b3c511
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Especially now that property_service is a thread, there may be some
delay between when init sets sys.powerctl and when the main thread of
init receives this and triggers shutdown. It's possible that
outstanding init commands are run during this gap and that is not
desirable.
Instead, have builtins call TriggerShutdown() directly, so we can be
sure that the next action that init runs will be to shutdown the
device.
Test: reboot works
Test: reboot into recovery due to bad /data works
Change-Id: I26fb9f4f57f46c7451b8b58187138cfedd6fd9eb
This property will need to be reset during userspace reboot, so it can't
be a read-only property anymore.
Test: builds
Bug: 135984674
Change-Id: I4e079b537cb5c725ac0b652804fdc801a6facfcf
There is a race condition with Service::Start and socket creation.
Since socket creation currently happens after the fork(), it's
possible that init can continue executing other commands before the
socket is created. If init starts another service that relies on that
socket, it isn't guaranteed to be available.
Particularly, we've seen this with hwservicemanager starting after
logd, but hwservicemanager's logs sometimes not showing up.
Bug: 140810300
Test: boot and logging functions correctly
Change-Id: Ib2932e836d345830cd38f3b556598508fd953058
This replaces the recently added `exec_reboot_on_failure` builtin, since
it'll be cleaner to extend service definitions than extending `exec`.
This is in line with what we decided when adding `exec_start` instead
of extending `exec` to add parameters for priority.
Test: `exec_start` a service with a reboot_on_failure option and watch
the system reboot appropriately when the service is not found and when
the service terminates with a non-zero exit code.
Change-Id: I332bf9839fa94840d159a810c4a6ba2522189d0b
mounted.
Necessary to make e.g. bootanimation work, which depends on (at least)
libandroidicu.so in the ART APEX.
Test: Build & boot
Bug: 135753770
Exempt-From-Owner-Approval: Approved internally
Change-Id: Ibab4f5f7a243d0815b9c70a537bae8d77dee2fbb
Merged-In: Ibab4f5f7a243d0815b9c70a537bae8d77dee2fbb
* changes:
Adds new property for service name -> PID.
Adds a library to parse service info from init_rc files for use in tests.
Adds a visibility rule for init defaults.
Host init verifier already checks that the names and number of
arguments for builtins are correct, but it can check more. This
change ensures that property expansions are well formed, and that
arguments that can be parsed on the host are correct. For example it
checks that UIDs and GIDs exist, that numerical values can be parsed,
and that rlimit strings are correct.
Test: build
Change-Id: Ied8882498a88a9f8324db6b8d1020aeeccc8177b
It's better to pass the error message to the caller to determine how
best to print the error.
Test: build
Change-Id: Id8857c459df2f26c031650166609608d20e4d051
clang-tidy hinted that some of this code wasn't right. Looking
deeper, there is really not much related to file and socket
descriptors, except that they're published in similar ways to the
environment. All of the abstraction into a 'Descriptor' class takes
us further away from specifying what we really mean.
This removes that abstraction, adds stricter checks and better errors
for parsing init scripts, reports sockets and files that are unable to
be acquired before exec, and updates the README.md for the passcred
option.
Test: build, logd (uses files and sockets) works
Change-Id: I59e611e95c85bdbefa779ef69b32b9dd4ee203e2
android-base:
* Add NOLINT for expanding namespace std for std::string* ostream
overload
libdm:
* Fix missing parentesis around macro parameters
init:
* Fix missing CLOEXEC usage and add NOLINT for the intended
usages.
* Fix missing parentesis around macro parameters
* Fix erase() / remove_if() idiom
* Correctly specific unsigned char when intended
* 'namespace flags' should be signed, since 'flags' it signed for
clone()
* Add clear to property restore vector<string> to empty after move
* Explicit comparison against 0 for strcmp
Test: build
Change-Id: I8c31dafda2c43ebc5aa50124cbbd6e23ed2c4101
There's no fundamental reason to store this aside. That property can
only be written by init, so it's not likely that we're going to
corrupt it.
Test: boot and use serial console
Change-Id: I9248fbaf959ea913d09add829d4cb509af99d570
Init had some pretty horrid Error() << StringPrintf(...) calls that
are all much better replaced by Errorf(...) now.
Test: build, check that keyword_map errors look correct
Change-Id: I572588c7541b928c72ae1bf140b814acdef1cd60
Now that Result<T> is actually expected<T, ...>, and the expected
proposal states expected<void, ...> as the way to indicate an expected
object that returns either successfully with no object or an error,
let's move init's Result<Success> to the preferred Result<void>.
Bug: 132145659
Test: boot, init unit tests
Change-Id: Ib2f98396d8e6e274f95a496fcdfd8341f77585ee
The Result, Error, ErrnoError are quite generic. Moving them from init
to libbase so that they can be used from other places.
Bug: 132145659
Test: libbase_test
Change-Id: Id774a587f74380fadd7a0fc88c0aa892c3d9a489
Factors out utility functions into service_utils.h/cpp, so that they
can be reused by the upcoming native zygote.
Bug: 133443795
Test: Build and boot cuttlefish.
Change-Id: I0531b6f17561119c8cc33dd9ba375b351747fcfe
When TARGET_FLATTEN_APEX is true (= ro.apex.updatable is unset or set to
false), apexd is not used to activate the built-in flattened APEXes.
Init simply bind-mounts /system/apex to /apex.
However, there is a special case here. The runtime APEX is installed as
either /system/apex/com.android.runtime.debug or
/system/apex/com.android.runtime.release, whereas it should be activated
on /apex/com.android.runtime - without the .debug or .release suffix.
To handle that case, the build system creates an empty directory
/system/apex/com.android.runtime and the .debug or .release directory
is bind-mounted to the empty directory by init at runtime.
This change also fixes a minor bug that native watchdog is triggered
for all post-apexd processes regardless of whether ro.apex.updatable
is true or not. Since apexd is expected to shutdown itself when ro.apex
.updatable is false, we don't trigger the watchdog in that case.
Bug: 132413565
Bug: 133305381
Test: marlin and sdk_gphone are bootable
Merged-In: I219465b8b81decb960e2c5f46bab6e0768b31317
Change-Id: I219465b8b81decb960e2c5f46bab6e0768b31317
(cherry picked from commit f93088ba2b)
Android-base has an implementation of the future std::expected<>.
This provides the same baseline functionality as Result<>, so use it
instead of our own version.
Bug: 132145659
Test: boot, init unit tests
Change-Id: I11e61bcb5719b262a6420483ed51a762826a9e23
This keyword was introduced to support restarting services on devices
using APEX and FDE. The current implementation is not a restart, but
rather a 'reset' followed by a 'start', because the real /data must be
mounted in-between those two actions. But we effectively want this to be
a restart, which means that we also want to start 'disabled' services
that were running at the time we called 'class_reset_post_data'.
To implement this, keep track of whether a service was running when its
class was reset at post-data, and start all those services.
Bug: 132592548
Test: manual testing on FDE Taimen
Change-Id: I1e81e2c8e0ab2782150073d74e50e4cd734af7b9
Merged-In: I1e81e2c8e0ab2782150073d74e50e4cd734af7b9
