systemd-tmpfiles-clean is racy, but only cleans things as per
tmpfiles.d/ configs in /run /etc /usr/lib, for things that explicitely
specify to clean themself older than some value.

For /tmp the affected paths are older than 10 days only:
d /tmp/.X11-unix 1777 root root 10d
d /tmp/.ICE-unix 1777 root root 10d
d /tmp/.XIM-unix 1777 root root 10d
d /tmp/.font-unix 1777 root root 10d
d /tmp/.Test-unix 1777 root root 10d

To figure out what actually happened, we need a reproducer or detailed
logs, including journal, and contents of /run/tmpfiles.d /etc/tmpfiles.d
/usr/lib/tmpfiles.d

I do not recommend using /tmp on security grounds, but I do recommend to
set PrivateTmp=true in the systemd units to get a secure /tmp /var/tmp
for your service.

** Changed in: systemd (Ubuntu)
       Status: New => Incomplete

-- 
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:
  New
Status in cloud-init package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

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

Reply via email to