I want to be sure that the following will not compromise my process:
The Solaris program writes heavily to stdout (via C++ wcout stream). The output serves for tracing, so during testing and analyisis the programmer/tester can easily observe what happens. But the program is actually a server process, so in the production version it will run as a demon without attached console and write all the trace output to files.
I assume that stdout is redirected to nul for a program without console, in this case I guess all is fine. However I want to be sure that the stdout output is not buffered somewhere such that after sufficient run-time we could have memory or disk space problems.
Note: we cannot redirect the trace output to a file because this would grow too large. Instead our own file tracing mechanism makes sure that new files are created and old ones deleted to always keep a certain amount of tracing and not more.
That depends how the daemon is started, I guess. When the daemon process is created, the streams have to be taken care of somehow (for example, they need to be detached from the current process, least the daemon would have to be terminated when the shell from which it was started manually exits).
It depends on how the daemon is started. If it's started as a cron job,
the output will be captured and mailed to whoever owns the crontab
entry, unless you redirect the output in the command line. (But
programs started as cron jobs aren't truly daemons.)
More generally, all processes are started from another program (except
the init processes); most of the time, that program is a shell (even
crontab invokes a shell to start its jobs), and the command is given
as a command line. And you can redirect the output anywhere you please
in a command line; /dev/null is a popular choice for cases like yours.
Most daemons are started from an rc file; a shell script installed
under /etc/rcn.d. Just redirect your output there.
Or better yet, rewrite your code to use some form of rotating logs,
instead of standard out.
Related
I am trying to find out a way to launch a custom daemon from my program. The daemon itself is implemented using double-forking mechanism and works fine if launched directly.
So far I have come across various ways to start a daemon:
Create an init script and install it to init.d directory.
Launch the program using start-stop-daemon command.
Create .desktop file and place in one of the autostart paths.
While the 1st 2 methods are known to start the service using command line, the 3rd method is for autostarting the service (or any other application) at user login.
So far my guess is that the program can be executed directly using exec() family of functions, or the 'start-stop-daemon' command can be executed via system() function.
Is there a better way to start/stop service?
Generally startups are done from shell scripts that would call your C++ program which would then do its double fork. Note that it should also close unneeded file descriptors, use setsid() and possibly setpgid/setpgrp (I can't remember if these apply to Linux too), possibly chdir("/"), etc. There are a number of fairly normal things to do which are described in the Stevens book - for more info see http://software.clapper.org/daemonize/daemonize.html
If the daemon is supposed to run with root or other system user account, then the system /etc/init/ or /etc/init.d/ mechanisms are appropriate places to have scripts to stop|start|status|etc your daemon.
If the deamon is supposed to be for the user, and run under his/her account, you have a couple of options.
1) the .desktop file - I'm not personally a fan, but if it also does something for you on logging out (like let you trigger shutting down your daemon), it might be viable.
2) For console logins, the ~/.bash_login and ~/.bash_logout - you can have these run commands supported by your daemon's wrapper to start it and (later) shut it down. The latter can be done by saving the PID in a file or having the .bash_login keep it in a variable the .bash_logout will use later. This may involve some tweaking to make sure the two scripts get run, once each, by the outermost login shell only (normal .bashrc stuff stays in the .bashrc, and .bash_login would need to read it in for the login shell before starting the daemon, so the PATH and so on would be set up by then).
3) For graphic environments, you'd need to find the wrapper script from which things like your X window manager are run. I'm using lightdm, and at some point /etc/X11/Xsession.d/40x11-common_xsessionrc ends up running my ~/.xsessionrc which gives me a hook to startup anything I want (I have it run my ~/.xinitrc which runs my window manager and everything), as well as the place to shot everything down later. The lack of standardization for giving control to the user makes finding the hook pretty annoying, since just using a different login manager (e.g. lightdm versus gdb) can change where the hook is.
4) A completely different approach is to just have the user's crontab start up the daemon. Run "man 5 crontab" and look for the special #reboot option to have tasks run at boot. I haven't used it myself - there's a chance it's root restricted, but it's easy to test and you need only contemplate having your daemon exist gracefully (and quickly) at system shutdown when the system sends it a SIGTERM signal (see /etc/init.d/sendsigs for details).
Hope something from that helps.
I have to write a program that intercepts data from terminal and i have to parse it. After processing when the data, i have to parse it before it goes to stdout.
I can't use tee or commands like prog > file 2>&1 as the program is going to be interactive.
For example :
If the user types ls in the terminal i have to parse it then it should go operating system and then when I get the result after processing I ll have to again parse it before it's displayed in the terminal.
I did my research and I think I can achieve it through pseudo terminal interfaces ( pty ).
Please let me know if there is a better way to achieve it.
I am using cpp and bash and the platform is *nix.
Update:
I can also use libexpect from expect.
I am not sure what do you mean here - you mean interactive program as "working in another terminal communicating with user" or even displaying GUI?
How does it specify the terminal? It is probably important what is program layout here (which program starts which).
If your application uses GUI to communicate with user, then I would simply do it this way:
start bash with sdtin and stdout attached to pipes,
your program reads & writes to it's end's of those pipes, parses data, and reads/writes on it's own stdin&stdout - so it appears on it's terminal.
If you mean controlling different terminal than your application's, it gets though since system generally does not expect program operating on multiple terminals. I don't think it's possible to filter communication between terminal and already working application attached to it. Starting another process spawning another terminal might be an option - to have basically two terminals working in sync. But then you will have to synchronize both processes by some other means (named pipes, network connection or some other IPC).
If you provide more detail on your program I might provide more directed help.
PS Don't tell me that you are writing some terminal keylogger ')
EDIT:
Your program is probably GUI based then - what i would recommend would be something similar to answer linked by banuj.
Best option will probably be to create three pipes, then fork, and in child process assign corresponding ends of pipes to stdin, stdout and stderr. Then child process should exec into shell - probably bash, although I am not sure if other shells would sound better if read out loud ;) Main process will be able to read/write other ends of mentioned pipes, parsing both inputs and outputs to bash and programs it runs.
You could also exec directly to commands user specifies, but that forces you to take over tedious job of a shell - managing current directory, environment variables, job control and so on.
Using above method might however cause some trouble - some programs (usually in security related contexts - eg. su(do) asking for password) will try to bypass stdin/stdout anyway and read directly from terminal device. I am not sure what can you do in such case - programing your own terminal emulator would be an option, but I don't know if you want to go this deep into system programming for this.
If you want some code snippet's, if you don't know how to do above, just ask ;)
I need to run a linux command such as "df" from my linux daemon to know free space,used space, total size of the parition and other info. I have options like calling system,exec,popen etc..
But as this each command spawn a new process , is this not possible to run the commands in the same process from which it is invoked?
And at the same time as I need to run this command from a linux daemon, as my daemon should not hold any terminal. Will it effect my daemon behavior?
Or is their any C or C++ standard API for getting the mounted paritions information
There is no standard API, as this is an OS-specific concept.
However,
You can parse /proc/mounts (or /etc/mtab) with (non-portable) getmntent/getmntent_r helper functions.
Using information about mounted filesystems, you can get its statistics with statfs.
You may find it useful to explore the i3status program source code: http://code.stapelberg.de/git/i3status/tree/src/print_disk_info.c
To answer your other questions:
But as this each command spawn a new process , is this not possible to run the commands in the same process from which it is invoked?
No; entire 'commands' are self-contained programs that must run in their own process.
Depending upon how often you wish to execute your programs, fork();exec() is not so bad. There's no hard limits beyond which it would be better to gather data yourself vs executing a helper program. Once a minute, you're probably fine executing the commands. Once a second, you're probably better off gathering the data yourself. I'm not sure where the dividing line is.
And at the same time as I need to run this command from a linux daemon, as my daemon should not hold any terminal. Will it effect my daemon behavior?
If the command calls setsid(2), then open(2) on a terminal without including O_NOCTTY, that terminal might become the controlling terminal for that process. But that wouldn't influence your program, because your program already disowned the terminal when becoming a daemon, and as the child process is a session leader, it cannot change your process's controlling terminal.
I developed a software (in C++) which needs to be continuously running. That basically means that it has to be restarted each time it stops.
I was thinking about using cron jobs to check every minutes if it is still alive, but there might be a cleaner way or standard way of doing this.
Thanks in advance
Fedora and Ubuntu use upstart, which has a the ability to automatically restart your deamon if it exits.
I believe the easiest way to do this is to have a script that will start your program and if it gets returned to it just restarts it.
#!/bin/sh
while true; do
./Your_program
done
Monit can do what you want and much more.
cron is an option if your app will be smart enough to check for itself running (this is to avoid many copies of it running). This is usually done in a standard way via PID files.
There are two proper ways to do it on *nix:
Use the OS infrastructure (like smf/svc on solaris, upstart on Ubuntu, etc...). This is the proper way as you can stop/restart/enable/disable/reconfigure at any time.
Use "respawn" in /etc/inittab (enabled at boot time).
launchtool is a program I used for this purpose, it will monitor your process and restart it as needed, it can also wait a few seconds before reinvocation. This can be useful in case there are sockets that need to be released before the app can start again. It was very useful for my purposes.
Create the program you wish to have running continually as a child of a "watcher" process that re-starts it when it terminates. You can use wait/waitpid (or SIGCHILD) to tell when the child terminates. I would expect someone's written code to do this (it's pretty much what init(8) does)
However, the program presumably does something. You might want not only to check the application is running, but that it is not hung or something and is providing the service that it is intended to. This might mean running some sort of probe or synthetic transaction to check it's operating correctly.
EDIT: You may be able to get init to do this for you - give it a type of 'respawn' in inittab. From the man page:
respawn
The process will be restarted whenever it terminates (e.g. getty).
How about a script that check about every 10 minutes to see if the application is running and if it isn't it will restart the computer. If the application is running, then it just continues to check.
Here is my script using PrcView is a freeware process viewer utility. And I used notepad.exe as my example application that needs to be running, I am not sure the command for checking every 10 minutes and where it would go in my script.
#echo off
PATH=%PATH%;%PROGRAMFILES%\PV;%PROGRAMFILES%\Notepad
PV.EXE notepad.exe >nul
if ERRORLEVEL 1 goto Process_NotFound
:Process_Found
echo Notepad is running
goto END
:Process_NotFound
echo Notepad is not running
shutdown /r /t 50
goto END
:END
This is not so easy. If you're thinking "I know, I'll write a program to watch for my program, or see if such a program already exists as a standard service!" then what if someone kills that program? Who watches the watcher?
Consider the following situation: -
I am using Linux.
I have doubt that my application has crashed.
I had not enabled core dump.
There is no information in the log.
How can I be sure that, after the system restart my app was started, but now it is not running, because it has crashed.
My app is configured as a service, written in C/C++.
In a way: how can I get all the process/service names that have executed since the system start? Is it even possible?
I know, I can enable logging and start the process again to get the crash.
This feature is included in Linux Kernel. It's called: BSD process accounting.
Standard practice is to have a pid file for your daemon (/var/run/$NAME.pid), in which you can find its process id without having to parse the process tree manually. You can then either check the state of that process, or make your daemon respond to a signal (usually SIGHUP), and report its status. It's a good idea to make sure that this pid still belongs to your process too, and the easiest way is to check /proc/$PID/cmdline.
Addendum:
If you're only using newer fedora or ubuntu, your init system is upstart, which has monitoring and triggering capabilities built in.
As #emg-2 noted, BSD process accounting is available, but I don't think it's the correct approach for this situation.
I would recommend that you write the fact that you started out to some kind of log file, either a private one which get's overwritten on each start up or one via syslogd.
Also, you can log a timestamp heartbeat so that you know exactly when it crashed.
you probably can make a decoy, ie an application or shell script that is just a wrapper around the true application, but adds some logging like "Application started".
Then you change the name of your original app, and give the original name to your decoy.
As JimB mentions, you have the daemon write a PID file. You can tell if it's running or not by sending it a signal 0, via either the kill(2) system call or the kill(1) program. The return status will tell you whether or not the process with that PID exists.
Daemons should always:
1) Write the currently running instance's process to /var/run/$NAME.pid using getpid() (man getpid) or an equivalent command for your language.
2) Write a standard logfile to /var/log/$NAME.log (larger logfiles should be broken up into .0.log for currently running logs along with .X.log.gz for other logs, where X is a number with lower being more recent)
3) /Should/ have an LSB compatible run script accepting at least the start stop status and restart flags. Status could be used to check whether the daemon is running.
I don't know of a standard way of getting all the process names that have executed; there might be a way however to do this with SystemTap.
If you just want to monitor your process, I would recommend using waitid (man 2 wait) after the fork instead of detaching and daemonizing.
If your app has crashed, that's not distinguishable from "your app was never started", unless your app writes in the system log. syslog(3) is your friend.
To find your app you can try a number of ideas:
Look in the /proc filesystem
Run the ps command
Try killall appname -0 and check the return code