Ask your nix questions here instead?

But if it's a directory "tree" then why is the root directory at the top?

A good question.
Whenever I've seen a representation of a hierarchical directory structure drawn (or when I've drawn it myself), the root is always at the top. So ".." is up.
But a tree's root system can "branch" just as much below ground as the branches above ground do. Perhaps the "root" directory ought to be called the "trunk" directory and then you could take your pick whether ".." goes up or down :slight_smile:

Pete

Don't family trees start with the "head" of the family at the top?

The problem is the startup system can differ from a linux distro to another. And this method may be old already... I'm not in sync with Ubuntu...

And the opposite:
http://www.tainguyen.com/2011/06/12/disable-ubuntu-services-autostart/

Many great answers! Thank you all! I decided to follow a daemon program tutorial. It fits the bill better than running a program periodically. The program I am going to run needs to stay "resident" or in the background and periodically snap pictures on two cameras. If the user decides to change these periods, I want them to be able to do this with the least effort or understanding of nix. I am thinking of this way:

Write a daemon program. research how to add this program to autostart at boot up and hope to start after the USB TTL adapter drivers are started so the serial cameras can be accessed.
Daemon program monitors a file called config.txt. It will contain the periods of each camera and a few other parameters. When the file is changed it will grab the update and operate according to the new parameters.
Ask user to log on to raspberry pi and type config (allias for nano config.txt), modify parameters and save with ^O exit with ^X.
Alternatively ask user to log in and type cam01period 10 (alias for a script or c program that updates the period to 10 minutes).
Alternatively ask user to point browser to raspberry pi ip address (port forwarding) and use a web based graphical interface, which does the same thing (modify the config.txt).

Suggestions? Comments?

Write a daemon program.

A daemon is basically an ordinary program, running in the background. eg. for a given program foo:

Run in the foreground (ie. your terminal window):

./foo

Run in the background:

./foo &

Normally you redirect output (if any) to a file in this case.

http://wiki.debian.org/BootProcess

Your software package should include an init script that would be placed in /etc/init.d (look at other examples in that directory) and also create symlinks from /etc/rc*.d directories. There are plenty of pre-existing examples that you can poke around at to help understand everything. For example try "ls -l /etc/rc*.d/anacron" to see how the Anacron daemon is configured within the various /etc/rcX.d directories.

That would die the moment the user logged out. You need to use setsid() to divorce yourself from the shell process.

Here's a good tutorial on creating a daemon: Unix Daemon Server Programming

Great! Thanks. I tried that myself. The background process did die when I log out so no go. So you are saying that sid is session id, I see.

If I put ./foo & in the init.d does it run when someone logs on or when system boot? I'm reading your suggested reference so hope to get an answer there as well.

Chagrin:
That would die the moment the user logged out. You need to use setsid() to divorce yourself from the shell process.

I was simplifying a bit. I had been using nohup, but it sounds like setsid could be an alternative.

If I put ./foo & in the init.d does it run when someone logs on or when system boot?

The init.d stuff is for system booting. There is a script that runs on startup, that runs all the scripts in the init.d directory. Again that is simplifying a bit.

Sorry -- I'm just trying to be terse, not rude. I'm not sure how far we can overwhelm Liudr before he smashes the Pi with a hammer ;). Judging from earlier posts I get the feeling that Liudr would rather have everything performed in the executable rather than using nohup or other scripty methods (cron, xinetd, etc.).

A little Perl can go a long way....

Chagrin:
Sorry -- I'm just trying to be terse, not rude. I'm not sure how far we can overwhelm Liudr before he smashes the Pi with a hammer ;). Judging from earlier posts I get the feeling that Liudr would rather have everything performed in the executable rather than using nohup or other scripty methods (cron, xinetd, etc.).

