Description

Users may find that the system storage (/var partition) is showing as full when they inadvertently run the file compression command on the same source and destination directory. This article explains how to reclaim storage space occupied by CLI sessions and also shares some best practices.

 

Symptoms

When you inadvertently run the file compression command on the same source and destination directory, you may see the "No space left on device" error as shown below.

root@mx-re0> file archive compress source /var/tmp/* destination /var/tmp/TMP.tgz
tar: Removing leading '/' from member names
: Can't add archive to itselftar: Write error
cp: /var/tmp/TMP.tgz: No space left on device
error: put-file failed
error: could not send local copy of file

When you check system storage as shown here, you see the numbers showing a 0 byte file. Yet the file system continues to occupy disk storage.

root@mx-re0> show system storage 
Filesystem              Size       Used      Avail  Capacity   Mounted on
/dev/gpt/junos         10.0G       2.2G       6.9G       24%  /.mount
/dev/gpt/config         1.6G       344K       1.5G        0%  /.mount/config
/dev/gpt/var             53G        53G      -4.2G      109%  /.mount/var
tmpfs                    41G       144K        41G        0%  /.mount/tmp
tmpfs                    16G       1.4M        16G        0%  /.mount/mfs


root@mx-re0> file list /var/tmp/ detail | grep TMP 
/var/tmp/:
-rw-------  1 root  wheel          0 Aug 21 11:05 TMP.tgz

Solution

To reclaim storage space, you can use either of the following methods:

 

  • Gracefully exit the current CLI session. This will help reclaim the disk space held by the CLI.

  • If the current CLI session exited ungracefully, then it is possible that there are stale CLI sessions. Try clearing all stale CLI sessions.

root@mx-re0> show system users 
11:20AM  up 1 day,  1:28, 3 users, load averages: 0.33, 0.36, 0.52
USER     TTY      FROM                              LOGIN@  IDLE WHAT
root  u0       -                                Sun09AM 25:25 -cli (cli)    
root  pts/0                                     10:35AM    27 -cli (cli)    
root     pts/1                                     11:20AM     - cli        

root@mx-re0> request system logout user root terminal pts/0 
logout-user: done

Now when you check the storage space again:

root@mx-re0> show system storage 
Filesystem              Size       Used      Avail  Capacity   Mounted on
/dev/gpt/junos         10.0G       2.2G       6.9G       24%  /.mount
/dev/gpt/config         1.6G       344K       1.5G        0%  /.mount/config
/dev/gpt/var             53G        36G        12G       75%  /.mount/var
tmpfs                    57G       144K        57G        0%  /.mount/tmp
tmpfs                    16G       1.4M        16G        0%  /.mount/mfs

Some Best Practices

  • Clearing all inactive CLI sessions can help reclaim disk storage that may have been held up by those sessions.

  • One of the safer approaches in a disk full situation is to run the "request system storage cleanup dry-run" command, which will list the files that can be deleted. Based on the output of "request system storage cleanup dry-run," you can manually clear the files or you can run the "request system storage cleanup" command to do the same.

Note: "request system storage cleanup" will not help reclaim the storage space occupied by stale CLI sessions as described earlier.

Modification History

2023-09-12: Initial version