On Fri, Jan 29, 2016 at 8:59 PM, Cecil Westerhof <cldwesterhof at gmail.com> wrote:
> > > However, I've run into a few problems, so I'm offering my findings and > > fixes. > > > > The first, line 3, you've got a reference to a script that doesn't exist > > AFAIK. You should maybe put a check to see if the file exists first, > > before running it. I just deleted that entry from my version of the > > script. > > > > ?That is my bash library. I will change it so you can use the script > without the library. > ? > I figured as such. :] > > Third, my version of df doesn't seem to support the --output parameter. > > I've checked online man pages and I can't find an example or a man page > > containing that parameter. Removing the parameter, it still works. > > > > ?I will look into that also. What does ?df --version? give and which > version of Linux are you using? (uname -a) > > On my home machine. mc at core ~$ uname -a Linux core 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux mc at core ~$ df --version df (GNU coreutils) 8.13 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html >. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. The RH machines are all RH6. I think all are 6.5, but not sure. I can't be assed to VPN in right now to find out. > > > Fourth, I'd maybe suggest that you either run a delete prior to updating > > for todays date, or, change the resolution of the date to the accuracy > of a > > second. The reason being is if you want to test (Like I'm doing) you're > > going to run into constraint violations. With changing to a second > > resolution, you can run it multiple times to get more results to get real > > time info. I'll also be changing my version so it doesn't show human > > readable since I'll be looking at a few KB worth of changes at a time. > > > > ?My idea was that you only run it once a day. But I will change that it can > be run on minute base also. I will also implement a parameter to get rid of > human readable. > ? > > In what I do and where I'd be using this most often, I deal with sick computers all the time at a software level. So if something goes rogue, I need to know what is changing in as near real-time as necessary sometimes. Once I build a front end for this, I'll be able to better monitor the health of a system, or at least determine why a drive is getting full quicker than expected. I might even expand this a bit further to look at cataloging file sizes, and then have the front end I build show me exactly what files have changed in size. > > > > On my MC server, I have the current partition setup: > > rootfs 36G 19G 15G 57% / > > udev 10M 0 10M 0% /dev > > tmpfs 397M 164K 397M 1% /run > > /dev/disk/by-uuid/75b09020-4711-48d3-a664-7024a0d16db8 36G 19G 15G > 57% / > > tmpfs 5.0M 0 5.0M 0% /run/lock > > > > The fact that I have two / mentioned, it errors out. This might be an > > edge case, but, just something I came across. I'll have to filter out > > either rootfs or dev/disk. I'll need to see how the work machines are > > setup (They're Redhat, I'm using Debian at home right now) so I'll decide > > what happens then. > > > > ?I would only use partitions? > ? that are mounted on /dev/... But that is the nice thing about this > solution: what is stored is driven by the database. > > Read my other note. It isn't / that caused me the grief, but the type of FS that is mounted. /run/lock and /run were both tempfs and your constraint locked me out based on tempfs. I changed the schema to enforce the three fields of date, partition, and my new field mountPoint. > > > > And finally, maybe not the scripts fault, but there was an oddball > > directory made by one of the Minecraft mods that pooched the script. > > Literally, the directory was > > "_!'0!bw"k!(}!~@"y!(:!a@"v!'4!d!"y!'%!}w"r!'`!cg!x!#4!;w!u!$%!:!==". > > I deleted the directory, and it went through completely. I'll just > modify > > the script to ignore this particular directory. > > > > ?You do not need to delete the directory, just do not put it in the > database to be processed. :-D > > Poh-tay-toe, poh-tah-toe. To me, before Simon explained, I thought it was a bad directory descriptor, so, junked it anyways. But going forward, the script didn't like the name for some reason, so it ultimately broke. I'll need to figure out how to ensure that doesn't happen at least on my MC server. > > > > All in all, excellent example. > > > > ?Thank you. > ? > > No problem. Do you have any issues with my using this in a commercial environment? It'd be just for diagnostic purposes and not resold.
