>From another bug with the same root cause, a failure might look like this:
Apr 12 07:56:33 ubuntu [CLOUDINIT] util.py[DEBUG]: Running command ['mount',
'-o', 'ro,sync', '-t', 'auto', '/dev/sr0', '/tmp/tmpzq70nqyi'] with allowed
return codes [0] (shell=False, capture=True)
Apr 12 07:56:33 ubuntu [CLOUDINIT] util.py[DEBUG]: Failed mount of '/dev/sr0'
as 'auto': Unexpected error while running command.#012Command: ['mount', '-o',
'ro,sync', '-t', 'auto', '/dev/sr0', '/tmp/tmpzq70nqyi']#012Exit code:
32#012Reason: -#012Stdout: ''#012Stderr: 'mount: mount point /tmp/tmpzq70nqyi
does not exist\n'
Apr 12 07:56:33 ubuntu [CLOUDINIT] util.py[DEBUG]: Recursively deleting
/tmp/tmpzq70nqyi
** Changed in: cloud-init
Status: New => Confirmed
** Changed in: cloud-init
Importance: Undecided => Medium
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => High
** Changed in: cloud-init
Importance: Medium => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1707222
Title:
usage of /tmp during boot is not safe due to systemd-tmpfiles-clean
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Won't Fix
Bug description:
Earlier this week on Zesty on Azure I saw a cloud-init failure in its
'mount_cb' function.
That function esentially does:
a.) make a tmp directory for a mount point
b.) mount some filesystem to that mount point
c.) call a function
d.) unmount the directory
What I recall was that access to a file inside the mount point failed during
'c'.
This seems possible as systemd-tmpfiles-clean may be running at the same time
as cloud-init (cloud-init.service in this example).
It seems that this service basically inhibits *any* other service from using
tmp files.
It's ordering statements are only:
After=local-fs.target time-sync.target
Before=shutdown.target
So while in most cases only services that run early in the boot
process like cloud-init will be affected, any service could have its
tmp files removed. this service could take quite a long time to run
if /tmp/ had been filled with lots of files in the previous boot.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1707222/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
