I am working with a client-server program. My server program is a daemon process. I need to write scripts that start and stop the daemon. For this, I need to find a way to store the daemon's processid . I've heard bash scripting might be a good solution. I want to store the processID of the daemon in a file called revd.pid under /var/run.
My program looks like this:
#!/bin/bash
pid = $!
echo pid >> /var/run/revd.pid
Use command pidof <application_name>
Here is your daemon process.
Below is an example of the above in a shell script.
Create empty file revd.pid under /var/run and give it proper permissions ...so that you can write into it.
pid=`pidof chrome`
echo "$pid" >> /var/run/revd.pid
Related
I have a batch file in linux (which I will execute externally from within my lazarus application). What it should do is read a process PID, store it in a variable, and use that variable to execute the "kill" command.
This is how I'm doing it:
PID=`pidof myProcess`
kill $PID
However, the kill command fails with a ": arguments must be process or job IDs" error.
How can I achieve this?
Perhaps using pkill directly would better suit your needs.
pkill myProcess
More info on pkill here: https://www.lifewire.com/list-and-kill-processes-using-the-pgrep-and-pkill-4065112
I was trying to get pid of process I ran with setsid and which ought to run in background like this:
test.sh:
#/bin/bash
setsid nohup ./my_program &
echo $!
if I run ./test.sh it will print a pid of my_program process and it's exactly what I need. But if run this commands one by one in my shell like this:
$ setsid nohup ./my_program &
$ echo $!
It will give me a pid of setsid command (or may be something else, but it almost all times gives me pid of my_program minus one).
What is happening here? Why results of commands I ran in terminal by myself differs from results of test.sh script?
Btw, may be you know some easy way of process which I started with setsid and which I need to run in background?
Repost of comments above as an answer:
This is because setsid only forks the current process if it is the process group leader. A detailed explanation can be found here.
To get the pid of a process executed via setsid, the approaches given here may be tried.
setsid will call fork to ensure that it creates a new process group aswell as a new session, hence the resulting pid will not match the pid of setsid. The most clean work-around would be that my_program stores its pid into a file.
When you later want to send kill to my_program, you should check that the pid actually matches a program named my_program via /proc file system or calling the ps command with some magic code around it. (This is a very common method used by many daemons)
I have seen many discussions here on kill command. But my confusion is different. I have many processes with the same name and I have to automate the killing. Hence I can't use the pid. So is it possible that if I go to a specific path and use kill <pname> then only the process related to that path will get killed?
Or is there some way to incorporate the path name in kill command?
Instead of using a pid, you could always use the pkill command and have it check against some regular expression. If you pass it the -f flag, it allows you to check against the entire command line rather than just the process name.
Something like this would probably do the trick:
pkill -TERM -u username -f "mwhome.*weblogic\\.NodeManager"
-f is where you would pass in your regex
-u is also useful so that you only affect pid's running as specific users
No, but you when you start the process with
yourcommand & echo $!
or wrap it in a small script
#!/bin/bash
yourcommand &
echo $! >/path/to/pid.file
you can save the pid. And then kill the process with this pid. This is the normal way how to manage the processes. If you look in the normal init.d scripts of perhaps nginx, they do it the same way. Just saving the pid in a file, and at stopping just read the pid and kill the process.
How do I get the pid of a process as soon as it opens. Like lets say we run ./file.pl and then ./file2.pl As both these files will create a pid in /proc/ folder. How do I instantly know if the process has been created when the executable is run.
I have a file with all the commands ready to be run as soon as it gets the green signal that there is a new process in the /proc/ folder. How do I do that?
EDIT:
Please don't answer with a shell command. I don't need to know the pid. I need to develop a script which can know right away that we have a guest in the proc department
If you start the process via a shell, then start process in background:
./your_prog &
Get the pid:
echo $!
If the script give you the shell prompt back, you can do :
./your_prog
pidof -x your_prog
Tested OK with this perl script :
#!/usr/bin/perl
if (fork() == 0) {
sleep(600);
}
you need to
chmod +x your_prog
before...
Every process can get its own pid with the getpid(2) syscall. At process creation by fork(2) the parent process (e.g. some shell) gets the pid of the new child process. Read e.g. Advanced Linux Programming for more. And the kernel (not the program) is creating some subdirectory /proc/1234/ see proc(5) as soon as it creates the process of pid 1234.
Actually, /proc/ is not a real file system. It is just a pseudo file system giving a view on the state of the kernel and the entire Linux system.
Perl gives you its POSIX module to interface the syscalls. The getpid() syscall is interfaced using the $PID or $$ Perl variable.
The /proc/ pseudo filesystem is filled by the kernel. You could perhaps use inotify to follow change in /proc/ but this is very probably a bad idea.
Your question is not clear, we cannot understand what you really want to do and what you have tried.
Try out below shell script.(You may have to include changes in below script for your expected output)
#!/bin/bash
nr_proc_before=`ls -l /proc | wc -l`
ls /proc > proc_list_before
./any_executable &
nr_proc_after=`ls -l /proc | wc -l`
ls /proc > proc_list_after
nr_new=`expr $nr_proc_after - $nr_proc_before`
echo "$nr_new processes are created newly"
echo "new processes pids are :"
diff proc_list_after proc_list_before > new_pids
sed "1d" new_pids
if [ nr_new > 0 ] ; then
#trigger your file which has commands.
fi
Insted of any_execuatble you can replace with your things so that new processes will be created.
Note : This is not a script which monitors for new process. This sample of script may give you idea to solve your problem.
Please do reply for this answer, i can redefine my answer.
I would like to spawn a process suspended, possibly in the context of another user (e.g. via sudo -u ...), set up some iptables rules for the spawned process, continue running the process, and remove the iptable rules when the process exists.
Is there any standart means (bash, corutils, etc.) that allows me to achieve the above? In particular, how can I spawn a process in a suspended state and get its pid?
Write a wrapper script start-stopped.sh like this:
#!/bin/sh
kill -STOP $$ # suspend myself
# ... until I receive SIGCONT
exec $# # exec argument list
And then call it like:
sudo -u $SOME_USER start-stopped.sh mycommand & # start mycommand in stopped state
MYCOMMAND_PID=$!
setup_iptables $MYCOMMAND_PID # use its PID to setup iptables
sudo -u $SOME_USER kill -CONT $MYCOMMAND_PID # make mycommand continue
wait $MYCOMMAND_PID # wait for its termination
MYCOMMAND_EXIT_STATUS=$?
teardown_iptables # remove iptables rules
report $MYCOMMAND_EXIT_STATUS # report errors, if necessary
All this is overkill, however. You don't need to spawn your process in a suspended state to get the job done. Just make a wrapper script setup_iptables_and_start:
#!/bin/sh
setup_iptables $$ # use my own PID to setup iptables
exec sudo -u $SOME_USER $# # exec'ed command will have same PID
And then call it like
setup_iptables_and_start mycommand || report errors
teardown_iptables
You can write a C wrapper for your program that will do something like this :
fork and print child pid.
In the child, wait for user to press Enter. This puts the child in sleep and you can add the rules with the pid.
Once rules are added, user presses enter. The child runs your original program, either using exec or system.
Will this work?
Edit:
Actually you can do above procedure with a shell script. Try following bash script:
#!/bin/bash
echo "Pid is $$"
echo -n "Press Enter.."
read
exec $#
You can run this as /bin/bash ./run.sh <your command>
One way to do it is to enlist gdb to pause the program at the start of its main function (using the command "break main"). This will guarantee that the process is suspended fast enough (although some initialisation routines can run before main, they probably won't do anything relevant). However, for this you will need debugging information for the program you want to start suspended.
I suggest you try this manually first, see how it works, and then work out how to script what you've done.
Alternatively, it may be possible to constrain the process (if indeed that is what you're trying to do!) without using iptables, using SELinux or a ptrace-based tool like sydbox instead.
I suppose you could write a util yourself that forks, and wherein the child of the fork suspends itself just before doing an exec. Otherwise, consider using an LD_PRELOAD lib to do your 'custom' business.
If you care about making that secure, you should probably look at bigger guns (with chroot, perhaps paravirtualization, user mode linux etc. etc);
Last tip: if you don't mind doing some more coding, the ptrace interface should allow you to do what you describe (since it is used to implement debuggers with)
You probably need the PID of a program you're starting, before that program actually starts running. You could do it like this.
Start a plain script
Force the script to wait
You can probably use suspend which is a bash builitin but in the worst case you can make it stop itself with a signal
Use the PID of the bash process in every way you want
Restart the stopped bash process (SIGCONT) and do an exec - another builtin - starting your real process (it will inherit the PID)