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
Before, if updatable processes crash 4 times in 4mins, a native
rollback will be attempted. This behavior does not detect
system_server early boot deadlocks because the system server requires
at least a min to detect a deadlock, and crash itself. The crashes
don't happen frequently enough for init to detect.
After, this cl, the old behavior exists and additionally, init detects
*any* 4 crashes of updatable processes before boot completed,
regardless of if they happen within 4mins or not.
Test: Manually tested by adding artificial sleep in system_server so
deadlock is triggered before boot. system_server crashes 4 times in
over 4mins and the ro.init.updatable_crashing prop is set to 1.
Bug: 129597207
Change-Id: Ie6fb5693ff4be105bcbe139c22850fb076e40260
On devices that use FDE and APEX at the same time, we need to bring up a
minimal framework to be able to mount the /data partition. During this
period, a tmpfs /data filesystem is created, which doesn't contain any
of the updated APEXEs. As a consequence, all those processes will be
using the APEXes from the /system partition.
This is obviously not desired, as APEXes in /system may be old and/or
contain security issues. Additionally, it would create a difference
between FBE and FDE devices at runtime.
Ideally, we restart all processes that have started after we created the
tmpfs /data. We can't (re)start based on class names alone, because some
classes (eg 'hal') contain services that are required to start apexd
itself and that shouldn't be killed (eg the graphics HAL).
To address this, keep track of which processes are started after /data
is mounted, with a new 'mark_post_data' keyword. Additionally, create
'class_reset_post_data', which resets all services in the class that
were created after the initial /data mount, and 'class_start_post_data',
which starts all services in the class that were started after /data was
mounted.
On a device with FBE, these keywords wouldn't be used; on a device with
FDE, we'd use them to bring down the right processes after the user has
entered the correct secret, and restart them.
Bug: 118485723
Test: manually verified process list
Change-Id: I16adb776dacf1dd1feeaff9e60639b99899905eb
This catches a common mistake where client code checks for errors using
the common idiom that works for std::iostream and other file-like
classes:
unique_fd fd = open(...);
if (!fd) {
}
Test: atest libbase_test
Test: m droid
Change-Id: I9629a7795537ecb3b57be9c741c06f80967e4cc2
Allow having properties in 'file' option of a service.
Test: boots (sanity)
Test: lpdumpd
Bug: 126233777
Change-Id: I55158b81e3829b393a9725fd8f09200690d0230f
In particular, this allows services running as the root user to have
capabilities removed instead of always having full capabilities.
Test: boot device with a root service with an empty capabilities
option in init showing no capabilities in /proc/<pid>/status
Change-Id: I569a5573ed4bc5fab0eb37ce9224ab708e980451
Remove hardcoded cpuset path usage and replace it with a request to
get the path using new API.
Exempt-From-Owner-Approval: already approved in internal master
Bug: 111307099
Test: builds, boots
Change-Id: I211d093c24a682e2d1992c08e4c1d980379711a4
Merged-In: I211d093c24a682e2d1992c08e4c1d980379711a4
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
This CL fixes the design problem of the previous mechanism for providing
the bootstrap bionic and the runtime bionic to the same path.
Previously, bootstrap bionic was self-bind-mounted; i.e.
/system/bin/libc.so is bind-mounted to itself. And the runtime bionic
was bind-mounted on top of the bootstrap bionic. This has not only caused
problems like `adb sync` not working(b/122737045), but also is quite
difficult to understand due to the double-and-self mounting.
This is the new design:
Most importantly, these four are all distinct:
1) bootstrap bionic (/system/lib/bootstrap/libc.so)
2) runtime bionic (/apex/com.android.runtime/lib/bionic/libc.so)
3) mount point for 1) and 2) (/bionic/lib/libc.so)
4) symlink for 3) (/system/lib/libc.so -> /bionic/lib/libc.so)
Inside the mount namespace of the pre-apexd processes, 1) is
bind-mounted to 3). Likewise, inside the mount namespace of the
post-apexd processes, 2) is bind-mounted to 3). In other words, there is
no self-mount, and no double-mount.
Another change is that mount points are under /bionic and the legacy
paths become symlinks to the mount points. This is to make sure that
there is no bind mounts under /system, which is breaking some apps.
Finally, code for creating mount namespaces, mounting bionic, etc are
refactored to mount_namespace.cpp
Bug: 120266448
Bug: 123275379
Test: m, device boots, adb sync/push/pull works,
especially with following paths:
/bionic/lib64/libc.so
/bionic/bin/linker64
/system/lib64/bootstrap/libc.so
/system/bin/bootstrap/linker64
Change-Id: Icdfbdcc1efca540ac854d4df79e07ee61fca559f
This reverts commit c661b660fe.
Reason: Breaks some 3p apps.
Bug: 122920047
Test: run the app, login.
Change-Id: Ie56ea5516887b885579764929e82e4fe684a7dcf
This reverts commit 2599088ff6.
Reason: Breaks some 3p apps.
Bug: 122920047
Test: run the app, login.
Change-Id: Idea332b1f91e9d2ac6ebd3879da7820c8ba2284f
This reverts commit 5ab1300481.
Reason: Breaks some 3p apps.
Bug: 122920047
Test: run the app, login.
Change-Id: Iec3347d7f35fbb6f32fd1192135a0cf87dc123a7
I7d47ea1223f7792a834981c729694242ab3f28c9 tried to identify processes that crash
after apexd is ready by introducing an 'updatable' class. However, after
I7ca67755dc0656c0f0c834ba94bf23ba9b1aca68 we now have a pre_apexd_ field we can
reuse instead of introducing a new class type.
Bug: 120598832
Test: Killing a !pre_apexd_ process 4 times in 4mins sets the
ro.init.updatable.crashing prop while killing a pre_apexd_ process reboots
into the bootloader
Change-Id: Icb9f405b9b54d11546bbf6d3bc28212936a78b0e
It is causing problem to the sdcardfs. Specifically, re-mounting events
for /mnt/runtime/{runtime|write} done by the vold process (which is a
pre-apexd process) are not being propagated to other mount namespaces.
As a result, SDCard access isn't working.
The propagation problem is a bug in sdcardfs which is fixed by [1].
However, we can't make all Android devices to have the patch at the same
time. Therefore, by default the separate mount namespace is not created
and will be created only for the devices where the kernel patches are in and
ro.apex.bionic_updatable sysprop is set to true.
[1]
d73d07673edbdbe78e1a7d00e7827ba9bfd86a59 ("ANDROID: mnt: Fix next_descendent")
b5858221c1c4f4bdc9ef67eb75ecf22580368820 ("ANDROID: mnt: remount should propagate to slaves of slaves")
Bug: 122559956
Test: m
Test: device boots
Test: sdcard works (e.g. camera can take pictures)
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Change-Id: I7a309bab46356ee5782f34c5963d1760963c0b14
This change makes the bionic libs and the dynamic linker from the
runtime APEX (com.android.runtime) available to all processes started
after apexd finishes activating APEXes.
Specifically, the device has two sets of bionic libs and the dynamic
linker: one in the system partition for pre-apexd processes and another
in the runtime APEX for post-apexd processes. The former is referred as
the 'bootstrap' bionic and are located at
/system/lib/{libc|libdl|libm}.so and /system/bin/linker. The latter is
referred as the 'runtime' bionic and are located at
/apex/com.android.runtime/lib/bionic/{libc|libdl|libm}.so and
/apex/com.android.runtime/bin/linker.
Although the two sets are located in different directories, at runtime,
they are accessed via the same path: /system/lib/* and
/system/bin/linker ... for both pre/post-apexd processes. This is done
by bind-mounting the bootstrap or the runtime bionic to the same path.
Keeping the same path is necessary because there are many modules and
apps that explicitly or implicitly depend on the fact that bionic libs
are located in /system/lib and are loaded into the default linker
namespace (which has /system/lib in its search paths).
Before the apexd is started, init executes a built-in action
'prepare_bootstrap_bionic' that bind-mounts the bootstrap bionic to the
mount points. Processes started during this time are provided with the
bootstrap bionic. Then after the apexd is finished, init executes
another built-in action 'setup_runtime_bionic' which again mounts the
runtime bionic to the same mount points, thus hiding the previous mounts
that target the bootstrap bionic. The mounting of the runtime bionic
(which is only for post-apexd processes) is hidden from pre-apexd
processes by changing propagation type of the mount points to 'private'
and execute the pre-apexd processes with a new mount namespace using
unshare(2). If a pre-apexd process crashes and re-launched after the
apexd is on, the process still gets the bootstrap bionic by unmounting
the runtime bionic which effectively un-hides the previous bind-mounts
targeting the bootstrap bionic.
Bug: 120266448
Test: device boots
Test: cat /proc/`pidof zygote`/mountinfo shows that
/system/lib/{libc|libdl|libm}.so and /system/bin/linker are from the
runtime APEX
Test: cat /proc/'pidof vold`/mountinfo shows that the same mount points
are from system partition.
Change-Id: I7ca67755dc0656c0f0c834ba94bf23ba9b1aca68
Critical processes currently cause the device to reboot into recovery when they
crash 4 times in 4mins.
We extend this feature to a new 'updatable' class of init services.
If these services crash 4 times in 4mins, instead of rebooting into bootloader,
we set ro.init.updatable_crashing to '1'. apexd and update_verifier will
listen to that property and try to abort and rollback updates, staged apex
modules and new slots respectively.
Test: Tested manually by marking zygote as updatable and killing zygote
frequently, verified that property is set.
Bug: 120598832
Change-Id: I7d47ea1223f7792a834981c729694242ab3f28c9
