Setup Script to run at boot using crontab?

Froto

New Member


Messages: 7

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,
Code:
@reboot syncthing "sh /home/syncthing/runsync.sh"
^^using Nano to edit /etc/crontab
or,
Code:
@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

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,744
Messages: 39,332

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.
 
OP
F

Froto

New Member


Messages: 7

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

Code:
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

Son of Beastie

Reaction score: 2,112
Messages: 3,792

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):

Code:
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.
 
OP
F

Froto

New Member


Messages: 7

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
Code:
@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.
 
Last edited:

gkontos

Daemon

Reaction score: 488
Messages: 2,160

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

Son of Beastie

Reaction score: 2,112
Messages: 3,792

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).

So:
I have tried creating the following crontab
Code:
@restart touch /home/syncthing/test

Which should place a blank test file in that directory. But nothing is there.
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

Beastie's Twin

Reaction score: 2,747
Messages: 5,682

Slightly off topic:

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

ralphbsz

Son of Beastie

Reaction score: 2,407
Messages: 3,282

Yes. Before and after.
Look at the top of /etc/rc.d/cron:
Code:
# 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

Beastie's Twin

Reaction score: 2,747
Messages: 5,682

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

Son of Beastie

Reaction score: 2,407
Messages: 3,282

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

Beastie's Twin

Reaction score: 2,747
Messages: 5,682

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

Son of Beastie

Reaction score: 2,112
Messages: 3,792

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).
 
OP
F

Froto

New Member


Messages: 7

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

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

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

Froto

New Member


Messages: 7

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. :D
 
Top