Firstly, a clarification is in order:
- init.d is the directory that stores services control scripts, which control the starting and stopping of services such as
- rc.local is a service that allows running of arbitrary scripts as part of the system startup process
In terms of whether its better to use
cron to run your script, I suspect that it is more a question of aesthetics more than practicality.
cron, as a task scheduler, is intended as a method to perform maintenance or upkeep to a machine, such as checking updates, cleaning caches, or performing security audits. This doesn't mean that it is limited to performing those functions, as it can run any script or command desired at the specified time (such as
rc.local, on the other hand, would fall more within a system configuration type of task, as
rc.local, being executed by the machines init system, is typically responsible for setting the machines network configuration, services or environments (but again, is not limited to just this task).
Both of these points, however, should be tempered by the fact that not all init systems offer an
rc.local mechanism, and not all cron daemons offer an
@reboot psuedo tag.
init.d is the directory that contains the scripts that control services that can be started or stopped on your system (at least on machines that use a
SysV type init system). Depending on your init system and the purpose of your script, it may be reasonable to convert your script into an init script to be run in the same manner as a service. This, however, is heavily dependent on your init system as the framework surrounding how these files are constructed can differ greatly.
It should also be noted that typically bash scripts end with a suffix of
.sh rather than
.txt, as this immediately denotes the file is a shell script instead of a text file. That being said, provided it either has a shebang (
#!/bin/bash) at the top of the file, or is called as
bash /path/to/script.whatever, it shouldn't matter in terms of executing the script.