Postinit script - commands not found

[Glorious1]

I have a script that controls my fans in response to drive temperature. It works fine when I execute it manually. But when I have it executed on startup, as a postinit script, it doesn't work.

"Luckily", when I restarted, FreeNAS didn't know what drive to use for booting, as it sometimes does. I had to go into the KVM/IPMI console to direct it to a boot drive. Watching that console, I saw that it tried to run the script, but many commands resulted in "Command not found".

My main question is, how can I execute the script automatically after startup, such that it can find the commands? But I'm also wondering about the console output. I couldn't find it in any log in /var/log. Does that stuff get logged? And why is this console output different from the console output that shows in the FreeNAS WebUI?

 

[dlavigne]

Hard to troubleshoot without seeing the actual script...

Also, which build version of FreeNAS (from System -> Information)?

 

[Glorious1]

Thanks dlavigne. The script is in the linked post (3rd code block in that post) in the first post here, but I'm not sure you want to look at it. It is fairly long and complex. There were multiple commands in the script that got the "Command not found". The one I recall was ipmitool.

The build is FreeNAS-9.10-STABLE-201606072003 (696eba7)

Maybe some stuff doesn't get loaded until after "post-init" scripts are run? If so, is there a way to run it post-post-init?

 

[Spearfoot]

The 'shebang' spec in your script...

Code:

#!/usr/local/bin/bash

...differs from what I use in my post-init script:

Code:

#!/bin/bash

Might this be the problem?

 

[Glorious1]

/bin/bash appears to be simply a link to /usr/local/bin/bash, so I can't see how that would make any difference. But I'm pretty ignorant, and will give it a try later unless some other ideas come along.

Code:

[jim@Tabernacle ~]$ ls /bin
total 1732
drwxr-xr-x  2 root  wheel  47B Jun 17 16:40 ./
drwxr-xr-x  19 root  wheel  27B Jun 22 06:20 ../
-r-xr-xr-x  2 root  wheel  11K Jun 17 16:40 [
lrwxr-xr-x  1 root  wheel  19B Apr 21 17:48 bash -> /usr/local/bin/bash
. . .

 

[Spearfoot]

/bin/bash appears to be simply a link to /usr/local/bin/bash, so I can't see how that would make any difference. But I'm pretty ignorant, and will give it a try later unless some other ideas come along.

Code:

[jim@Tabernacle ~]$ ls /bin
total 1732
drwxr-xr-x  2 root  wheel  47B Jun 17 16:40 ./
drwxr-xr-x  19 root  wheel  27B Jun 22 06:20 ../
-r-xr-xr-x  2 root  wheel  11K Jun 17 16:40 [
lrwxr-xr-x  1 root  wheel  19B Apr 21 17:48 bash -> /usr/local/bin/bash
. . .

Well, it was just a thought...

You said:

There were multiple commands in the script that got the "Command not found". The one I recall was ipmitool.

Which leads me to another thought...

You may need to specify the full path to any programs your script calls, ipmitool being one such.

Why? I dunno. I'm not a UNIX guru... but I have found out, by trial and error, that I have to do this in my own startup scripts.

One example is the smartctl program. If I don't give the full path to it in my startup script, I get 'command not found' errors just like you describe, while the same script will run flawlessly from a shell.

Smartctl example:

 

[Glorious1]

OK, you're onto something here. Now I remember that smartctl was another command in the script that didn't work. I guess that's a fairly easy fix then. But obviously the system is not fully loaded when the script runs, I guess I need to make a feature request to run post-init scripts later or have another option for post-post-init.
Thanks Spearfoot!

 

[Robert Trevellyan]

obviously the system is not fully loaded when the script runs

I think it's more a case of the scripts being launched in an environment in which the normal search path is not set. You typically have to specify full paths to commands launched by cron jobs, for the same reason.

 

[Spearfoot]

I think it's more a case of the scripts being launched in an environment in which the normal search path is not set. You typically have to specify full paths to commands launched by cron jobs, for the same reason.

Makes sense... but OTH I thought UNIX always loaded the root (or other specified user's) profile to run any shell scripts. It always seems to have at least a minimal path specification configured -- for example, 'tee' executes without having to include the full path spec to /usr/bin/tee.

 

[Glorious1]

Makes sense... but OTH I thought UNIX always loaded the root (or other specified user's) profile to run any shell scripts. It always seems to have at least a minimal path specification configured -- for example, 'tee' executes without having to include the full path spec to /usr/bin/tee.

In my script, only two commands required the path - ipmitool and smartctl. The others that didn't include
tee
case
printf
while
date
expr
grep
if
awk
bc
sleep

 

[Spearfoot]

In my script, only two commands required the path - ipmitool and smartctl. The others that didn't include
tee
case
printf
while
date
expr
grep
if
awk
bc
sleep

So it looks like no user settings are loaded and you just get a standard shell environment in chron, at startup, etc. I suppose this explains why add-on tools (smartctl, ipmitool) aren't available.