Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
From man page of crontab.
string meaning
------ -------
#daily Run once a day, "0 0 * * *".
#midnight (same as #daily)
So a job #daily will never be executed if the system is always shutdown at midnight? What is the proper way to specify that I want to run this job once daily but I don't care when exactly it is executed in a day?
The job may run, but probably won't complete. cron is implemented via a daemon, so it's always running. Depending on your system's shutdown order, cron may actually be sent the shutdown signal fairly late in the shutdown process, so jobs scheduled for the moment the shutdown started may still run.
e.g. If the shutdown starts at 00:00:00 exactly, but doesn't get to sending cron a kill signal until 00:00:05 (5 seconds after midnight(, then a short running 2-second job may still have time to complete.
However, if any services that job depends on have already been shutdown or are in the process of shutting down, then it's unlikely to be able to finish. e.g.... the script pings a mysql server for one little piece of data... but mysql shut down at 00:00:01 and your script didn't get to the mysql portion until 00:00:02.
tl;dr: it's a race condition and your job MAY execute, but probably won't.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
On Linux, I try to run a fortran executable (or even recompile and then run) and the job is killed immediately. The process just says "Killed". Now, if I copy the whole directory, the program will run just fine in the "new" directory -- but never in the original. This is happening repeatedly, but not universally, and seems random to me. Even though I have a work-a-round, I am still wondering why this happens at all.
Run your program with strace to find out what it is doing before it gets killed. Just speculating: But could it be allocating a huge amount of memory? If system memory is exhausted the out-of-memory killer usually kills the process that uses memory most aggressively. Check /var/log/syslog to see if the OOM killer was kicking in.
Also see What killed my process and why? and Will Linux start killing my processes without asking me if memory gets short?.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
EDIT: More detailed answers here: https://serverfault.com/questions/454192/my-linux-server-number-of-processes-created-and-context-switches-are-growing
I have a strange behaviour in my server :-/. Is a VPS. When I do cat /proc/stat, I can see how each second about 50-100 processes are created and happens about 800k-1200k context switches! All that info is with the server completely idle, no traffic nor programs running.
Top shows 0 load average and 100% idle CPU.
I've closed all non-needed services (httpd, mysqld, sendmail, nagios, named...) and the problem still happens. I do ps -ALf each second too and I don't see any changes, only a new ps process is created each time and the PID is just the same as before + 1, so new processes are not created, so I thought that process growing in cat /proc/stat must be threads (Yes, seems that processes in /proc/stat counts threads creation too as this states: http://webcache.googleusercontent.com/search?q=cache:8NLgzKEzHQQJ:www.linuxhowtos.org/System/procstat.htm&hl=es&tbo=d&gl=es&strip=1).
I've changed to /proc dir and done cat [PID]\status with all PIDs listed with ls (Including kernel ones) and in any process voluntary_ctxt_switches nor nonvoluntary_ctxt_switches are growing at the same speed as cat /proc/stat does (just a few tens/second).
I've done strace -p PID to all process too so I can see if any process is crating threads or something but the only process that has a bit of movement is ssh and that movement is read/write operations because of the data is sending to my terminal.
After that, I've done vmstat -s and saw that forks is growing at the same speed processes in /proc/stat does. As http://linux.die.net/man/2/fork says, each fork() creates a new PID but my server PID is not growing!
The last thing I can think of is that all process data that proc/stat and vmstat -s show is shared with all the other VPS stored in the same machine, but I don't know if that is correct... If someone can throw some light on this I would be really grateful.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
In my server machines, some process goes to the defunct state every day. It affects my CPU usage. I need to write a shell script to kill the defunct process id and parent id.
For example, when I run the command:
ps -ef|grep defunct.
it found many values. In that I need to kill only "[chrome] defunct" process.
sample entry:-
bitnami 12217 12111 0 Feb09 pts/3 00:00:00 [chrome] <defunct>
I need to kill this type of chrome entries. Can anyone suggest some samples to kill the entries?
Defunct processes do not go away until the parent process collects the corpse or the parent dies. When the parent process dies, the defunct processes are inherited by PID 1 (classically it is PID 1; it is some system process designated with the job), and PID 1 is designed to wait for dead bodies and remove them from the process table. So, strictly, the defunct processes only go away when their parent collects the corpse; when the original parent dies, the new parent collects the corpse so the defunct process goes away at last.
So, either write the parent code so that it waits on its dead children, or kill the parent process.
Note that defunct processes occupy very little resources - basically, a slot in the process table and the resource (timing) information that the parent can ask for.
Having said that, last year I was working on a machine where there were 3 new defunct processes per minute, owned by a a system process other than PID 1, that were not being harvested. Things like ps took a long, long, long time when the number of defunct processes climbed into the hundreds of thousands. (The solution was to install the correct fix pack for the o/s.) They are not completely harmless, but a few are not a major problem.
It's already dead. The parent needs to reap it and then it will go away.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
If I have a dual core CPU, does it mean that it can run a maximum of 2 threads?
Then; if so, how does one run 4 concurrent threads, when they are seemingly limited by their CPU, to two? (Since it can only run maximum of 2 for a dual core PC).
This is a very big question.
Basically you are correct that with a dual-core CPU only two threads can be currently executing. However, more threads than two are actually scheduled to execute. Furthermore, a running thread can be interrupted at (almost) any time by the operating system, effectively halting execution of that thread to allow another thread to be run.
There are a lot of factors that weigh into how threads are interrupted and run. Each thread has a given "time-slice" in which to execute and after that time-slice has elapsed that thread may be stopped to allow other threads to execute (if any are waiting). There are also thread priorities that can be assigned that allow for higher priority tasks to take precedence over lower priority tasks.
Some work that can be offloaded from the main CPU (to the GPU or to a disk controller) can also be run in parallel with other threads.
Suggest that you read up on the basics.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
Is there any command in Linux through which i can know if the process is in hang state.
Is there any command in Linux through which i can know if the process is in hang state.
There is no command, but once I had to do a very dumb hack to accomplish something similar. I wrote a Perl script which periodically (every 30 seconds in my case):
run ps to find list of PIDs of the watched processes (along with exec time, etc)
loop over the PIDs
start gdb attaching to the process using its PID, dumping stack trace from it using thread apply all where, detaching from the process
a process was declared hung if:
its stack trace didn't change and time didn't change after 3 checks
its stack trace didn't change and time was indicating 100% CPU load after 3 checks
hung process was killed to give a chance for a monitoring application to restart the hung instance.
But that was very very very very crude hack, done to reach an about-to-be-missed deadline and it was removed a few days later, after a fix for the buggy application was finally installed.
Otherwise, as all other responders absolutely correctly commented, there is no way to find whether the process hung or not: simply because the hang might occur for way to many reasons, often bound to the application logic.
The only way is for application itself being capable of indicating whether it is alive or not. Simplest way might be for example a periodic log message "I'm alive".
you could check the files
/proc/[pid]/task/[thread ids]/status
What do you mean by ‘hang state’? Typically, a process that is unresponsive and using 100% of a CPU is stuck in an endless loop. But there's no way to determine whether that has happened or whether the process might not eventually reach a loop exit state and carry on.
Desktop hang detectors just work by sending a message to the application's event loop and seeing if there's any response. If there's not for a certain amount of time they decide the app has ‘hung’... but it's entirely possible it was just doing something complicated and will come back to life in a moment once it's done. Anyhow, that's not something you can use for any arbitrary process.
Unfortunately there is no hung state for a process. Now hung can be deadlock. This is block state. The threads in the process are blocked. The other things could be live lock where the process is running but doing the same thing again and again. This process is in running state. So as you can see there is no definite hung state.
As suggested you can use the top command to see if the process is using 100% CPU or lot of memory.