8

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)
           man:systemd-tmpfiles(8)
  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?

Improve this question
3
  • I know this is not a solution to your problem here, but you can switch to sysvinit by installing sysvinit-core.
    – CameronNemo
    Oct 16, 2014 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, 2014 at 10:37
  • I tried removing /tmp but it says rm: cannot remove ‘/tmp/’: Device or resource busy
    – smitrp
    Nov 17, 2014 at 14:44

3 Answers 3

Reset to default
3

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
1
  • 1
    Rather than looking at each config individually, it's probably easier to just run systemd-tmpfiles --cat-config. This prints paths to configs along with their content.
    – Hi-Angel
    Aug 15, 2020 at 17:31
0

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
2
  • 1
    Could any downvoters please explain their reasoning?
    – CameronNemo
    Oct 26, 2014 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, 2014 at 14:51
0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .