WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: bootlocal.sh vs cron  (Read 4344 times)

Offline 3rail

  • Full Member
  • ***
  • Posts: 114
bootlocal.sh vs cron
« on: May 15, 2009, 12:54:38 PM »
what's the recommended method for starting a service at boot in tc?  is there any advantage to using bootlocal.sh vs cron?  does it matter?

thanks,

3rail

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: bootlocal.sh vs cron
« Reply #1 on: May 15, 2009, 01:30:19 PM »
For included services it would be a bootcode ("cron", "syslog" etc). For others, cron isn't really meant to start services on-boot, but on certain times.

If you need to only serve http traffic every sunday 4-5, it's cron; if start every boot, I'd put it in bootlocal.sh
The only barriers that can stop you are the ones you create yourself.

Offline 3rail

  • Full Member
  • ***
  • Posts: 114
Re: bootlocal.sh vs cron
« Reply #2 on: May 15, 2009, 02:13:25 PM »
curaga, thanks for the reply.  I see what you're saying.  I'm also thinking why run an extra service like cron for startup items (a la "@reboot") when it's "builtin" to tc.

Offline valuequest

  • Newbie
  • *
  • Posts: 8
Re: bootlocal.sh vs cron
« Reply #3 on: February 17, 2011, 09:37:51 AM »
I am running microcore-3.5.  I tried configuring my bootloader to pass "inet" and "telnet" as boot codes (ref: http://www.tinycorelinux.com/faq.html#bootcodes) but I was not able to get them to start at boot time that way.

I then tried put "inetd&" and "telnetd&" into /opt/bootlocal.sh, and that seems to start them at boot time

Just out of curiosity am I missing something about using boot codes to start these two daemons?  Both inetd and telnetd are part of busybox right? So they shouldn't need any other extensions loaded before they are able to start right?

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: bootlocal.sh vs cron
« Reply #4 on: February 17, 2011, 09:44:36 AM »
There are no bootcodes for inetd or telnetd, so your approach of starting them in bootlocal.sh is correct.
The only barriers that can stop you are the ones you create yourself.