# Setup Script to run at boot using crontab?



## Froto (May 5, 2017)

Hi,

So I'm trying to set a script, so it starts on boot. The problem is, I'm using "@reboot" and I don't think that is working.
I have:

Tried modifying /etc/crontab as root
using crontab -e -u syncthing
tried various commands, IE: "@restart touch /home/syncthing/test"
I have surfed the net, and some mentioned that @restart is bugged or that it can only be initiated by the root user. Is this true? What can I try to make this work?

The command I'm looking to execute is,

```
@reboot syncthing "sh /home/syncthing/runsync.sh"
```
^^using Nano to edit /etc/crontab
or,

```
@reboot "sh /home/syncthing/runsync.sh"
```
^^as syncthing user running crontab -e

Note, I've also tried this without "sh" in the command.

If possible, I would greatly appreciate your help.
Thanks in advance

Edit: I forgot to mention that this is in a jail.


----------



## SirDice (May 5, 2017)

Look in /var/log/cron and check the user's mail. Errors will show up in the logging and if the script itself produces any output (error messages for example) the output will be mailed to the user.


----------



## Froto (May 5, 2017)

Hmm, well I checked the output in /var/log/cron and there doesn't seem to be anything out of the ordinary.


```
May  4 23:27:22 sync newsyslog[48818]: logfile first created
May  4 23:27:22 sync /usr/sbin/cron[48883]: (CRON) WARNING (madvise() failed)
May  4 23:30:00 sync /usr/sbin/cron[50535]: (root) CMD (/usr/libexec/atrun)
May  4 23:35:00 sync /usr/sbin/cron[51178]: (root) CMD (/usr/libexec/atrun)
May  4 23:40:00 sync /usr/sbin/cron[51724]: (root) CMD (/usr/libexec/atrun)
May  4 23:45:00 sync /usr/sbin/cron[48883]: (*system*) RELOAD (/etc/crontab)
May  4 23:45:00 sync /usr/sbin/cron[52302]: (root) CMD (/usr/libexec/atrun)
May  4 23:50:00 sync /usr/sbin/cron[52856]: (root) CMD (/usr/libexec/atrun)
May  4 23:55:00 sync /usr/sbin/cron[53389]: (root) CMD (/usr/libexec/atrun)
May  5 00:00:00 sync /usr/sbin/cron[53943]: (root) CMD (newsyslog)
May  5 00:00:00 sync /usr/sbin/cron[53945]: (root) CMD (/usr/libexec/atrun)
May  5 00:01:00 sync /usr/sbin/cron[54111]: (root) CMD (adjkerntz -a)
May  5 00:05:00 sync /usr/sbin/cron[54555]: (root) CMD (/usr/libexec/atrun)
May  5 00:10:00 sync /usr/sbin/cron[55088]: (root) CMD (/usr/libexec/atrun)
May  5 00:12:00 sync /usr/sbin/cron[48883]: (*system*) RELOAD (/etc/crontab)
May  5 00:15:00 sync /usr/sbin/cron[55668]: (root) CMD (/usr/libexec/atrun)
May  5 00:19:00 sync /usr/sbin/cron[48883]: (*system*) RELOAD (/etc/crontab)
May  5 00:20:00 sync /usr/sbin/cron[56220]: (root) CMD (/usr/libexec/atrun)
May  5 00:20:11 sync crontab[56251]: (syncthing) BEGIN EDIT (syncthing)
May  5 00:21:00 sync /usr/sbin/cron[48883]: (*system*) RELOAD (/etc/crontab)
May  5 00:25:00 sync /usr/sbin/cron[56746]: (root) CMD (/usr/libexec/atrun)
May  5 00:27:30 sync crontab[56251]: (syncthing) REPLACE (syncthing)
May  5 00:27:31 sync crontab[56251]: (syncthing) END EDIT (syncthing)
May  5 00:27:35 sync crontab[57018]: (syncthing) BEGIN EDIT (syncthing)
May  5 00:27:42 sync crontab[57018]: (syncthing) END EDIT (syncthing)
May  5 00:29:05 sync crontab[57216]: (root) BEGIN EDIT (syncthing)
May  5 00:30:00 sync /usr/sbin/cron[57295]: (root) CMD (/usr/libexec/atrun)
May  5 00:30:06 sync crontab[57216]: (root) REPLACE (syncthing)
May  5 00:30:07 sync crontab[57216]: (root) END EDIT (syncthing)
May  5 00:31:00 sync /usr/sbin/cron[48883]: (syncthing) RELOAD (tabs/syncthing)
May  5 00:31:00 sync /usr/sbin/cron[57428]: (root) CMD (adjkerntz -a)
May  5 00:32:01 sync crontab[57563]: (root) BEGIN EDIT (root)
May  5 00:32:05 sync crontab[57563]: (root) END EDIT (root)
May  5 00:33:35 sync /usr/sbin/cron[58982]: (CRON) WARNING (madvise() failed)
May  5 00:33:35 sync /usr/sbin/cron[58987]: (syncthing) CMD (/home/syncthing/runsync.sh )
May  5 00:35:00 sync /usr/sbin/cron[59842]: (root) CMD (/usr/libexec/atrun)
May  5 00:40:00 sync /usr/sbin/cron[60362]: (root) CMD (/usr/libexec/atrun)
May  5 00:45:00 sync /usr/sbin/cron[60893]: (root) CMD (/usr/libexec/atrun)
May  5 00:50:00 sync /usr/sbin/cron[61424]: (root) CMD (/usr/libexec/atrun)
May  5 00:55:00 sync /usr/sbin/cron[61942]: (root) CMD (/usr/libexec/atrun)
May  5 01:00:00 sync /usr/sbin/cron[62478]: (root) CMD (newsyslog)
May  5 01:00:00 sync /usr/sbin/cron[62481]: (root) CMD (/usr/libexec/atrun)
May  5 01:01:00 sync /usr/sbin/cron[62622]: (root) CMD (adjkerntz -a)
May  5 01:05:00 sync /usr/sbin/cron[63061]: (root) CMD (/usr/libexec/atrun)
May  5 01:10:00 sync /usr/sbin/cron[63579]: (root) CMD (/usr/libexec/atrun)
May  5 01:15:00 sync /usr/sbin/cron[64109]: (root) CMD (/usr/libexec/atrun)
May  5 01:20:00 sync /usr/sbin/cron[64630]: (root) CMD (/usr/libexec/atrun)
May  5 01:25:00 sync /usr/sbin/cron[65169]: (root) CMD (/usr/libexec/atrun)
May  5 01:30:00 sync /usr/sbin/cron[65682]: (root) CMD (/usr/libexec/atrun)
May  5 01:31:00 sync /usr/sbin/cron[65796]: (root) CMD (adjkerntz -a)
May  5 01:35:00 sync /usr/sbin/cron[66238]: (root) CMD (/usr/libexec/atrun)
May  5 01:40:00 sync /usr/sbin/cron[66758]: (root) CMD (/usr/libexec/atrun)
May  5 01:45:00 sync /usr/sbin/cron[67284]: (root) CMD (/usr/libexec/atrun)
May  5 01:50:00 sync /usr/sbin/cron[67815]: (root) CMD (/usr/libexec/atrun)
May  5 01:55:00 sync /usr/sbin/cron[68336]: (root) CMD (/usr/libexec/atrun)
May  5 02:00:00 sync /usr/sbin/cron[68862]: (root) CMD (newsyslog)
May  5 02:00:00 sync /usr/sbin/cron[68866]: (root) CMD (/usr/libexec/atrun)
May  5 02:01:00 sync /usr/sbin/cron[68999]: (root) CMD (adjkerntz -a)
```

