UTM 9 up2date stuck on version 9.352-6 and pattern 94753

Try, from the command line: du -shx /var/storage/*

What does that give you?

Cheers - Bob

Bob, when I ran that command I got back this:

/root # du -shx /var/storage/*
16K     /var/storage/agent
88M     /var/storage/chroot-clientlessvpn
4.0M    /var/storage/chroot-ftp
148M    /var/storage/chroot-http
17M     /var/storage/chroot-pop3
26M     /var/storage/chroot-reverseproxy
69M     /var/storage/chroot-smtp
271M    /var/storage/cores
16K     /var/storage/lost+found
32K     /var/storage/pgsql
1.8G    /var/storage/pgsql92
2.1G    /var/storage/swapfile

So it looks like the pgsql92 and the swapfile are hogging up most of the space.

Any suggestions?

First, it looks like you have this installed on a disk that is too small.

You probably can remove all of the core dumps in /var/storage/cores.  Be careful in /var/storage/pgsql92/data/pg_xlog that you don't delete anything with a time stamp equal to or newer that on archive_status.

Cheers - Bob

Thanks Bob for the info.

My UTM box has been running fine with the 120 GB drive for a couple years now. And the HD size wasn't an issue until the 1st of the year (Jan 2016) when some files started growing very fast and chewing up space.

Also your statement about the size of my HDD is kind of surprising since the "UTM 9.3 quick start guide" PDF states in the "Minimum Hardware Requirements" section that "20 GB hard disk drive (40 GB recommended)"... and my drive 3x the "recommended" size.

Maybe its time to rebuild using a bigger disk...  so if 120 GB is too small what size HDD would be "REALLY" recommended??

But until I have a chance to do that...

Here is the output from the "/var/storage/cores/*"...  so can I just do a "rm*"  command in that "cores" directory?

/var/storage/cores # du -shx /var/storage/cores/*
24M     /var/storage/cores/admin-reporter..4233
215M    /var/storage/cores/cssd.12817
12M     /var/storage/cores/ips-reporter.pl.26440
1.8M    /var/storage/cores/ipv6_watchdog.4256
20M     /var/storage/cores/ulogd.4058

If so, looks like I will gain back a couple hundred MBs at least...

Thanks again for sticking with me on this!!!

I would first do ls -l /var/storage/cores to check that you don't have a recent core dump you might want to keep for Support.

You say, "And the HD size wasn't an issue until the 1st of the year (Jan 2016) when some files started growing very fast and chewing up space."  Do you know where that was?  Do you have any Reporting on when the partition started to grow?  Can you show us the graph?

Again, you'll probably want to delete some of the pgsql92 files as I mentioned above, but do so carefully with my warning above in mind.

Cheers - Bob

Bob,

I am sorry but I am a bit of a noob with the inner workings so more details on this statement would be greatly appreciated: "Be careful in /var/storage/pgsql92/data/pg_xlog that you don't delete anything with a time stamp equal to or newer that on archive_status."

When you said "be careful"... I read it as "stay away from".  So how and where do I see the "archive_status" time stamp? And any other specifics would be helpful.

(And yes, I will backup my config before deleting anything.)

Also, should a 120 GB HDD be big enough for a 5 user site? My Logs directory is hardly touched... its really ROOT which is almost completely full.

Here is the image of my Storage graph...

As always.... THANKS for your help!!

Run ls -l /var/storage/pgsql92/data/pg_xlog - you will see that there is a sub-directory archive_status.

Yes, 120GB should be enough for five users.

Show us the results of the version command and of df.

Cheers - Bob

Here you go...

:/ # version
Current software version...: 9.352006
Hardware type..............: Software Appliance
Installation image.........: 9.004-33.1
Installation type..........: asg
Installed pattern version..: 94753
Downloaded pattern version.: 94753
Up2Dates applied...........: 37 (see below)
                             sys-9.004-9.004-33.34.1.tgz (Mar 10  2013)
                             sys-9.004-9.005-29.15.2.tgz (Mar 10  2013)
                             sys-9.005-9.005-15.16.1.tgz (Mar 10  2013)
                             sys-9.005-9.006-15.5.2.tgz (Apr 16  2013)
                             sys-9.006-9.100-5.16.1.tgz (May 20  2013)
                             sys-9.100-9.101-16.12.1.tgz (Jun 12  2013)
                             sys-9.101-9.102-11.8.2.tgz (Jul  3  2013)
                             sys-9.102-9.103-8.5.2.tgz (Nov 18  2013)
                             sys-9.103-9.104-5.17.2.tgz (Nov 18  2013)
                             sys-9.104-9.105-17.9.1.tgz (Nov 18  2013)
                             sys-9.105-9.106-9.17.1.tgz (Nov 18  2013)
                             sys-9.106-9.107-17.33.2.tgz (Jan 20  2014)
                             sys-9.107-9.108-33.23.2.tgz (Mar 26  2014)
                             sys-9.108-9.109-23.1.2.tgz (Mar 26  2014)
                             sys-9.109-9.110-1.22.1.tgz (Apr 13  2014)
                             sys-9.110-9.111-22.7.1.tgz (Apr 13  2014)
                             sys-9.111-9.111-7.11.1.tgz (Jul 28  2014)
                             sys-9.111-9.112-7.12.1.tgz (Jul 28  2014)
                             sys-9.112-9.113-12.1.2.tgz (Jul 28  2014)
                             sys-9.113-9.203-1.3.1.tgz (Jul 28  2014)
                             sys-9.203-9.204-3.20.1.tgz (Jul 28  2014)
                             sys-9.204-9.205-20.12.1.tgz (Sep 14  2014)
                             sys-9.205-9.206-12.35.1.tgz (Sep 14  2014)
                             sys-9.206-9.207-35.19.2.tgz (Jan 19  2015)
                             sys-9.207-9.208-19.8.5.tgz (Jan 19  2015)
                             sys-9.208-9.209-8.8.1.tgz (Jan 19  2015)
                             sys-9.209-9.210-8.20.1.tgz (Jan 19  2015)
                             sys-9.210-9.304-20.9.2.tgz (Jan 26  2015)
                             sys-9.304-9.305-9.4.1.tgz (Jan 26  2015)
                             sys-9.305-9.306-4.6.1.tgz (Jan 26  2015)
                             sys-9.306-9.307-6.6.1.tgz (Mar  6  2015)
                             sys-9.307-9.308-6.16.2.tgz (Mar  6  2015)
                             sys-9.308-9.309-16.3.1.tgz (Mar 11  2015)
                             sys-9.309-9.310-3.11.1.tgz (May 10  2015)
                             sys-9.310-9.311-11.3.1.tgz (Jun  2  2015)
                             sys-9.311-9.312-3.8.1.tgz (Jun  2  2015)
                             sys-9.312-9.313-8.3.1.tgz (Jul  9  2015)
Up2Dates available.........: 0
Factory resets.............: 0
Timewarps detected.........: 0

---

:/ # df
Filesystem     1K-blocks        Used     Available    Use%    Mounted on
/dev/sda6         5412452   4883672       230800      96%     /
udev                  1669276               80      1669196       1%    /dev
tmpfs                 1669276                 0      1669276       0%    /dev/shm
/dev/sda1            338875        24774        292085       8%    /boot
/dev/sda5       42628172    4373268   35957868      11%    /var/storage
/dev/sda7       55903552       298328   52600092       1%    /var/log
/dev/sda8          2559076           5908     2403460       1%     /tmp
tmpfs                 1669276                  0      1669276       0%    /var/sec/chroot-httpd/dev/shm
tmpfs                 1669276                  0      1669276       0%    /var/storage/chroot-reverseproxy/dev/shm
tmpfs                 1669276                  8      1669268       1%    /var/storage/chroot-smtp/tmp/ram

sorry...  back to back posts again...

From this ls -l /var/storage/pgsql92/data/pg_xlog... i got back lots of row of entries like the examples below (I shortened the list quite a bit).

So you are saying I could do the "rm 000000010000004600000041" command on entries like this? ( the may 1st entry for example )

But I should stay away from the May 6th entries since "archive_status" is also "May 6"? ( ignoring the time stamp for now just to be safe )

-rw------- 1 postgres postgres 16777216 May  6 13:20 00000001000000460000003E
-rw------- 1 postgres postgres 16777216 May  6 14:35 00000001000000460000003F
-rw------- 1 postgres postgres 16777216 May  6 14:56 000000010000004600000040
-rw------- 1 postgres postgres 16777216 May  1 23:32 000000010000004600000041
-rw------- 1 postgres postgres 16777216 May  2 00:14 000000010000004600000042
-rw------- 1 postgres postgres 16777216 May  2 01:05 000000010000004600000043
-rw------- 1 postgres postgres 16777216 May  2 01:47 000000010000004600000044
-rw------- 1 postgres postgres 16777216 May  2 02:27 000000010000004600000045
drwx------ 2 postgres postgres    12288 May  6 14:39 archive_status
cronkright:/ #

With only eight files, it's not worth deleting anything.  Usually, these problems are associated with either the cores or pgsql92 directory, but I just reread the thread and noticed that you picked up near the beginning on the /dev/sda6 problem that I just saw above.  What do you get from du -shx /*

Cheers - Bob