Execute script after FreeBSD is rebooted

Actually, the way described in the linked article (using @reboot with cron) does work.
If it doesn't work for you, there's probably a mistake in the script or in the way it is called. In particular, the script runs with a reduced environment, for example the PATH is different. See the crontab(5) manual page for details. Also, if there is any problem with your cron job, you will receive the output (error messages) via e-mail.

Would you please share your exact crontab entry with us? Might be easier to advise what the problem could be. Also, do you receive output from the cron job via e-mail?
 
Indeed, there are several ways to execute things upon reboot.
Just keep in mind that rc scripts are executed with root privileges. If you don't need that, it's safer to use a user cronjob.
 
I tried to understand rc i made following script which is located in /etc/rc.d/:

Code: 
#!/bin/sh

. /etc/rc.subr

name="dir"
start_cmd="${dir}_start"
stop_cmd=":"

dir_start()
{
    mkdir /test
}
But this does not work. What have i made wrong?


olli@ said:
Actually, the way described in the linked article (using @reboot with cron) does work.
Click to expand...
I made a script which is located in /.
I edit the crontab -e file and paste following in this file: @reboot /script.sh and tried. Does not work. Than I have edit it: @reboot sh /script.sh.
Does still not work.

//
Execute as root is OK.
 
Sessa said:
I made a script which is located in /.
I edit the crontab -e file and paste following in this file: @reboot /script.sh and tried. Does not work. Than i have edit it: @reboot sh /script.sh.
Does still not work.
Click to expand...
Is the script executable (chmod +x)? Does it produce any output? If in doubt, put something like this at the beginning:
Code: 
date >> /tmp/script-debug.log
So you can see if your script is started at all.
Also, look in /var/mail if you have any output mailed from the cron job.
If your mail system is not configured correctly, a work around is to redirect all output to a log file:
Code: 
@reboot /script.sh >> /tmp/script-output.log 2>&1
 
Sessa said:
Code: 
start_cmd="${dir}_start"
Click to expand...
Typo here. The variable ${dir} doesn't exist, it should probably be ${name} instead. In your version the start_cmd points to a function named _start (which doesn't exist) when it should be pointing to dir_start.
 
olli@ said:
Is the script executable (chmod +x)?
Click to expand...
Yes.

olli@ said:
So you can see if your script is started at all.
Click to expand...
There is no file. So the script was not executed. Any other idea?
@reboot sh /script.sh OR @reboot /script.sh?

SirDice said:
The variable ${dir} doesn't exist, it should probably be ${name} instead. In your version the start_cmd points to a function named _start (which doesn't exist) when it should be pointing to dir_start.
Click to expand...
Could you show me how the script is right? So maybe i understand it than better :)
For the beginning it is OK when the script creates a dir.
 
This is wrong:
Code: 
start_cmd="${dir}_start"
It should be:
Code: 
start_cmd="${name}_start"
OR
Code: 
start_cmd="dir_start"

The ${name} is a variable. It's set on the line above it: name="dir".

If you're having trouble with shell scripts I can highly recommend: http://www.grymoire.com/Unix/Sh.html
It's an old site but I still use it quite often for reference.
 
Sessa said:
I tried to understand rc i made following script which is located in /etc/rc.d/:
Click to expand...
Your script should contain at least one REQUIRE line. Otherwise it is undefined at which point it is executed during reboot (for example, it could be executed before file systems are mounted, which is probablt too early). This is documented in the rcorder(8) manual page. To run the script rather late during reboot (so filesystems, networking and the standard daemons are running), the following dependency line can be used:
Code: 
# REQUIRE: LOGIN
 
Sessa said:
There is no file. So the script was not executed. Any other idea?
Click to expand...
That's very strange. Do you have cron disabled? (By default it's enabled.)
Otherwise I guess there must be something fundamentally wrong with your script.
@reboot sh /script.sh OR @reboot /script.sh?
Click to expand...
Both should work. By default cron uses /bin/sh to execute commands (see the description of the SHELL variable in the crontab(5) manual page), so you don't have to specify it.
Actually, just specifying “sh” (as opposed to “/bin/sh”) is not a good idea, because it relies on the PATH setting.
 
Alright, got it. I have define a wrong bash location in the crontab file.
I comment it out and everything works fine.

When i try to set another editor with @reboot setenv EDITOR /usr/local/bin/nano directly in the crontab, is does not work?
 
Sessa said:
Alright, got it. I have define a wrong bash location in the crontab file.
I comment it out and everything works fine.
Click to expand...
It's better to use the base system's /bin/sh for such things, not bash.
When i try to set another editor with @reboot setenv EDITOR /usr/local/bin/nano directly in the crontab, is does not work?
Click to expand...
Wait a second – Are you trying to set an environment variable globally for all users? In that case, a reboot script is not the right place to do that, because the variable is only set for the duration of the script. You probably want to modify /etc/login.conf instead.
However, it's usually not good practice to force such settings on all users. If you prefer nano personally, you should set the EDITOR variable inside your login shell's profile (the details depend on which login shell you use).
 
