Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

Nightly check of FreeNAS database!

Western Digital Drives - The Preferred Drives of FreeNAS and TrueNAS CORE

danb35

Wizened Sage
Joined
Aug 16, 2011
Messages
11,873
The chkconfig.sh script as posted didn't work for me--I would get emails saying "sqlite3: not found". I had to change that line (line 27 of cyberjock's posted script) to specify the full path: /usr/local/bin/sqlite3. Works fine now--thanks!
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
It sounds like you didn't follow my guide properly for cronjob creation so you have none of the path variables. It also means that while you think you may have fixed the sqlite3 the script may be incapable of sending an email. And just for completeness adding /usr/local/bin/sendmail may not even fix it.

You should instead go back and find out why your path variables are not being used in the environment the script is being run in. The two most likely causes are human error or you've customized FreeNAS. I'll leave you to figure out which one and how as I can't provide much more help than that. :/
 

danb35

Wizened Sage
Joined
Aug 16, 2011
Messages
11,873
I'm not sure what settings in the cronjob setup would affect the availability of environment variables other than (possibly) the user. My setting is attached, and it seems to match what you posted, but if you could point out something that doesn't match I'd be glad to see it.

I know the script can send mail, because it was sending mail that the database was corrupted. I haven't made any system modifications that I can think of, though I am running 9.2.1.6 BETA as of a day or two ago.
 

Attachments

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
I don't know either, and since you aren't using it the same way that I am I don't have any advice. I know I'm using the 9.2.1.6-beta on my Mini with this script and it runs every night exactly how I did the setup.
 

danb35

