Tiny Core Extensions > TCE News

Basic init.d script example

<< < (2/4) > >>

jpeters:

--- Quote from: Juanito on December 02, 2009, 10:26:34 PM ---
--- Quote from: Jason W on December 02, 2009, 05:18:09 PM ---..and I believe cups likes X to be already started (correct me Juanito if I am wrong about cups).

--- End quote ---

It looks that way, but I've not yet managed to find out why.

--- End quote ---

yep.....

Jason W:
Upstart is definitely a no go.  It is a replacement for the init process and seems Debian/Ubuntu specific.  

The alsa issue is one that also seems to affect Arch and other fast booting distros when alsa restoring is done during boot.  My thoughts are that as some machines require a "waitusb" boot code, the user simply adds the boot code to accomodate his machine.  And on boot, if a command or script in bootlocal needs a couple of seconds for other parts of the system to settle, then a simple sleep command will do.  I added various checks for waiting on depmod & udevtrigger to complete, as well as the presence of /proc/asound directory to the alsa init.d script to no avail.  Rather than adding any possible test conditions to the init.d script, I think even if that did work it is better for a user to add a sleep command to bootlocal.sh if his machine needs it.  There should not be many scripts affected like this, and for the ones that are the remedy is common knowledge, and will also be put in the info file.

As for a way a system to start the init scripts, we have bootlocal.sh. Or .xsession for things needing to start after X.  I would like this process to stay as simple as possible.

combo3:
Having submitted two extensions with daemon scripts affected by this policy, I have a few questions.

For monkey, I debated placing the daemon in four places:

 - /etc/init.d (where the author intended),
 - /usr/local/etc/init.d (the logical alternative)
 - /usr/local/bin
 - /usr/local/sbin
 
I ruled out the first choice for PPI compatability reasons, and would have gone with the second except that it requires the user to enter the complete path or create an alias.

Options 3 and 4 require some explaining:

Monkey can be run by any user on unprivileged ports, but requires root privileges for anything below 1024. To keep things simple (and avoid confusion over something which may not be readily apparent), I modified the script to run only as root user and placed it in /usr/local/bin

So my first question is:

Will /usr/local/etc/init.d be included in the environment path for future releases,
or is there a valid reason why it isn't?

My second question concerns config files.

Some extensions put them in /home/tc/.app while others put them in /home/tc/.config/app

Which is the preferred location?

Finally, what role (if any) does /opt play in Tinycore vis-a-vis extensions?

Jason W:
Are you talking about a wrapper or an init script?  A wrapper would go in /usr/local/bin,sbin as usual.

Init scripts use a start, restart or stop switch, and are usually not in $PATH.  /etc/init.d is never in $PATH in the distros I have used though their init scripts are there.  We use /usr/local/etc/init.d for PPI compatibility.  And with one basic location, it is simpler to locate them. 

Very few extensions are installed into /opt, but perhaps /opt/init.d would be the logical place.

Config files are normally determined by the application itself as far as the ones in /home.  But for the /etc/ config files, my preference is in /usr/local/etc or /usr/local/etc/appname.  Sometimes /etc is hardcoded into the application, in that case the startup script can copy the configs into /etc/ from a PPI compatible location.  But that is preferable only if /usr/local/etc is not a compile time option.

combo3:
It's a start-stop-restart script, and the author's configure script adds it to BINDIR (not /etc/init.d as I posted earlier). The binary is hardcoded to search for the config files in BINDIR/config, but provides an override switch allowing the user to specify an alternate location at runtime. I chose $HOME based on the assumption most users include that in their backup or set up a persistent home directory on their partition.

No problem. I'll rebuild the extension and resubmit it after the weekend.

Thanks for the clarification.

Navigation

[0] Message Index

[#] Next page

[*] Previous page