Recently I upgraded to debian jessie (current testing) and after that avg boot time has increased to 3-4 minutes.

Between grub and gdm start, I get this message for 2-3 minutes.

A job is running for creating volatile and temporary files and directories

Here is output of systemd-analyze blame

[smit: ~] $ systemd-analyze blame 
    3min 14.096s systemd-tmpfiles-setup.service
          8.657s NetworkManager.service
          8.244s apache2.service
          7.048s ModemManager.service
          6.328s networking.service
          6.004s accounts-daemon.service
          5.288s binfmt-support.service
          4.557s systemd-logind.service
          4.541s alsa-restore.service
          4.541s console-kit-log-system-start.service
          4.530s lm-sensors.service
          4.521s pppd-dns.service
          4.520s redis-server.service
          4.519s hostapd.service
          4.519s minissdpd.service
          4.519s timidity.service
          4.519s nvidia-kernel.service
          4.518s rc-local.service
          4.437s bluetooth.service
          4.408s avahi-daemon.service
          2.243s systemd-fsck-root.service
          1.437s exim4.service
          1.415s keyboard-setup.service

Once system is started, systemctl doesn't report any error.

[smit: ~] $ sudo systemctl status systemd-tmpfiles-setup
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static)
   Active: active (exited) since Fri 2014-10-17 01:19:09 IST; 1h 41min ago
     Docs: man:tmpfiles.d(5)
  Process: 230 ExecStart=/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=0/SUCCESS)
 Main PID: 230 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/systemd-tmpfiles-setup.service

Why is systemd-tmpfiles-setup.service starting slow? Where can I get detailed logs of systemd-tmpfiles-setup.service?

  • I know this is not a solution to your problem here, but you can switch to sysvinit by installing sysvinit-core. – CameronNemo Oct 16 '14 at 21:59
  • Same problem. This seems resolve it : forums.debian.net/viewtopic.php?f=10&t=118008#p556542 delete your /tmp recreate it chmod 1777 /tmp – user88219 Oct 17 '14 at 10:37
  • I tried removing /tmp but it says rm: cannot remove ‘/tmp/’: Device or resource busy – smitrp Nov 17 '14 at 14:44

When systemd start a system, one of the first service units launched is systemd-tmpfiles-setup. This service runs the command:

# systemd-tmpfiles --create --remove 

This command reads configuration files from (less relevant first):

  • /usr/lib/tmpfiles.d/*.conf - these files are provided by the relevant RPM package and shouldn't be edited by system admin.
  • /run/tmpfiles.d/*.conf - these files are normally used by daemons to manage their own runtime temporary files
  • /etc/tmpfiles.d/*.conf - these files are meant for sysadmis to configure custom temporary locations, and to override vendor-provided default

Also there are three places where temporary files are stored:

  • /var - Variable data specific to this system that should persist between boots
  • /run - Runtime data for processes started since the last boot. This includes process ID files and lock files, among other things. The contents of this directory are recreated on reboot.
  • /tmp - A world-writale space for temporary files. Files which have not been accessed, changed, or modified for 10 days are deleted automatically. Another temporary directory exists in /var/tmp in which files that have not been accessed, changed, or modified in more than 30 days are deleted automatically.

Summing up:
check tmp configuration files to see why tmp setup take so much time, especially note entries in /run directory because it's recreated at boot time.

| improve this answer | |

This is because chrome beta and cups had issues where they created millions of files in /tmp. If /tmp is a tmpfs for you, then try unmounting it and remounting it. Otherwise, rm -rf /tmp then recreate it.

| improve this answer | |
  • Could any downvoters please explain their reasoning? – CameronNemo Oct 26 '14 at 20:19
  • I dont have chrome beta and I upgraded to cups 1.7.5-7 after I found that it caused similar issues. But I am still facing same problem. Also /tmp is not tmpfs. – smitrp Nov 17 '14 at 14:51

systemd-tmpfiles starts before the network does, so depending on your configuration, its possible that one of the systemd-tmpfiles config files (located in /usr/lib/tmpfiles.d) is trying to create a directory for a user or group that is only available on the system once the network is up, such as a user or group defined in LDAP.

If that's the case, you should look to move systemd-tmpfiles-setup.service to starting after the network.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.