I have emoncms running on my emon-base at home. It has run fine for a few weeks, but now it appears the graphs have stopped updating as of yesterday, but the Feeds page is showing updates every few seconds.
What should I do to diagnose this?
J.
I have emoncms running on my emon-base at home. It has run fine for a few weeks, but now it appears the graphs have stopped updating as of yesterday, but the Feeds page is showing updates every few seconds.
What should I do to diagnose this?
J.
I see that my /home/pi/data partition is full. Have I done something wrong? Is there something I probably should be doing to avoid this?
pi@emonpi(rw):~$ more /etc/fstab
tmpfs /tmp tmpfs nodev,nosuid,size=30M,mode=1777 0 0
tmpfs /var/log tmpfs nodev,nosuid,size=50M,mode=1777 0 0
tmpfs /var/lib/dhcp tmpfs nodev,nosuid,size=1M,mode=1777 0 0
tmpfs /var/lib/dhcpcd5 tmpfs nodev,nosuid,size=1M,mode=1777 0 0
tmpfs /var/lib/openhab tmpfs nodev,nosuid,size=40M,mode=1777 0 0
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults,noatime,nodiratime 0 2
/dev/mmcblk0p2 / ext4 defaults,ro,noatime,nodiratime,errors=remount-ro 0 1
/dev/mmcblk0p3 /home/pi/data ext2 defaults,rw,noatime,nodiratime,errors=remount-ro 0 2
pi@emonpi(rw):~$ df -m
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/root 3410 2293 952 71% /
devtmpfs 481 0 481 0% /dev
tmpfs 486 0 486 0% /dev/shm
tmpfs 486 50 437 11% /run
tmpfs 5 1 5 1% /run/lock
tmpfs 486 0 486 0% /sys/fs/cgroup
/dev/mmcblk0p3 194 183 2 100% /home/pi/data
tmpfs 40 7 34 17% /var/lib/openhab
/dev/mmcblk0p1 60 22 39 37% /boot
tmpfs 1 0 1 0% /var/lib/dhcpcd5
tmpfs 1 0 1 0% /var/lib/dhcp
tmpfs 50 22 29 44% /var/log
tmpfs 30 1 30 1% /tmp
pi@emonpi(rw):~$
Hi @jasonnet,
Your /home/pi/data filesystem being full will be the culprit.
But it does look quite small though. I have an Emon hub and have:
pi@emonpi(ro):data$ df -h /home/pi/data
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p3 3.5G 217M 3.1G 7% /home/pi/data
pi@emonpi(ro):data$
So either enlarge the filesystem, or review what you’ve got stored, to investigate try:
pi@emonpi(ro):~$ cd /home/pi/data
pi@emonpi(ro):data$ sudo du -sm * | sort -rn
139 phpfina
30 mysql
23 emoncms-backup-2017-11-18.tar.gz
17 emoncms-backup-2017-09-26.tar.gz
7 node-red
1 wpa_supplicant.conf
....
The list above shows the total MB used for everything within /home/pi/data, where this is a directory, it is a summary of total used of ALL levels within that directory.
You could then traverse through the higher usage directories. I have 18 feeds, earliest dating back to March 2017, which uses 139MB.
As your filesystem is 194MB total, then I’d increase the filesystem size.
Clive.
Thanks Clive.
After a few reboots and a bit of trouble, I successfully started using a symbolic link to map the ~/data/phpfina directory to a directory on a usb-mounted SSD. I first copied over all the files in the phpfina directory. I don’t know if it’s ever a concern, but because the phpfina partition had been full, I was not concerned about copying files that were changing.
If I had not had a spare drive and had wanted to prune back the data in the phpfina directory, is there a recipe for nicely pruning?
I think my trailing question there was lost:
Is there any standard operating procedure for pruning back the phpfina directory as it becomes too big? 'anything automated?
Not that I have seen. The suggestion has come up a few times.
I saw your phpfina data (in the /home/pi/data directory) above:
pi@emonpi(rw):~$ df -m
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mmcblk0p3 194 183 2 100% /home/pi/data
You really don’t have much space available or much data. You might be better off buying a larger SD card and expanding the space so you have more room for data.
EDIT: See GitHub - emoncms/usefulscripts: Some useful scripts for administering Emoncms accounts
see sdpart directory (GitHub - emoncms/usefulscripts: Some useful scripts for administering Emoncms accounts)