It turned out to be tricker than I first thought. First of all, if I rebooted the device it passed.

Here is my repro steps.

1) run `test_that login_Cryptohome.py` without any patch; it fails because of  Bug 688258 .

2) Apply the following rough patch to fix  Bug 688258 :

diff --git a/client/cros/constants.py b/client/cros/constants.py
index d2fbbbbce..832a9d3bd 100644
--- a/client/cros/constants.py
+++ b/client/cros/constants.py
@@ -46,9 +46,11 @@ SHADOW_ROOT = '/home/.shadow'
 CRYPTOHOME_DEV_REGEX_ANY = r'.*'
 CRYPTOHOME_DEV_REGEX_REGULAR_USER_SHADOW = r'^/home/\.shadow/.*/vault$'
 CRYPTOHOME_DEV_REGEX_REGULAR_USER_EPHEMERAL = r'^ephemeralfs/.*$'
-CRYPTOHOME_DEV_REGEX_REGULAR_USER = r'(%s|%s)' % (
-    CRYPTOHOME_DEV_REGEX_REGULAR_USER_SHADOW,
-    CRYPTOHOME_DEV_REGEX_REGULAR_USER_EPHEMERAL)
+CRYPTOHOME_DEV_REGEX_REGULAR_USER_DEVICE = r'^/dev/.*$'
+CRYPTOHOME_DEV_REGEX_REGULAR_USER = r'(%s|%s|%s)' % (
+   CRYPTOHOME_DEV_REGEX_REGULAR_USER_SHADOW,
+   CRYPTOHOME_DEV_REGEX_REGULAR_USER_EPHEMERAL,
+   CRYPTOHOME_DEV_REGEX_REGULAR_USER_DEVICE)

3) run `test_that login_Cryptohome.py` again. ==> It reproduces the failure I originally reported.

4) If I reboot and run `test_that login_Cryptohome.py` again. ==> the test passes.


So, it doesn't block my autotest fix effort.
However, it may or may not be indicating a potential problem in real use case.

Actually my environment has yet another hack (for avoiding  Bug 686611 ) that when restarting UI,
the environment does not kill process opening files on cryptohome.
Such processes should be usually killed, so there may be a chance that that is making the thing bad.

Anyway, we probably should revisit this only after the two obstacles are resolved...

Minimized repro step:

$ cryptohome --action=mount --user=test@test.test --password=testme --async --create
$ restart cryptohomed
$ cryptohome --action=mount --user=test@test.test --password=testme --async --create

Even with --direncrypt disabled, the Mount fails at a different point so it may be ok.


For some reason, on ext4crypto, cryptohomed is killed by somebody and hence reaching the state.
There may be a similar cause like  crbug.com/686611  ...

2017-02-08T07:31:48.991034+00:00 WARNING kernel: [   79.650009] init: cryptohomed main process (1686) killed by TERM signal

My bad. The steps above was actually causing a different failure. What I really saw was:

$ cryptohome --action=mount --user=test@test.test --password=testme --async --create
$ restart cryptohomed
$ restart chapsd
$ cryptohome --action=mount --user=test@test.test --password=testme --async --create


I still don't know who is killing chapsd and cryptohomed at test shutdown...

After "keyctl clear $(keyctl search @s keyring dircrypt)", cryptohome --action=mount succeeds.
It seems add_key syscall is failing when the key being added is already present on the keyring.
We can fix this by clearing the dircrypto keyring when restarting cryptohomed.

I finally found who is killing cryptohomed and chapsd
https://chromium.googlesource.com/chromiumos/third_party/autotest/+/master/client/cros/tpm_dam.py#60
which is called from
https://chromium.googlesource.com/chromiumos/third_party/autotest/+/master/client/bin/site_sysinfo.py#379


So, this is basically expected to happen. It should have happened on ecryptfs-based cryptohome but probably my eyes got crazy and missed that from the log.

In summary, this is not a regression.
Being more robust to service restart sounds good to me, so the suggestion in #7 still may be nice to have, though.

Made a CL: https://chromium-review.googlesource.com/c/439828/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/de3b59e96eadb718fb539d10237c535a1ec31fe2

commit de3b59e96eadb718fb539d10237c535a1ec31fe2
Author: Ryo Hashimoto <hashimoto@google.com>
Date: Fri Feb 10 12:13:59 2017

cryptohome: Allow root to write and setattr the encryption key

We may need to change the state of the key when cryptohome restarts.

BUG= chromium:689381 
TEST=Manually following the steps in the comment #6 of the bug.

Change-Id: I762e30a9ae70f678beb126799730320638bb0eda
Reviewed-on: https://chromium-review.googlesource.com/439828
Commit-Ready: Ryo Hashimoto <hashimoto@chromium.org>
Tested-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>

[modify] https://crrev.com/de3b59e96eadb718fb539d10237c535a1ec31fe2/cryptohome/platform.cc

login_Cryptohome is passing on M58 caroline