So far, we considered mount units activated as soon as the mount
appeared. This avoided seeing a difference between mounts started by
systemd, and e.g. by running `mount` from a terminal.
(`umount` was not handled this way).
However in some cases, options passed to `mount` require additional
system calls after the mount is successfully created. E.g. the
`private` mount option, or the `ro` option on bind mounts.
It seems best to wait for mount to finish doing that. E.g. in
the `private` case, the current behaviour could theoretically cause
non-deterministic results, as child mounts inherit the
private/shared propagation setting from their parent.
This also avoids a special case in mount_reload().
static const UnitActiveState state_translation_table[_MOUNT_STATE_MAX] = {
[MOUNT_DEAD] = UNIT_INACTIVE,
[MOUNT_MOUNTING] = UNIT_ACTIVATING,
- [MOUNT_MOUNTING_DONE] = UNIT_ACTIVE,
+ [MOUNT_MOUNTING_DONE] = UNIT_ACTIVATING,
[MOUNT_MOUNTED] = UNIT_ACTIVE,
[MOUNT_REMOUNTING] = UNIT_RELOADING,
[MOUNT_UNMOUNTING] = UNIT_DEACTIVATING,
Mount *m = MOUNT(u);
assert(m);
-
- if (m->state == MOUNT_MOUNTING_DONE) /* not yet ready to reload, try again */
- return -EAGAIN;
-
assert(m->state == MOUNT_MOUNTED);
mount_enter_remounting(m);