Keeping my cool here (at least until I get a good box for the pi to smash against the wall with minimal damage). At the start of the day I knew nothing about background processes end at logout, daemons /etc/init.d/ etc. and now I have my basic understanding. I have several books but they are thick and don't talk to me. I am very appreciative with what you all provided here. I have just installed a simple script with update-rc.d that just runs the daemon I wrote (it deletes delete.txt in my home director every 5 seconds). I'm in a good position to read more books and online references. I think cron is possibly next. Also need to know how to tweak make files created by eclipse IDE. It's too massive to run on raspberry pi but did create a makefile. After some more reading I might be able to compile my projects with this makefile in console to save time. Then maybe look for solutions to cross compiling so I can develop the project on a Debian laptop, and occasionally cross compile for raspberry pi to test it out. Many things to learn.

liudr:
I have several books but they are thick and don't talk to me.


It even doubles as a personal defense weapon if anyone sneaks up on me while i'm working.

You might have better luck starting out with a version of Ubuntu. Its a lot easier to find new user help threads for Ubuntu, and most of the settings will transfer over to Debian.

Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

GoForSmoke:
Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

Or even better, create a new user that only has permission to do what you need it to do. Like the Apache user is for the Apache webserver.

wizdum:

GoForSmoke:
Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

Or even better, create a new user that only has permission to do what you need it to do. Like the Apache user is for the Apache webserver.

Sounds like the best and safest way to do things if I knew how to deal with user account already :wink: I am behind on my linux cookbook, which is a book on how to use linux. This motivates me. So is there a programmatic way to create such a user name? I wanted to spend the least time to set up and tweak each unit after my program is ready. If I can run a script or c program to create this account, it will be even more attractive option.

If I just installed the script that calls my daemon with sudo update-rc.d, the daemon will run as root, at system boot, correct? There's no need for anyone to log on for daemons to start, right?

I feel like different linux flavors are equally difficult to me since there is a command for everything and most of which I don't know. Programming on linux is probably not related to ease of use of GUI. I have a pidora image that I have not touched yet. Since raspberry pi recommends the raspbian distribution, I followed along with installing debian on my older laptop. Installation was not bad neither was GUI under KDE. It's relatively responsive on a 2.4GB core 2 duo and seems to run fine with 3GB ram. My main laptop with 4GB ram always fills up easily when windows vista loads up and I felt like it needs 6GB to do "blink" :wink:

GoForSmoke:
Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

Not sure what account starts the daemon :blush:

I did sudo update-rc.d script_name

root I guess?

liudr:

GoForSmoke:
Just a thought. What if you start the daemon as administrator?
IIRC admin is always "on" but that is only poor memory.

Not sure what account starts the daemon :blush:

I did sudo update-rc.d script_name

root I guess?

Don't quote me on it, but i'm pretty sure sudo just gives your current account certain elevated permissions (that are specified in the sudo configuration). I think you can do something like sudo update-rc.d script_name.sh -u USER.

"sudo" is "su" on steroids. "su" allows you to switch between users (e.g. "su - root" to switch to the root user) while sudo allows a more fine-grained configuration to allow the execution of a limited number of commands with the privileges of another user.

init.d scripts always execute with the privileges of the root user. The "init" process (process #1, the parent process of all, the head honcho, etc.) uses /etc/inittab as its configuration file. In /etc/inittab you'll see that the script /etc/init.d/rc is launched when the runlevel changes, and /etc/init.d/rc executes the appropriate scripts within /etc/rcX.d (where "X" is the runlevel) in the proper order.

After your script launches your executable your executable would switch to an unprivileged user using the setuid() and setgid() functions. You do have the issue that if you switch to an unprivileged user that you won't be able to access the hardware USB port, so you have to order your program so it opens the USB port first and then switches to an unprivileged user. Or adjust the privileges of the USB port (the device file) appropriately. Adjusting those privileges are kinda tricky so I'd suggest just running with the root user for the present time.

The only thing that update-rc.d does is create symlinks (in Windows parlance a "shortcut") from the various /etc/rcX.d directories to the script in /etc/init.d/. It's a handy tool but I'd suggest creating those symlinks manually so it doesn't feel like voodoo. Again, try to make your setup look like all of the other stuff that's already present -- compare to how other init scripts for ssh, cron, etc. are being run.

Thanks for the detailed explanation. I just checked the daemon I installed to my raspbian. I did ps -u root and found it running as root. I have setsid in my code but not setuid or setgid. Is this the reason it is still a root priveleged process?