olli@ said:
If you prefer nano personally, you should set the EDITOR variable inside your login shell's profile (the details depend on which login shell you use).
Click to expand...

Ah, that's a good idea.
If I set the editor variable to nano and then reboot, the default editor is Vim again.
With this "restart script" I would want to make the env again set as the default editor on nano.
 
Sessa said:
When i try to set another editor with @reboot setenv EDITOR /usr/local/bin/nano directly in the crontab, is does not work?
Click to expand...
Well, actually it does work but is in essence useless. What happens is that the EDITOR variable gets set, a shell is spawned (with the variable set) and this shell closes immediately. So for a short period the EDITOR variable was indeed changed but only for that short-lived sub-shell. This is probably not what you intended to do.
 
Sessa said:
If I set the editor variable to nano and then reboot, the default editor is Vim again.
Click to expand...
The default editor is vi(1), not vim(1). There is a difference (editors/vim has to be installed, vi(1) is part of the base OS).

You don't need to reboot for this. Just source(1) the right file.
It's going to depend on that user's shell; ~/.cshrc is for csh(1)/tcsh(1), ~/.profile is for sh(1) and other Bourne compatible shells (i.e. bash, zsh).
 
You need to edit the file /.cshrc if using the stock shell. This will change the root user editor.
My preferred editor is ee or "easy editor". Very similar to nano.
So to change to nano you will need to use some other editor to make the change.
For instance:
ee /.cshrc
This brings up the FreeBSD editor and all you need to do is change the line that says EDITOR=vi to EDITOR=/usr/local/bin/nano
Once editing is complete hit ESC key and save and exit.

If you want to change a users shell editor the command would be like this:
ee /home/username/.cshrc

I really think you need to drop the Linuxisms and adopt ee right now. It is so simple a kid could use it.
On a new install I change mine from vi to ee with EDITOR=ee
No weird shortcut keys needed. All commands are shown on screen. The ESC key brings up the menu.
It is very similar to nano but is in our base system. Learn it and set yourself free.
 
Sessa said:
I'm logged in as root user.
Click to expand...
Explain: Why are you trying to do a system-wide change while logged in as root?

The correct way to do this: log in as a normal user, and do the change for that user. In a nutshell, the only thing root should ever do is to administer the system to keep running. Some people even say that root should never log in at all, instead normal users should execute system administration commands one at a time with sudo.

Another thing: be very careful changing files like .cshrc for the root user. If you screw up, and root can't log in, or can't work effectively, you have a system that is very difficult to repair (probably have to use the console and do the single-user boot thing, which is hard). I would leave the root user alone.

I don't care which editor you use. If you like vim instead of vi, use it. I happen to like emacs, and use it as the default editor. To each their own.

(Having said that, I don't actually follow my advice above: Not only do I log into an account that has ID 0, I even change the login shell of that account to be bash instead of tcsh. However, that account is not root, and ssh logins to those accounts is disabled.)
 
The file /.cshrc is only used in single-user mode (when “/” is the home directory). During normal operation, when you log in as the root user (which is strongly discouraged!), /root is the home directory, so you should make that change to /root/.cshrc. However, it is better not to log in as root. You can, for example, use su -m to change to root privileges while logged in as normal user. In that case, your normal user environment stays the same, including the setting of EDITOR that you have as normal user.

Please note that Phishfry made a small mistake in his advice above. csh(1) has a different syntax for setting environment variables than most other shells. So, instead of writing EDITOR=/usr/local/bin/nano (sh syntax) you need to write setenv EDITOR /usr/local/bin/nano (csh syntax).

Another point to keep in mind: For historical reasons, there are two different environment variables to specify the editor: EDITOR and VISUAL. The first is intended to be used for line editors such as ed(1) and ex(1), and the latter for full-screen editors such as vi(1) and ee(1). Applications don't use these variables consistently, so it's better to always set both to the same value. So in your case, you need these lines for csh:
setenv EDITOR /usr/local/bin/nano
setenv VISUAL /usr/local/bin/nano
 
Normally /.cshrc and /root/.cshrc are hard-linked and thus should be exactly the same.

Code: 
dice@armitage:~ % ls -li /.cshrc /root/.cshrc
130082 -rw-r--r--  2 root  wheel  1259 Mar 12  2014 /.cshrc
130082 -rw-r--r--  2 root  wheel  1259 Mar 12  2014 /root/.cshrc
 
You must log in or register to reply here.
Back
Top