Wizened Sage
Joined
Aug 16, 2011
Messages
11,873
The problem came down to how FreeNAS builds cron jobs. FreeNAS prepends a PATH statement (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/root/bin, at least in my system) to the command you enter--but when you enter "command1 && command2 && command3" as the command for the cron job, that path apparently only applies to the first command. The remaining commands get a much shorter PATH (/etc:/bin:/sbin:/usr/bin:/usr/sbin on my system), which matches the PATH specified at the beginning of /etc/crontab. This is why sendmail works (it's in /usr/sbin), but sqlite3 doesn't (it's in /usr/local/bin).

I can think of a few ways to deal with it:
  1. Change the sqlite3 call in chkconfig.sh to explicitly specify the path
  2. Create a fourth script containing only "/mnt/tank/diffconfig.sh && /mnt/tank/chkconfig.sh && /mnt/tank/bkpconfig.sh", and call that script in the cron job (the PATH prepended to the command should apply to anything called by that script)
  3. Specify the path for the remaining commands in the cron job, like '/mnt/tank/diffconfig.sh && PATH="blah" /mnt/tank/chkconfig.sh'
Option 1 seems the easiest. A fourth option would certainly be to remove the call to diffconfig.sh, but I don't see any reason to make daily backups of unchanged config databases.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
My only problem with #1 is as I described above. What about other commands that may require a path and not have it. Will you know that the path is/isn't correct when it fails and you *should* get an email but won't because sendmail executes some other command that requires the path? This concern is precisely why I said:

You should instead go back and find out why your path variables are not being used in the environment the script is being run in.

So while I agree that #1 is the simplest, I also consider it the most risky because of other potential dependencies that may break with no warning. Personally I'd opt for #2 as a conservative option that has the highest chance for success in all scenarios. Considering that this stuff is somewhat important(you'd hate to have this break someday and not work for weeks or months without you knowing better) I'd prefer to stick with what is the most likely to work. ;)
 

danb35

Wizened Sage
Joined
Aug 16, 2011
Messages
11,873
If a command is called by a script (or elsewhere in a cron job) and can't be found, cron itself notifies you (which was what clued me in to the path as a possible problem--in addition to the one email saying my database was corrupt, I got another from the cron daemon saying "/mnt/tank/chkconfig.sh: sqlite3: not found" Thus, it seems the odds of a cron job failing silently appear to be roughly zero.

As to other dependencies, the chkconfig.sh script calls only two external programs--sqlite3 and sendmail. It might be better if the path were explicitly specified for both of them--then the environment variables would simply be irrelevant. I'm not sure if that's a "best practice" or not for these scripts, but it seems to have something to recommend it.

In any event, I've determined why the path that FreeNAS prepends to the cron job isn't applying to this script, what the PATH environment is for this script, and how it affects the script running in my installation. The great thing about UNIX is that there's more than one way to do it (whatever "it" may be).
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
If a command is called by a script (or elsewhere in a cron job) and can't be found, cron itself notifies you (which was what clued me in to the path as a possible problem--in addition to the one email saying my database was corrupt, I got another from the cron daemon saying "/mnt/tank/chkconfig.sh: sqlite3: not found" Thus, it seems the odds of a cron job failing silently appear to be roughly zero.
Then you changed 2 things about how I do my install since I recommend that the stderr and stdout redirect to /dev/null. In that case they *would* silently fail.

As to other dependencies, the chkconfig.sh script calls only two external programs--sqlite3 and sendmail. It might be better if the path were explicitly specified for both of them--then the environment variables would simply be irrelevant. I'm not sure if that's a "best practice" or not for these scripts, but it seems to have something to recommend it.
Ok, and say for instance that sendmail needs to call some other dependency. sendmail may not return an error but the dependency will not work and your mail may not go out. I've seen this with dependencies between apache and openssl when doing ssl certificate validation and such.

In any event, I've determined why the path that FreeNAS prepends to the cron job isn't applying to this script, what the PATH environment is for this script, and how it affects the script running in my installation. The great thing about UNIX is that there's more than one way to do it (whatever "it" may be).
I agree 100%. 10 ways to skin a cat. ;)

On an unrelated note(and not trying to point you out specifically) but this is an excellent example of why so many people won't post their guides in the forum. Too many take the guide, bend it and twist it to work for them, and when it fails they expect to be provided the answers,even if it takes 5 pages of text back and forth. That's why many of the older guides are not able to be replied to and I delete threads that say 'I did this guide and it didn't work". If you do exactly what we say and it doesn't work, that's one thing. But too many people don't fully understand everything(I won't pretend that I had your answer for 100% certainty when you first posted the question) it gets messy real fast because you find they made 10 changes and you don't know which one or ones are to blame for the fault.

One person has even proposed the idea of making every guide read-only and basically letting the user figure it out for themselves. Unfortunately that's not what I'd expect to happen and I'd rather not have to delete 50 threads a week covering every guide because someone couldn't figure out the answer on their own.

I'm in the process of writing a "guide" on getting permissions correct on FreeNAS 9.2.1.6+ since Samba4 has so many twists and turns with how it works the file and folder permissions. My big problem is I do not want an inbox full of complaints and I don't want a thread full of people that just don't 'get it'. So if/when I post it, it will be read-only with the warning that any threads asking about permissions will be deleted without warning.
 

danb35

Wizened Sage
Joined
Aug 16, 2011
Messages
11,873
I did redirect stdout and stderr to /dev/null (I refer you to my post #23 for the screen shot of the setup)--but that redirection only applies to the last command in the chain. Thus, if I do as you suggest:
If you want to do backups AND config checks, you can change the cronjob to instead be something like: /mnt/tank/chkconfig.sh && /mnt/tank/bkpconfig.sh
...the redirection applies only to bkpconfig.sh, not to chkconfig.sh. But that said, that's a good point that I hadn't fully processed. It still seems like a fourth script whose only purpose is to call the first three is needless added complexity, but it may be the best way to go.

In any event, apparently I wasn't very clear about my reason for posting in this thread. It wasn't "this is broken, fix it for me." It was "it didn't work for me this way, but when I made this small change, it did." The point was to help others who might encounter the same problem I did--and there's nothing at all in the GUI that will tell you why chaining another script will cause the second one to fail. The subsequent discussion has been helpful, I think, and points out pros and cons of some possible ways to address the problem.

People will have questions about guides. Sometimes the questions will be because they didn't read thoroughly (or at all), sometimes they will read carefully and just not understand something, sometimes they'll need something not quite covered by the guide, and sometimes the guide is just wrong--and there are probably lots of other reasons I didn't even think of. If users can't ask questions, what is the purpose of a support forum?
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
I did redirect stdout and stderr to /dev/null (I refer you to my post #23 for the screen shot of the setup)--but that redirection only applies to the last command in the chain.
Ah! I don't think I caught that part. I thought only the path was applicable.

In any event, apparently I wasn't very clear about my reason for posting in this thread. It wasn't "this is broken, fix it for me." It was "it didn't work for me this way, but when I made this small change, it did." The point was to help others who might encounter the same problem I did--and there's nothing at all in the GUI that will tell you why chaining another script will cause the second one to fail. The subsequent discussion has been helpful, I think, and points out pros and cons of some possible ways to address the problem.
I didn't think you were asking in that way, which is why I even posted to begin with. ;)

People will have questions about guides. Sometimes the questions will be because they didn't read thoroughly (or at all), sometimes they will read carefully and just not understand something, sometimes they'll need something not quite covered by the guide, and sometimes the guide is just wrong--and there are probably lots of other reasons I didn't even think of. If users can't ask questions, what is the purpose of a support forum?
That's why I'm not exactly for making stuff read-only. There's some very hot topics(like permissions) that do need some kind of control. We get about a dozen threads a day on permissions and I am not interested in fielding those questions. I deliberately close my browser when I see them and I'm not interested in my guide turning into a thread of people begging for help. We are all volunteers in the forums and none of us are paid to do anything on here.
 

diedrichg

Neophyte Sage
Joined
Dec 4, 2012
Messages
1,299
Subscribed
 
Joined
Sep 13, 2013
Messages
144
Trying to get this to fail but can't. Found the following, any suggestions?

Code:
ian@freenas:/mnt/VOLUME1/nas-admin % sudo sqlite3 /data/freenas-v1.xx "pragma integrity_check;"
ok

ian@freenas:/mnt/VOLUME1/nas-admin % which sqlite3
/usr/local/bin/sqlite3
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
You are trying to get it to fail? Point it to a file that doesn't exist. That should always return an error since a non-existent file will fail the integrity check.
 

warri

Neophyte Sage
Joined
Jun 6, 2011
Messages
1,193
Interestingly enough the sqlite version delivered with FreeNAS seems to create an empty file first, which then passes the check.
This is sqlite 3, version 3.8.1 2013-10-17 12:57:35 c78be6d786c19073b3a6730dfe3fb1be54f5657a in my case (FreeNAS 9.2.1.5).

On my linux machine it fails as expected:
Code:
$ sqlite3 /data/freenas-v1.xx "pragma integrity_check;"
Error: unable to open database "/data/freenas-v1.xx": unable to open database file


But, you can just echo some garbage into a temporary file and check it to make the test fail:
Code:
$ echo "invalid" > freenas-v1.xx
$ sqlite3 freenas-v1.xx "pragma integrity_check;"
Error: file is encrypted or is not a database
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Haha warri, you beat me to it. I did know that from my own testing. It just didn't click right away.
 
Joined
Sep 13, 2013
Messages
144
Is there a shell variable which contains the version number of FreeNAS? I'd like this to be added to my filenames if possible.

i
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
There is!

# cat /etc/version
 
Top