While mount_all and umount_all were updated to use ro.boot.fstab_suffix,
I neglected to update swapon_all. Trivially copied from umount_all.
Bug: 142424832
Change-Id: Icd706fe7a1fe16c687cd2811b0a3158d7d2e224e
Merged-In: Icd706fe7a1fe16c687cd2811b0a3158d7d2e224e
Currently the ReadDefaultFstab function, which calls GetFstabPath,
makes some assumptions about what the fstab will be called and where
it is located. This is being used by vold to set up userdata encryption
and for gsid, and is even used in the default boot control HAL, so it
has become quite baked.
The original way for a board to specify things to mount was to use the
"mount_all /path/to/fstab" command in init.rc. However, due to the
above functionality, the path after mount_all is no longer very useful,
as it cannot differ from the inferred path, or userdata encryption and
other features will be broken.
On Cuttlefish, we have an interest in being able to test alternative
userdata configurations (ext4 vs f2fs, encryption on/off, etc.) and
currently the only way to achieve this is to either a) modify the
ro.hardware or ro.hardware.platform properties, which breaks a bunch
of things like default HAL filenames, or regenerate our odm.img or
vendor.img filesystems. We can't simply install another fstab and
point to it with "mount_all".
This change allows the fstab path to be omitted from "mount_all", and
adds another property which overrides the existing checks for
fstab.${ro.hardware} and fstab.${ro.hardware.platform}. Specifying
${ro.boot.fstab_suffix} will cause fstab.${ro.boot.fstab_suffix}
to be checked first.
Bug: 142424832
Test: booted cuttlefish with 'mount_all ${ro.hardware} --late'
Test: booted cuttlefish with 'mount_all --late'
Test: booted cuttlefish with 'mount_all --late' and fstab_suffix=f2fs
Test: partially booted cuttlefish with 'mount_all ${ro.hardware}'
Test: partially booted cuttlefish with 'mount_all'
Change-Id: I3e10f66aecfcd48bdb9ebf1d304b7aae745cbd3c
A one second timeout is so coarse and can affect boot time when
the possibility that the file does not exist. Switch to accepting
a floating point number for seconds for the wait for file command.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 151950334
Test: wait_for_file sleep 0.05 reports an appropriate delay
Change-Id: I8d8ed386519ab54270b05ce91663d0add30f12e7
This is apparently causing problems with reboot.
This reverts commit 7205c62933.
Bug: 150863651
Test: build
Change-Id: Ib8a4835cdc8358a54c7acdebc5c95038963a0419
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
Instead they will be logged from system_server. This CL just prepares
grounds for logging CL to land.
Test: adb reboot userspace
Bug: 148767783
Change-Id: Ie9482ef735344ecfb0de8a37785d314a3c0417ff
This gives search (x) permission on the parent apex data
directory /data/misc/apexdata so that directories below it
may be opened. It also gives that permission on the apex
data directories themselves.
Bug: 147848983
Test: Build & flash, check perms are correct
Change-Id: I27c4ea01602002c89d0771a144265e3879d9041a
In case one of the cryptfs calls to vdc fails, first try a normal
reboot.
Test: manual
Bug: 135984674
Bug: 143970043
Change-Id: I5706d9cd6c3a08fa06329ffb7d141de632620e3d
The apex data directories must be accessed by apexd in order for it to
perform snapshot and restore as part of the rollback process. As apexd
runs as root, this CL changes the apex data directories under /data/misc
to be owned by root.
Bug: 141148175
Test: Build and flash; check permissions are set correctly.
Change-Id: Ib534e705802c06900884a15f39fee257d4987f4c
Current linkerconfig targets for specific output file. However,
linkerconfig will generate more than 1 file based on APEX modules, so it
should take argument for target directory rather than target file. This
change updates linkerconfig's argument to point output directory.
Bug: 146993126
Test: m -j passed & Cuttlefish succeeded to boot
Change-Id: I3a720a047077688582436aabd307adafeafc5398
There are two namespaces from init - bootstrap and default - and those
will have different set of APEX modules. To support difference between
two namespaces, linker config should be generated per namespace and each
namespace should use its own linker configuration. As a first step of
the work, this change will create different mount point for each
namespace, and re-generate linker config after APEX mount from each
namespaces.
Bug: 144664390
Test: m -j passed & tested from cuttlefish
Change-Id: Iac2e222376ec4b0ced6c29eed18b21d39ff0b1ba
This creates the directory /data/misc/apexdata, at the same time as other
directories under /data/misc. Then, when apexd has finished activating
APEXes, a directory is created under /data/misc/apexdata for every
APEX, with the same name as the APEX module name.
See go/apex-data-directories.
APEXes are discovered by scanning the /apex directory. It may be better
to delegate this process to a library, but it is proposed to defer that
change to a future CL.
Bug: 141148175
Test: Built and flashed, checked directories were created.
Change-Id: I639d6f490ae0b97f116ce38ff3ac348bd73aa20e
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
During userspace reboot FscryptInstallKeyring will be called again, this
CL will make it second call a no-op, which IMHO is better than having a
special logic in init to conditionally call FscryptInstallKeyring
depending on whenever it's normal boot, or userspace reboot.
Test: adb reboot userspace
Test: checked in kernel logs that new keyring is not created
Bug: 135984674
Change-Id: I4ad5aee6887b7318fb1cd02bf1c7be8da6ece599
sys.init.userspace_reboot.in_progress will be used to notify all
the processes (including vendor ones) that userspace reboot is
happening, hence it should be treated as stable public api.
All other sys.init.userspace_reboot.* props will be internal to /system
partition and don't require any stability guarantees.
Test: builds
Test: adb reboot userspace
Bug: 135984674
Change-Id: Ifb64a6bfae2de76bac67edea68df44e33c9cfe2d
There will be useful in debugging/logging events to statsd.
Also as part of this CL, sys.init.userspace_reboot.in_progress property
is now used as a mean of synchronization. It is set directly in
DoUserspaceReboot, to make sure that all the setprop actions triggered
by userspace-reboot-requested were processed.
Test: adb reboot userspace
Test: adb shell getprop sys.init.userspace_reboot.last_started
Test: adb shell getprop sys.init.userspace_reboot.last_finished
Bug: 135984674
Change-Id: I9debcd4f058e790855200d5295344dafb30e496a
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
From the implementation of FscryptInstallKeyring it looks like it will
install a new keyring on each call.
Another approach would be change FscryptInstallKeyring to first call
request_key[0] (http://man7.org/linux/man-pages/man2/request_key.2.html),
and don't add keyring in case request_key succeeded, but it looks like
that libkeyutils doesn't provide such functionality.
Since I was there, I've also added checks that we are not trying to
remount userdata on FDE devices.
Test: adb reboot userspace
Bug: 135984674
Change-Id: I2e063d7d87a3c2c26810e913a33e3a5c0364332b
FscryptSetDirectoryPolicy no longer tries to infer the action from the
filename. Well mostly; it still assumes top-level directories in /data
should be encrypted unless the mkdir arguments say otherwise, but
it warns.
Bug: 26641735
Test: boot, check log messages
Change-Id: Id6d2cea7fb856f17323897d85cf6190c981b443c
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 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
Add exec_reboot_on_failure builtin and refactor the VDC commands that
had similar functionality. These will now also reboot in the case
that the program cannot be found or run for any reason.
Test: boots normally, reboots if command is not found or if command
returns status '1'
Change-Id: I1c99498c2b741512a50188e1a325c25e9ec8fba0
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
Use lstat(), and then make only the system calls needed to fix the
directory up.
Bug: 140027478
Test: boots twice, no worrying log messages.
Change-Id: I1c1445baae3ec1c1ce17626ede388aa04d5f7781
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
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
Previously we were ignoring ENOENT from all builtins as
rootdir/init.rc has many legacy commands that we need to keep for
backwards compatibility, but are otherwise no longer relevant.
However, this wasn't catching actual issues, for example chown failing
due to not finding the user or group name. This change therefore
reduces the scope of ignoring ENOENT to the only the extraneous errors
in builtins.
Test: boot CF and walleye without seeing errors from init.rc
Test: see errors from invalid users/groups in chown
Change-Id: Ia8e14fa2591e083cb1736c313a3e55515bc5d15e
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
For devices that use FDE and don't support updatable APEXes, don't
stop and restart all processes - there is no need and it only increases
boot time for these devices.
Additionally, some daemons have never been restarted in the past, and
restarting them exposes certain issues.
Bug: 137251597
Bug: 136777273
Bug: 135627804
Test: verified manually w/ ro.updatable.apex=false
Change-Id: I9590f2c2cdfab0a49f39846896460305d44221ee
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
In retrospect, these always should have been header only. We don't
need setgroups() anymore either, since we have the right symbols now.
Test: build
Change-Id: If6fbf6f8ee288ed261576207d90a7ec5674853f9
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
