1. You may get e-mail or system, task notifications from the MA or ELM you are running out of disk space.
2. You may have an unresponsive Unidesk Management Console,                                                                               

To verify

1. 1.open ALMC gui
2. Login as root and use the "df" command to determine that you are out of space.
   
   -Unidesk sample-
   [root@localhost ~]# df
   Filesystem     1K-blocks    Used Available Use% Mounted on
   /dev/sda3        6062664 5445636    309060  95% /
   tmpfs            4090504      20   4090484   1% /dev/shm
   /dev/sda1         126931   32606     87772  28% /boot
   
   In the ELM you should check the "Use%" of /dev/sda1  - this can also be on /dev/sda2.  The important disk to look for is "/"  which is root, which is the ELM disk.
   
   Filesystem                                                 Size  Used Avail Use% Mounted on
   devtmpfs                                                   7.9G     0  7.9G   0% /dev
   tmpfs                                                      7.9G   16K  7.9G   1% /dev/shm
   tmpfs                                                      7.9G  756M  7.1G  10% /run
   tmpfs                                                      7.9G     0  7.9G   0% /sys/fs/cgroup
   /dev/sda1                                                   30G   30G   20K 100% /
   /dev/loop0                                                 505M  505M     0 100% /mnt/cemedia/HypervCitrixCE
   /dev/loop1                                                 506M  506M     0 100% /mnt/cemedia/VsphereCitrixCE
   /dev/mapper/unidesk_vg-xfs_lv                              512G  370G  143G  73% /mnt/repository
   /dev/sdb1                                                   32G  4.1G   28G  13% /mnt/resource
   //Servername.windows.net/applayers  5.0T   18G  5.0T   1% /mnt/maserviceshare/mnt00000024
   tmpfs                                                      1.6G     0  1.6G   0% /run/user/1000
   
    

The default credentials for accessing the Linux console in Unidesk V2 and V3 are:

Username: root
Password: v9Yx*6uj

Note : The ELM root account is set by the customer and if in Azure, you will need to logon with the alternate root account, name and use sudo for most of the below commands.

1.The first place to look is the root directory.  Look for any files names core.*.  Note the timestamp on the file to determine if there's anything you can learn about when they were created, and then simply delete them. 

2.Another key place to look for core* .* files is:  /usr/local/CAMService/diagcores.  This one is not as obvious as others but if you see the /usr directory larger than 1.4G (see below) then Execute, 'du -h --max-depth=1-x /' to walk down through the directory.  If core*.* files are found, they can be deleted.
To delete them:
[root@localhost ~]# rm core*.*

Once the core*.* are removed from the CAMService/diagcores directory, reboot the ELM and test accessing the GUI.  As an aside, you may want to export logs to determine why CAMS crashed or is crashing continually, if that is the case.

[root@localhost ~]# cd /
[root@localhost /]# ls -l core*
-rw------- 1 root root 656683008 Sep 16  2016 core.mono.1879.1474073323
-rw------- 1 root root 719343616 Jun 10  2017 core.mono.1882.1497158335
-rw------- 1 root root 393949184 Jan  9  2015 core.mono.1897.1420815442
-rw------- 1 root root 730693632 Apr 18  2015 core.mono.1901.1429408621
-rw------- 1 root root 691625984 May  8  2016 core.mono.2058.1462765017
[root@localhost /]# rm core*
rm: remove regular file `core.mono.1879.1474073323'? y
yrm: remove regular file `core.mono.1882.1497158335'? y
rm: remove regular file `core.mono.1897.1420815442'? y
rm: remove regular file `core.mono.1901.1429408621'? y
rm: remove regular file `core.mono.2058.1462765017'? y
[root@localhost /]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda3        6062664 4010252   1744444  70% /
tmpfs            4090504      20   4090484   1% /dev/shm
/dev/sda1         126931   32606     87772  28% /boot

3.Also look for folders with large amounts of data, i.e. 2+ GBs using the below. Alter the search once you change into a different directory.

Execute, 'du -h --max-depth=2 -x /'


4.The next place to look is the HTTPD logs. These are not ever rolled or truncated, and will grow unbounded for the life of the MA, ELM.  They can be safely zeroed out, but do not simply delete them.  Use the "cat" command as below

[root@localhost /]# cd /var/log/httpd
[root@localhost httpd]# ls -l
total 621424
-rw-r--r-- 1 root root  65193086 Apr 18 16:59 access_log.1521504000
-rw-r--r-- 1 root root  94422027 May 18 16:59 access_log.1524096000
-rw-r--r-- 1 root root  65889826 Jun 17 16:30 access_log.1526688000
-rw-r--r-- 1 root root  83312328 Jul 17 16:59 access_log.1529280000
-rw-r--r-- 1 root root 149767821 Aug 16 16:59 access_log.1531872000
-rw-r--r-- 1 root root   2439740 Aug 20 09:05 access_log.1534464000
-rw-r--r-- 1 root root   2707456 Apr 18 13:56 error_log.1521504000
-rw-r--r-- 1 root root    106496 May 16 07:18 error_log.1524096000
-rw-r--r-- 1 root root   3633152 Jun 14 07:41 error_log.1526688000
-rw-r--r-- 1 root root     61440 Jul 17 06:11 error_log.1529280000
-rw-r--r-- 1 root root    131072 Aug 13 23:02 error_log.1531872000
-rw-r--r-- 1 root root     32768 Aug 20 06:09 error_log.1534464000
-rw-r--r-- 1 root root 1260943207 Aug 19 06:43 ssl_access_log
-rw-r--r-- 1 root root  29837066 Aug 19 05:19 ssl_error_log
-rw-r--r-- 1 root root  77159437 Aug 19 06:43 ssl_request_log
[root@localhost httpd]# cat > /dev/null > ssl_access_log
[root@localhost httpd]# cat /dev/null > ssl_error_log
[root@localhost httpd]# cat /dev/null > ssl_request_log


In the ELM you may need to stop the httpd and, or apache servise then "rm" the files, in the httpd folder.

systemctl stop httpd

and/or

systemctl stop apache

5.Finally, you may need to work your way through the filesystem manually to determine which folder(s) contain unusually large files.  "du" is an appropriate tool for this.  "du -s *" will give you the subtotal of the listed files separately, in KB.

[root@localhost /]# du -s *
20980   MAData.sql
5184    MAData.sql.tgz
6036    bin
26975   boot
176     dev
30096   etc
24      home
151016  lib
20      lost+found
4       media
4       mnt
56336   opt
du: cannot access `proc/15410/task/15410/fd/4': No such file or directory
du: cannot access `proc/15410/task/15410/fdinfo/4': No such file or directory
du: cannot access `proc/15410/fd/4': No such file or directory
du: cannot access `proc/15410/fdinfo/4': No such file or directory
0       proc
460     root
10932   sbin
4       selinux
4       srv
0       sys
62220   tmp
1444036 usr
1915540 var

Also, you may use 'du -h --max-depth=2 -x /', to find folders starting at the root. Alter the starting path, folder as needed.

This is for Unidesk 2.x and 3.x appliances, not 4.x or the current ELM releases. See how only usr and var have any significant space used in them.  /usr normally contains 1.4GB, so we can ignore that.  "cd /var" and repeat the process until you find the files causing you problems.  There might be old logs you can just delete, but you might need to call Support for assistance in figuring out what is causing log files to balloon.

Problem Cause