It shows a bunch of edits, made by me, but it doesn't say anything about a failed run. 

I searched up "madvice() failed" but I haven't gotten any clear anwsers.

Edit: I forgot to mention that I'm running this in a jail.


----------



## ShelLuser (May 6, 2017)

First thing springing to mind: you don't need to start a shell followed by the shell script. Just access the script directly, and use the shebang to sort out the shell to use. For example, this is how my custom ZFS snapshot script gets run (from `# crontab -l`):


```
peter@breve:/usr/local/etc/postfix# crontab -l
## ZFS snapshots
10 3 * * *      /root/bin/snapshot.zfs y
15 3 * * *      /root/bin/snapshot_zdata.zfs y
```
Where the script starts with the obvious shebang: #!/bin/sh.

Anyway, if the logfile doesn't mention anything then check the users mailbox. A cronjob always mails the produced output.


----------



## Froto (May 6, 2017)

Unfortunately, I haven't setup mailbox.
I have also tried removing the "sh" part.

From what SirDice says, it's only when the script I'm running encounters an error that I get emailed a message. So:
I have tried creating the following crontab

```
@reboot touch /home/syncthing/test
```

Which should place a blank test file in that directory. But nothing is there.

Edit: The script command is actually "reboot" I typed "restart by mistake.


----------



