The Service Manager is a daemon, that's roughly what Windows folks call a Service.
Technically, cron is NOT the place to start daemons. The place to start daemons is the system's start mechanism, which is the System V init (/etc/init.d) with older Linux, "upstart" for a brief period on Debian/Ubuntu, or systemd on most current Linux variants. Of course you
can do it from cron, but it's sort of wrong, and has some drawbacks:
- other UNIX admins won't neccessarily look in your crontab - not a problem if you alone are maintaining it, but with multiple people it pays to stick to standards
- you can not use the established ways of starting and stopping it manually (but someone has to know where your custom shell script is) - same as above
- graphical, web based (such as webmin, god forbid someone use that) or text-based system configuration tools (such as the venerable "chkconfig" and friends) can't be used to configure your daemon (which, again, may confuse other people who might maintain your system).
- you lose useful logging, especially with systemd
- your systemd commands on a modern system will be blind to the status of your daemon, and all other commands that depend on it will be, too. E.g. if you manage multiple systems with Puppet, that becomes a liability fast
- you lose the (direct) ability do make dependencies (especially with upstart and systemd), e.g. "start Automic only after the network has started"
- stuff possibly doesn't get stopped properly when you shut the server down (or switch "run level").
Therefore, it's recommended that you find out what startup system your distribution uses.
System V:
you can use a script like the one
Vlad_Navazhylau_6186 gave in /etc/init.d. There is a multitide of tutorials if one googles "system v init tutorial" or such, but in short: Put your script in /etc/init.d, make sure it starts your Service Manager when called with the parameter "start" and ends it when called with "stop". Find out your systems run-level by typing "runlevel" (it's the rightmost number in the output, usually "3" for text based servers), then symlink it to the respective directory (/etc/init.d/rc.3.d for runlevel 3). The system will run each script with the parameter "start" that it finds in that directory when it enters the respective runlevel (i.e. when it boots), and with "stop" when it leaves that run level (e.g. shuts down).
If you want to avoid doing that work, most distributions have an /etc/init.d/rc.local as a collective script for all server-local things, you can put your Service Manager start commands (or script reference) in there, too.
Bonus: You
can also tell Linux to ensure your service manager is always running, by entering it with the /etc/inittab with the "respawn" keyword. This is better than doing it in cron, because a) you don't need to wait for it respawning until the next run of your cronjob, and b) it works even if cron has crashed (yes, I've seen it happen multiple times). But I do NOT recommend using this mechanism, because sometimes you WANT to [edit] stop Automic, and I can forsee some other issues with that. So I recommend you use a start script as described above.
Upstart:Sorry, you are on your own, but upstart is mostly dead imho, and most distributions replace it by systemd anyways
Systemd:I already posted an example systemd unit file here, use systemctl and friends to manage your systemd start up afterwards.
Best,
Carsten