Printable View
Hi everybody, this is my first post in this forum!!!
I want to write a service program, a program that runs when system comes up and doesn't teminate by user logoff and is in root level. I read the link below:
But i'm not sure that this is all what should I do?! Or I don't know that it's compatible with different distributions of linux?!
Any help is appreciated before :)
fork() works on linux, and it will create a child process that runs "in the background" of your main process (and in that sense is "daemonized") but it will not cause the main process to background if you run the prog from the command line normally, eg.
./a.out
To cause a program to background itself automatically, use &.
./a.out &
If you use fork like this:
The main process will exit immediately and return you to the command line. 10 seconds later DONE will get insert into the middle of whatever you are doing.Code:#include <stdio.h>
#include <string.h>
int main(int argc, char *argv[]) {
int pid = fork();
if (pid == 0) {
sleep(10);
puts("DONE");
}
return 0;
}
However, this is sort of trivial and not really related to what you want to do, since it is just about how the program will appear to behave when run from the command-line. So forget about fork() for now.
Persistant system daemons are launched at start-up using shell scripts in the /etc/rc.d directory (some distros may put them somewhere else in /etc, like /etc/init.d). This is a set of seven sub-directories corresponding to the *nix runlevels, numbered 0-6. An rc directory looks like this:
These are all symbolic links, the actual files do not have a prefix like "S18" or "K90". The prefix indicates whether this script is to be run to kill or to start a set of services and the number indicates the order in which the scripts are to be run.Code:K02dnsmasq
K15httpd
K50netconsole
K87restorecond
K90network
S08iptables
S18rpcidmapd
S26haldaemon
S95jexec
S99local
So to have a new system daemon run it at start, you need to add something to an existing rc script (look into rc.local, which is linked above with "S99local") or create a new one. In any case, you almost certainly want to use "&" in the script or else it will wait for your daemon to exit, which it won't.
The name of the init script directory is not the only distro-specific issue here. In fact, init systems are one of the major differences between distros, and most systems I know are nothing like the one you describe.Quote:
Persistant system daemons are launched at start-up using shell scripts in the /etc/rc.d directory (some distros may put them somewhere else in /etc, like /etc/init.d). This is a set of seven sub-directories corresponding to the *nix runlevels, numbered 0-6. An rc directory looks like this:
Archlinux uses a single configuration variable per runlevel in its rc.conf file, which references the (non-symlink) files in rc.d.
Gentoo uses init.d and uses its own runscript interpreter, which basically calls shell functions defined in the init scripts. There is another directory that holds the set of scripts for each runlevel, but Gentoo uses named instead of numbered runlevels. Also, that directory is automatically managed (along with the service dependency cache) by the rc-conf program.
Ubuntu (and I assume Debian) has an init.d directory containing the init scripts, and eight rcN.d directories containing symlinks to them as MK27 described.
I know that RedHat works again differently, and SuSE yet again differently, but I don't know exactly how.
In addition, distros often provide helper programs to manage daemons, like Gentoo's start-stop-daemon.
So init scripts are not trivial. Typically, you create a simple script that can start and stop the service, and leave it to the distributors to adapt it to their platform. Or you create a proper init script for your favourite distro.
If redhat is still like fedora it uses the system I described. I've only looked at that and debian, so I'm kind of ignorant. In any case, the significant topic here is the runlevel which all "System V" derived OS's (like linux) use. I think that's right...Quote:
Originally Posted by CornedBee
For sure not. Bash scripting is pretty arcane too. Just trying to point in the right direction.Quote:
So init scripts are not trivial.
Do you need to be root? If the answer is yes, ask yourself this: "Do you need to be root?"Quote:
is in root level
As for init scripts... I don't even have a /etc/rc.d directory. (Gentoo) Mine are in init.d. You can provide init scripts for targetted distros, perhaps (start with the big ones). Otherwise, package maintainers will probably fill the blanks...
Hi and thank you very much everyone. I need to be root, because I really need :)
I knew that there is init.d and some scripts that we control the service with that.
But my main question is this: Have I do something special in my code like the link below?
Thanks for your consideration all
That's why I prattled on about fork() in my previous post. As for the rest of the stuff, well, it looks like a pretty good article to me (altho all I did was skim it) -- you might want to try a more specific question. The discussion of fork() there is because a single system daemon on a multi-user system probably must be able to fork itself, so that it can continue responding to new requests while it is responding to an existing one. Depending on the nature of the daemon, it could also be performing multiple simultaneous processes even when there is only one user.Quote:
Originally Posted by hosseinyounesi
To simply demonize your program, being root or not, just do what other people said, that is "command &". That's all. If the command is launched from the root user, even if your normal user logs out, it'll still run as a deamon. Then it all depends on what you want to do exactly.
"command &" is not enough. It will background your app, but not detach it. You can't exit the shell as long as that process lives, and if you force it to quit, the process will be killed.
You can use nohup to really detach it.
> I need to be root, because I really need
Now that's what I call circular reasoning.
I see a future containing either a trivially compromised box, or rummaging through drawers looking for reinstall disks.
You haven't said yet what it is that your daemon is going to do.
Good point. What you really need to do is create a new user (and maybe group) specifically for the daemon and attribute necessary filesystem resources to it.Quote:
Originally Posted by Salem
Not from my experience. I daemonize at every boot a little program I wrote, then I close the terminal and the daemon simply gets init as his parent.Quote:
Originally Posted by CornedBee
Interesting. When I have a job that gets stopped when backgrounded (like top), bash will simply refuse to close. If I start "cat /dev/zero" in the background, it will get killed. But "cat /dev/zero > /dev/null &" keeps running, probably because it's not attached to the console.
So apparently it's not killing the shell that kills the sub-program, but closing its TTY. If your little program closes stdout or never tries to write to eat, that probably explains why it keeps running.
It's true that if you background something from the command-line bash will complain if you try to exit before the background process finishes.Quote:
Originally Posted by CornedBee
But bash behaves differently when it is executed as an interactive "login" shell (eg for the console) then it does when invoked as a script, which you can background processes in scripts as well, in which case they do not have a controlling tty:
If you have something (like a daemon) you want run at start-up the easiest thing to do is just add this somewhere into /etc/init.d/rc.local or the equivalent:Code:[root/~] ps -A
PID TTY TIME CMD
1 ? 00:00:00 init
2 ? 00:00:00 kthreadd
3 ? 00:00:00 migration/0
4 ? 00:00:00 ksoftirqd/0
mydaemon &
I believe "&" is an actual fork() call.
Yes, I do "command > /dev/null &". Why would you want to have a daemon print its output to the console? Clearly, if you don't redirect the output, it screws things up.Quote:
Originally Posted by CornedBee
Note that the CONSOLE is different from a TTY. CONSOLE should not close, _ever_ (keeping in mind that if you don't have one, it still NEVER closes). In fact, it even stays alive after the kernel has shut down (if doing a shutdown -h now), and can still display messages. Having a daemon print to the console is done quite often.Quote:
Originally Posted by MisterIO
The reason that your jobs stop if you have started background jobs is that you started the jobs as a non-root user. If you start a job in background mode (either by & or by CTRL-Z and then bg) as root, init will adopt the job believing it to be a critical function.
Yeah, I wasn't talking about consoles as in "CTRL+ALT+F1",etc., because those can never be closed and the post I was answering to was talking about closing the terminal.Quote:
Originally Posted by Kennedy
But what do you mean that the console stays alive after the kernel has shut down?
Consoles stay alive even during the system is going to a halt, but when the kernel finally halts, no consoles remain.
ALT-F1 is a tty, as is ALT-F2 - ALT-F7 (F7 is mostly used for X<something>). THE console, however, is how the kernel talks to the world. There is a big difference between the console and a tty.Quote:
Originally Posted by MisterIO
As far as CTRL+ALT+F1, I'm assuming you are referring to "shelling" out of X<something>. That is still not the console and YES these can be closed. It only requires you editing /etc/inittab and commenting out the shells that you don't want to run, then send init a hang-up (killall -HUP init).
I know that I can change their number, but that's different from closing them. It seems as if by "The Console" you mean simply the interface that the kernel uses to do output, but how is that related to the much simpler discussion above about how to deamonize a program?Quote:
Originally Posted by Kennedy
Because you asked the questionQuote:
Originally Posted by MisterIO
And the answer is because you may want to send messages to the console after the controlling tty has died.Quote:
Originally Posted by MisterIO
[EDIT]More info: check out the specs on /dev/console[/EDIT]
Thanks for this.Quote:
Originally Posted by Kennedy
Thanks all!!! My daemon have to monitor other users and maybe logoff one of them,
remove some files, restart the system and something like these.
So I have to be root to do these. Am I wrong?!!! I have written this service for windows
with WIN API. I want just know that is there any API like WIN in LIN to do this?
:cool:
Since this is most easily done with a sequence of system commands, the normal and sane way to do this would be with a shell script, so there is no such API. Many linux daemons are (more and less complicated) bash shell (aka. the "command language interpreter") scripts that use system commands, which system commands are written in C. Indeed, the bash shell is derived from an older unix power tool called "the C shell", and many "system commands" are actually part of the shell -- they do not have their own executables.Quote:
Originally Posted by hosseinyounesi
If you do a bit of research into basic system commands you will realize you do not have to write any new ones for this*, so don't bother using C -- it will just be a string of system(), popen(), etc. I would almost bet that you could learn enough bash to do this in less time than it would take to actually write an awkward and probably inefficient (since you must invoke the shell implicitly to do all that) C program. If you don't use system/exec() calls, this will take you years and ten of thousands of lines of code to re-write commands that already exist.
Advanced Bash-Scripting Guide
You can even ask questions here about that; if no one else will answer them, I will...there are some goofy things about the syntax, like it is whitespace sensitive and heavy on braces. But it has regular expressions, functions, arrays, etc.
You're right, this is a root/sys admin task. So it's about the shell. The bash shell. You don't have to write anything in C, it's already written. I promise you, that is how the pros do it and that is what the shell is for.
*check users logged on: use "who", check the time: use "date", to log a user out: use "kill" to kill all the processes with that user ID (maybe you want to send a message first with "write" or "wall"). To delete files: "rm". To wait, "sleep". To fork, "&". To take the output of a such a SHELL command (who, date) and put into an array for further manipulation analysis, for example, is simple in a SHELL script; to do it in C, a real pain in the
I agree with you, unless he's doing that just for fun. In that case, he could simply take a look at those apps code.Quote:
Originally Posted by MK27
Maybe you are right :)
I'm now reading about bash and linux command line. It seems that Bash is some thing more than it's name !!!!! :cool:
Thank you for all