## SirDice (May 6, 2017)

Where are you adding this? In the user's crontab(1)?


----------



## gkontos (May 6, 2017)

Make sure that you declare all paths in your script. A script executed by cron has no idea regarding /usr/local/bin for example.


----------



## ShelLuser (May 6, 2017)

Froto said:


> From what SirDice says, it's only when the script I'm running encounters an error that I get emailed a message.


He didn't say that, your assumption is incorrect. _Any_ output created by a cronjob will get mailed, it doesn't matter if this is through stdout (normal way for programs to show text) or stderr (used to separate errors from regular output).



Froto said:


> So:
> I have tried creating the following crontab
> 
> ```
> ...


Which is why it's important to pay attention to your e-mail output. Check crontab(5), you don't want @restart, you want @reboot. Also nice to know: it'll work on any crontab, system and user based.


----------



## Phishfry (May 6, 2017)

Slightly off topic:

Does a `cron` job with a '@reboot' crontab file start before or after /rc.d scripts in the bootup sequence?


----------



## ralphbsz (May 6, 2017)

Yes.  Before and after.
Look at the top of /etc/rc.d/cron:

```
# REQUIRE: LOGIN FILESYSTEMS
# BEFORE: secure level
```
On my system, if I run `rcorder /etc/rc.d/* /usr/local/etc/rc.d/*`, then cron runs 148th out of 177 files (immediately after sendmail).  Your mileage will vary, depending on what is installed.


----------



## Phishfry (May 6, 2017)

Ahaha. I was assuming cron was a separate facility. So it is started with /etc/rc.d and its just a matter of rc' ordering.


----------



## ralphbsz (May 6, 2017)

Froto said:


> Unfortunately, I haven't setup mailbox.


So you are trying to debug something without seeing what is going on.  That's like driving a car blindfolded.

Suggestion: If setting up sendmail is too complicated, try setting up some simplified system to get mail into a readable form.  I personally happen to like the ssmtp package, it simply takes any mail generated on my FreeBSD box and ships it to a real mail host (including mail that is intended for root, which I rewrite in ssmtp.conf to go to a specific username).

There are many other ways to install simplified mail replacements.


----------



## Phishfry (May 6, 2017)

Why would you use a `cron` event for this instead of straight rc.d startup script. Especially if it is nested in /etc/rc.d anyway?
That is my philosophical question.
Please forgive my ignorance.
What is it that `cron` offers that would make this worthy over a straight startup rc.d script?


----------



## ShelLuser (May 6, 2017)

Phishfry said:


> Why would you use a `cron` event for this instead of straight rc.d startup script. Especially if it is nested in /etc/rc.d anyway?


Well, ease of administration and preventing a massive clutter.

For example, lets say I have some jobs I need to sort out for Dovecot. I could create an rc.d script, but since I already have /usr/local/etc/rc.d/dovecot how should I name this new one?

Another issue is that an rc.d script is more troublesome. After all: it gets started as root yet in most cases you don't want that to happen (think about file permissions and such). So if you resort to cron you can be sure that everything runs with the right user id.

And finally standardization. Letting cron handle all this also ensures that you will always know where to find these auxiliary scripts. A 'rogue' rc.d script is easy to overlook, but you only need to peek in /var/cron/tabs to get a direct overview (either that or /etc/crontab of course).


----------



## Froto (May 17, 2017)

Hey guys, sorry for the late response, I was away from home for a long while. 

I have setup email for the FreeBSD jail and you guys were right. Having an email setup definitely, makes the process easier. 

I have just received an error from crontab:

/bin/sh: /usr/home/sync/run.sh: Permission denied


```
/bin/sh: /usr/home/sync/run.sh: Permission denied
```

Is it because I'm starting the script with #!/bin/sh?


----------



## Froto (May 17, 2017)

Edit: I think its working now. I suspect maybe its because I did not append chmod +x run.sh to the script. 

Sorry for the trouble, and thanks for the help! At the very least, I've now started setting up emails for my FreeBSD jails.


----------

