How do I start a cron job immediatly on boot up/reboot?

Currently, I have the streaming codes,server starting code and a script to automatically email the nano’s IP address to a gmail account.

When I enter crontab -e :

@reboot sleep 20 && sudo /usr/bin/python3

@reboot sleep 25 && sudo

@reboot sleep 35 && sudo

This however does not work on boot up.

When I enter this code on the terminal,

sudo /usr/bin/python3

It works normally but not with the crontab.

After research, it seems I have to specify the /home/ directory but the problem is I can’t cd the /home directory.

Here is a screenshot of where my scripts and .py files are:

Should I also enter root using “sudo -s” and edit the crontab or just use my normal account to enter the crontab? I realised that the crontabs on these are not the same.

Another doubt I have on why it does not work is because there is a password required(I think) to start these scripts and maybe crontab does not have permissions to this. If so, is there a workaround to it? Thank you!

I won’t be able to answer, but here is some information which will probably help.

The init scripts already run as root. You wouldn’t use sudo unless you want a non-root user to execute something…and then you wouldn’t use a “-s” shell.

By far the best way to deal with this, if placing it at the end of “/etc/rc.local” does not do the job, would be to learn about the systemd method of creating services, where one service depends upon another and the final service only runs after the prerequisites are in place. In your case a prerequisite might be networking is up.

There are a number of interesting files related to this in “/etc/systemd/”. Some of those files are simply symbolic links to the default systemd files in “/lib/systemd/”. Others are copies of the default files, with simple edits. Placing a file here with the same name as an existing “/lib/systemd/” file overrides the original, but deleting that file reverts back to the original. When a system has multiple boot options, then usually a symbolic link is placed somewhere in this location to the choice, but all choices still exist in “/lib/systemd/”…the pick is via the symbolic link.

A service is what you might want to create, with a dependency on another service. A good example is that “” is a text mode boot target, “” is a graphical boot mode, and depending on which is configured, then either the “/etc/systemd/” or the “/etc/systemd/” content will be consulted…requesting the target results in fulfilling the dependencies first. Note that NetworkManager.service is a symbolic link to these, and that (text mode boot) will result in the NetworkManager being up prior to start (or as a side effect of start).

The syntax of the files is simple, and lots of examples there. Once you learn this, if rc.local can’t handle the task, but systemd will actually simplify more complicated boot requirements.

Note that the “systemctl” command is the interface for command line interaction with systemd. For example, to see the status of NetworkManager:

systemctl status NetworkManager

+1 for learning about systemd

It’s worth the effort, and mostly all modern Linux distros use it for this kind of thing, including L4T and Ubuntu itself.

Here is an article that might help you accomplish what you want:

tip: you can specify a specific user and group for the script to run as if you do not want it to run as root in the in the [Service] section using the User= and Group= options.

Hi linuxdev,

Thank you for the detailed reply!

I’m alittle sceptical about messing with system files as I’m worried they may mess up my system and I’d have to erase all my progress. Is there a safe way to go about learning the systemd method?

Also, can I ask what is the proper way to specify the home directory for my cron? I can’t cd /home/ so how do I specify it? is it

@reboot sleep 20 && sudo /usr/bin/python3 /home/

or just @reboot sleep 20 && sudo /usr/bin/python3 (Since the .py script is in the home/~ directory

Any script you add to “/etc/systemd/…” is likely somewhat safe. Not guaranteed, but unless you actually remove some other script or edit an existing script, risk is fairly low.

Normally I would tell someone to clone their system before doing something risky. Now if you are running an eMMC Nano variant, this is still true. If you are using an SD card version, then you just plug the SD into another computer and erase or neutralize the offending file you added.

I’m not sure about the home directory question, but if this is part of the system, then I’d suggest putting the extra content somewhere like “/usr/local/bin/” or “/usr/local/etc/” or similar (you’d still add content to the “/etc/systemd/…” location). If you can’t “cd /home”, then something is wrong…the filesystem should be mounted.

PS: I often just bzip2 a file to temporarily neutralize it.

I agree with linuxdev. Adding a unit (.service) file to systemd/system/… is probably safer than modifying rc.local

Cloning the system beforehand is also a decent idea just in case.

I did happen to notice you seem to be trying to keep track of your public IP each time the nano restarts. It may be easier to do that with a dynamic DNS client (noip, etc…).

Otherwise if your public IP is reassigned in between boots you won’t be able to access your nano from outside. Noip’s utility should build from source on nano but I haven’t specifically tested it.

Putting the script in /use/local/bin is a good suggestion. It should probably be owned by root but executed by a dedicated system user. You can use the adduser command with the --system option. Run --help for a full list. You probably also want disabled password and no home directory.

Then follow the article I posted earlier on how to create and install a unit (.service) file and add your new user and group as suggested. Of course creating a new user is optional but it’s generally a good idea not to have anything running as root (default) that doesn’t absolutely need to.