A start job is running for Create Volatile Files and Directories

Publish on: Classify at: Read:≈ 3min Views: Comments:

Yesterday, when I login to my VM I found that the disk is full. Even a tab command completion cannot be done. I immediately delete some unused files and the system works. However, when I reboot the system, it stucked at A start job is running for Create Volatile Files and Directories...:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

...
[  OK  ] Started File System Check on /dev/disk/cloud/azure_resource-part1.
[  OK  ] Started File System Check Daemon to report status.
[  OK  ] Started File System Check on /dev/d…5d996-7436-4ec8-b5d6-0d7b6100aeb5.
         Mounting /data...
[  OK  ] Mounted /data.
[  OK  ] Reached target Local File Systems.
         Starting AppArmor initialization...
         Starting ebtables ruleset management...
         Starting Tell Plymouth To Write Out Runtime Data...
         Starting Set console font and keymap...
[  OK  ] Started Set console font and keymap.
[  OK  ] Started Tell Plymouth To Write Out Runtime Data.
[  OK  ] Started ebtables ruleset management.
[  OK  ] Started Flush Journal to Persistent Storage.
         Starting Create Volatile Files and Directories...
[  OK  ] Started AppArmor initialization.
[    **] A start job is running for Create V… Directories (13min 46s / no limit)

I searched and found a similar discussion: # Boot stuck at “A start job is running for Create Volatile Files and Directories”

I used an Azure VM with an extra disk. However, it always failed to boot into recovery mode. Then I removed the extra disk from the portal and the system mount the disk failed and went to the single user mode so that I can execute commands:

1
2

root@DEAN:/tmp# ls /tmp
bash: /bin/ls: Argument list too long

Then occasionally I found that there are HUGE amount of something like this .com.google.Chrome.nFbq9T:

1
2

root@DEAN:/tmp# ls .com.google.Chrome.*
bash: /bin/ls: Argument list too long

Since I have a web crawler in the system, it seems that there are something wrong but it doesn’t matter. I also cannot execute rm -f .com.google.Chrome.* due to Argument list too long. First list them:

1
2
3
4
5

root@DEAN:/home# find /tmp -type f -iname ".com.google.Chrome*" -ls | head
find: ‘/tmp/.com.google.Chrome.nFbq9T’: No such file or directory
find: ‘/tmp/.com.google.Chrome.WKCRCU’: No such file or directory
find: ‘/tmp/.com.google.Chrome.62cCbn’: No such file or directory
find: ‘/tmp/.com.google.Chrome.RR1E3L’: No such file or directory

The command cannot quickly return, but I got above error messages. Seems that the OS is cleaning the /tmp folder but I cannot verify this. Through df -lh I found that the available disk space is increasing. To speed up the process, execute:

1

root@DEAN:/home# find /tmp -iname ".com.google.Chrome*" -delete > /dev/null 2>&1

After nearly an hour it finished:

1
2
3
4
5
6

~$ df -lh
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           393M  1.1M  392M   1% /run
/dev/sda1        29G   13G   16G  46% /
...

It looks like there were 16G .com.google.Chrome. files… And because of this, the system is stuck at boot. Unfortunately, the root cause of this problem is not found yet.

By the way, directly move /tmp to /tmp.bak and recreate /tmp might be more efficient as suggested in the above post…