[Bug 1707222] Re: usage of /tmp during boot is not safe due to systemd-tmpfiles-clean

[norman shen]

2021-06-17 01:37:56,633 - util.py[WARNING]: Failed: growpart /dev/vda 2
2021-06-17 01:37:56,634 - util.py[DEBUG]: Failed: growpart /dev/vda 2
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 156, in resize
    subp.subp(["growpart", diskdev, partnum])
  File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 295, in subp
    cmd=args)
cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
Command: ['growpart', '/dev/vda', '2']
Exit code: 2
Reason: -
Stdout: FAILED: pt_resize failed
Stderr: /usr/bin/growpart: 554: /usr/bin/growpart: cannot create /tmp/growpart.g8m8DI/pt_update.err: Directory nonexistent
        failed [pt_update:2] pt_update /dev/vda 2
        cat: /tmp/growpart.g8m8DI/pt_update.err: No such file or directory
2021-06-17 01:37:56,652 - util.py[DEBUG]: resize_devices took 4.224 seconds
2021-06-17 01:37:56,652 - cc_growpart.py[DEBUG]: '/' FAILED: failed to resize: disk=/dev/vda, ptnum=2: Unexpected error while running command.
Command: ['growpart', '/dev/vda', '2']
Exit code: 2
Reason: -
Stdout: FAILED: pt_resize failed
Stderr: /usr/bin/growpart: 554: /usr/bin/growpart: cannot create /tmp/growpart.g8m8DI/pt_update.err: Directory nonexistent
        failed [pt_update:2] pt_update /dev/vda 2
        cat: /tmp/growpart.g8m8DI/pt_update.err: No such file or directory

no sure related, but I still saw similar logs using cloud-init 20.4.1...

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
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