There is no reason for these scripts to continue to exist in /, when
they are better suited for /system/etc. There are problems keeping
them at / as well, particularly that they cannot be updated with
overlayfs.
Bug: 131087886
Bug: 140313207
Test: build/boot
Merged-In: I043d9a02ba588ca37ceba2c4e28ed631792b2586
Change-Id: I043d9a02ba588ca37ceba2c4e28ed631792b2586
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 CL only draws boundaries between userspace and full reboots, and
adds some functionality that will be required for userspace reboot:
* Whenever device is shutting down is now controlled in reboot.cpp,
since during userspace reboot this state can change.
* Now it's also possible to restart handling of control messages inside
property service. In case of userspace reboot, init will restart it
after stopping post-data services.
* New userspace-reboot-requested trigger is added similar to shutdown
one for full reboot.
Test: adb reboot
Test: adb reboot userspace
Bug: 135984674
Change-Id: Id55a53ba781d2b90ce40449037b6d8d47e72c476
This code is more generic than it needs to be and one of the side
effects is that an extra init process is forked for odm_init, despite
it having the same context as vendor_init. I don't think anything is
going to change regarding that soon, so this change stops forking that
extra process to save its memory and simplifies the code overall.
Bug: 141164879
Test: init still uses vendor_init for vendor_scripts
Test: init unit tests
Test: init only has one subcontext process
Change-Id: I0d224455604a681711e32f89fb20132378f69060
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
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command. This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.
This change has init run property service in a thread, which
eliminates the above issue.
This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.
Reland: during reboot, init stops processing property_changed messages
from property service, since it will not act on these anyway. This
had an unexpected effect of causing future property_set calls to block
indefinitely, since the buffer between init and property_service was
filling up and the send() call from property_service would then
block. This change has init tell property_service to stop sending it
property_changed messages once reboot begins.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I26902708e8be788caa6dbcf4b6d2968d90962785
Added in af1a9bfb8f, but it's never been
used in practice because of the performance impact, and it's incompatible
with our ability to add new system calls via a bionic module update
because it defaults to disabling all unknown syscalls, and init will
still be using the non-updated bootstrap libc from when it first shipped.
Test: treehugger
Change-Id: I8e396675fcfaf0218a92f464d15e613f43319305
Instead of init.cpp knowning about the boringssl self
test, use init.rc to exec dedicated self test executables.
Advantages:
- The self test is run not only both the copy of libcrypto
in /system but also /apex/com.android.conscrypt.
- The self test is run not only for the primary (e.g. 64bit)
ABI but also for a secondarry (e.g. 32bit) ABI.
- The dependency on libcrypto is kept to the self test binary.
- The self test binary abstracts the exact native API for
running the self test (this will change soon because the
self test will be run when the library is loaded).
Bug: 137267623
Test: Check that logcat shows both binaries being started as root,
and finishing with exit code 0.
Change-Id: I1e716749ee2133993f0f7b2836483391fd1a62f0
There is a race that manifests like this:
1) A service dies (not processed by init yet).
2) service_manager processes death notification.
3) service_manager gets checkService and calls init to start service.
4) init gets the ctl.start / ctl.interface_start for the service
but the service already appears started, so it does nothing.
5) init gets sigchld, but doesn't do anything else to restart the
service
We can avoid all of this if we already reap pending processes before
handling properties in the main loop of init. Since reaping the
services calls waitid(), there's no race even if the signalfd for
sigchld hasn't triggered yet. It also won't cost us much efficiency,
since it's only a single system call.
Test: CF boots, init unit tests pass
Change-Id: Ie24ef406055b283797b41b1821c8ebcccead4db4
As part of debugging long run issue we are enabling
module info as part of debug build under the config key
DEBUG_MODULE_LOAD_INFO , But doing so can lead to info leak
as modules/dlkm are loaded in early-init and setting the
kptr_restriction is done after early-init.
So moving setting of kptr_restrict much before early-init.
Bug: 138641073
Change-Id: Ic3c0ca57a94c8b20136a15331dd646bd8825b625
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command. This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.
This change has init run property service in a thread, which
eliminates the above issue.
This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I13b8bf240c9fcb1d2d5890a8be2f0ef74efd4adf
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command. This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.
This change has init run property service in a thread, which
eliminates the above issue.
This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: Id9534a5916abb2f7d2a49cda54e33c1b69c50c2f
I've heard that keyword_map is too complex, in particular the tuple
and the pair in BuiltinFunctionMap, so this change removes a lot of
that complexity and, more importantly, better documents how all of
this works.
Test: boot, init unit tests
Change-Id: I74e5f9de7f2ec524cb6127bb9da2956b5f307f56
- unused
- using binder requires twoway calls (since getting a service from
servicemanager requires two calls)
Bug: 135768100
Test: N/A
Change-Id: Idc41f487bad2d8343e99ded98812f3a84e2b8e37
Test: Adding a misspelling to an init_rc's interface line and observing
build failure.
Bug: 77646540
Change-Id: I58f66d73f0bd9b4203e8259161843b56ad428d73
By moving it into builtins.cpp..., but that's less bad than it is
now, especially since this is defunct in code targeting Q+. Remove
the guards that init.h isn't being included by other files too as it's
not useful anymore.
Test: build
Change-Id: Ic564fcff9e8716ec924098b07a8c9d94ca25f960
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
Ueventd can't set properties currently, but this is an artificial
limitation, since ueventd communicates to init that it has finished
cold boot via a file, and init polls this file instead of returning to
the epoll loop, where properties are handled.
This change replaces that file with a property and thus frees ueventd
to be able to set properties.
Bug: 62301678
Test: boot, check that properties are set
Change-Id: I985688e9299456efcb2dfeef9b92668991aa9c05
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
This change factors out functions that handle selabels from
selinux.h/cpp into selabel.h/cpp. This allows util.cpp to be used by
the upcoming native zygote without a bunch of define flags that are
required for selinux.cpp.
Bug: 133443795
Test: Build and boot cuttlefish.
Change-Id: Ie238a96c6407c6698a605dd8803c1727abfaae7b
Dump init stacks when aborting either due to LOG(FATAL) or in
userdebug/eng builds due to signals, including signals from
sanitizers.
Doesn't work for static first stage init yet, b/133450393 tracks
that.
Also, ensure that LOG(FATAL) in child processes calls abort() in all
stages of init, not just 2nd stage init.
Bug: 131747478
Test: abort init in various ways and see stacks
Test: hang or crash in backtrace handler and see child reboot
Change-Id: Ib53b5d3e7e814244203f875de016ada9900dfce8
Add a property ro.boottime.init.first_stage to provide us a
first stage init duration from start to exec completed in
nanoseconds.
For consistency, report nanoseconds duration for
ro.boottime.init.selinux as well instead of milliseconds.
Now also report consistently from start to exec completed
instead of just the selinux load time.
SideEffects: ro.boottime.init.selinux is reported to TRON and
may alarm with the millionfold increase in precision.
ro.boottime.init is now also consistent with ns
precision.
Test: inspect
Bug: 124491153
Bug: 129780532
Change-Id: Iff4f1a3a1ab7ff0a309c278724c92da0832b9a69
In previous implementation, userdebug sepoilcy and property files are
loaded from the system.img. This CL changes this to:
- first-stage init copies userdebug files from ramdisk to /debug_ramisk/*
- second-stage init loads files from /debug_ramdisk/*.
Note: same as before, the above can only be triggered, if the device
is UNLOCKED
With this, we don't have to put userdebug related files into the USER
system.img.
Bug: 126493225
Test: boot device with a ramdisk with /force_debuggable, checks related
files are loaded
Change-Id: I63f5f846e82ba78427062bf7615c26173878d8f3
right now vendor_init is forked before we set oom_adj for init which
leaves a chance vendor_init could be killed in heavy memory pressure.
this CL set the oom_adj before forking everything to ensure all native
have correct oom_adj settings.
Fixes: 130824864
Test: procrank -o
Change-Id: I8af129076c3efa29f7b781459449f8f2dc853c98
Only init uses SetupCgroups. This functionality is
moved from libprocessgroup to its own library, and only
init links to it.
Also, merge CgroupSetupCgroups() with CgroupMap::SetupCgroups()
because the former is just an alias of the latter, and
CgroupMap does not belong to libcgrouprc_setup.
Test: boots
Bug: 123664216
Change-Id: I941dc0c415e2b22ae663d43e30dc7a464687325e
Merged-In: I941dc0c415e2b22ae663d43e30dc7a464687325e
SetupCgroups is called by init process during early-init stage and is not
supposed to be called again by anyone else. Ensure that the caller is the
init process, make sure cgroup.rc file is written only one time, keep the
file descriptor to cgroup.rc file open by the init process to ensure all
its further mappings stay valid even if the file is deleted.
Bug: 124774415
Test: build, run, verify no errors or warning in the logcat
Change-Id: Ib8822cf0112db7744e28d442182d54dcf06f46f2
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Set properties dev.mnt.blk.<mount_point>=<device_block_class> for mount
and umount operations by setting up an Epoll handler to catch
EPOLLERR or EPOLLPRI signals when /proc/mounts is changed. Only
update properties associated with block devices. For the mount
point of /, use the designation of /root instead.
Can use the properties in init rc expansion like:
on property dev.mnt.blk.root=*
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${boot_read_ahead_kb:-2048}
on property dev.mnt.blk.data=*
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${boot_read_ahead_kb:-2048}
on late-fs
setprop boot_read_ahead_kb 128
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${boot_read_ahead_kb}
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${boot_read_ahead_kb}
Test: boot and inspect getprop results.
Bug: 124072565
Change-Id: I1b8aff44f922ba372cd926de2919c215c40ee874
When init found "/force_debuggable" in the first-stage ramdisk, it will
do the following if the device is unlocked:
1. load /system/etc/adb_debug.prop (with ro.debuggable=1)
2 .load userdebug_plat_sepolicy.cil instead of original plat_sepolicy.cil from
/system/etc/selinux/.
This make it possible to run VTS on a USER build GSI, by using a special
ramdisk containing "/force_debuggable".
Bug: 126493225
Test: unlock a USER build device, check 'adb root' can work
Change-Id: I9b4317bac1ce92f2c0baa67c83d4b12deba62c92
Abstract usage of cgroups into task profiles that allows for changes
in cgroup hierarchy and version without affecting framework codebase.
Rework current processgroup and sched_policy API function implementations
to use task profiles instead of hardcoded paths and attributes.
Mount cgroups using information from cgroups.json rather than from init.rc
Exempt-From-Owner-Approval: already approved in internal master
Bug: 111307099
Test: builds, boots
Change-Id: If5532d6dc570add825cebd5b5148e00c7d688e32
Merged-In: If5532d6dc570add825cebd5b5148e00c7d688e32
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
Before, this process had no threadpool, so it could make blocking
calls, but if it did, they would block forever. Now when this
happens, an error is logged so that we can easily see this happen.
Bug: 36424585
Test: boot
Change-Id: I7d2fa12b6d5a243bdde13ce4d974a444133749f7
Tom Cherry