I am using child_process.exec() to execute the command time <my application>.
If I run this command in the terminal, my application is timed with Linux's time(1) command. However when executing the same command from a Node.js script child_process.exec(time <my application>);, my application is timed with GNU Time instead.
This is problematic because I need the millisecond precision of time(1) which GNU Time does not provide.
How can I call time(1) from child_process.exec()? I have tried giving the full path to time(1) instead of just time, however this did not have any effect.
Answering my own question: I was successfully able to enforce use of time(1) by wrapping my command in the following format: child_process.exec(/bin/bash -c "time <my application>").
Related
I have a PHP script that runs the following code:
exec("ls $image_subdir | parallel -j8 tesseract $image_subdir/{} /Processed/OCR/{.} -l eng pdf",$output, $result_code);
The code runs, however, even after I terminate the PHP script and close the browser, it continues to create the pdf files (thousands). It has been 24 hrs and it is still running. When I run a ps command, it only shows the 8 current processes that were created.
How can I find where all the pending ones are running and kill them? I believe I can simply restart Apache/PHP, but I would like to know where these pending processes are and how they can be down or controlled. It seemed originally that the code waited a minute while it executed the above code, then proceeded to the next line of code in the PHP script. So it appears that it created the jobs somewhere and then proceeded to the next line of code.
Is it perhaps something peculiar to the parallel command? Any information is very much appreciated. Thank you.
The jobs appear to have been produced by a perl process:
perl /usr/bin/parallel -j8 tesseract {...basically the code from the exec() function call in the php script}
perl was invoked either by the gnu parallel command or php's exec function. In any event, htop would not allow killing of process and did not produce any error or status and so it may be a permission problem preventing htop from killing the process. So it was done with sudo on the command line which ultimately killed the process and stopped any further processes creation from the original PHP exec() call.
I'm using CentOS 7.5.1804.
Right after booting-up, the operating system delays.
For example, when I try to write "python" in a terminal,
first I write "pyt" and press .
I have to wait a few seconds for the OS to interpolate to "python".
This phenomenon occurs just after booting-up.
After a few days later, this phenomenon goes away.
Does anyone know a clue to solve this problem?
The bit when you press pyt-"tab" is part of bash-completion package as the command completion happens after you typed the full command. So the cause has to be investigated starting with bash. My educated guess is that some process or I/O is keeping the system busy.
You can start with some generic system information tools as soon as the system start:
uptime to see the system load
vmstat -n 1 to check the status of the CPU
ps aux to check running processes
iotop to check for I/O
systemctl list-jobs to show running jobs in systemd
and based on the result of them perform deeper analysis.
Another thing might be the access to the disk slowing down the systemt at startup. Where is the machine running?
I don't know about fixing — there are all kinds of things that could go cause delays. But I can offer a few tips to investigate.
The first step to investigate is to run set -x to get a trace of the commands that the shell executes to generate the completions. Watch where it pauses.
do you have the issue with different auto-completion? if its only python you can time the execution of your command
time python
you can watch if you have some problems at launch with redirect standar output and error to a file.
strace python 2>&1 launch.log
take a strace at boot and one later then you can check if there is difference between:
diff -u delays.log delays2.log | grep ^+
hope it can help.
This is a reduced example of a makefile which illustrates my problem:
exec:
time (ls > ls.txt; echo $$? > code) 2> time.txt
make exec runs fine under one Linux installation:
Linux-2.6.32-642.4.2.el6.x86_64-x86_64-with-centos-6.8-Final
but it fails under my Ubuntu installation:
Linux-4.4.0-64-generic-x86_64-with-Ubuntu-16.04-xenial
and produces the message:
/bin/sh: 1: Syntax error: word unexpected (expecting ")")
No problems if I run the command time directly from the terminal.
Are there different versions of the command in different Linux installations? I need the version which allows a sequence of commands.
Make always invokes /bin/sh to run the recipe. On some systems, /bin/sh is an alias for bash which has a lot of extra extensions to the standard POSIX shell (sh). On other systems (like Ubuntu), /bin/sh is an alias for dash which is a smaller, simpler, closer to plain POSIX shell.
Bash has a built-in time operation which accepts an entire pipeline and shows the time taken for it (run help time at a bash shell command prompt to see documentation). Other shells like dash don't have a built-in time, so when you run it you get the program /usr/bin/time; run man time to see documentation. As a separate program it of course cannot time an entire pipeline (because a pipeline is a feature of the shell); it can only time one individual command.
You have various options:
You can force your makefile to always use bash as its shell by adding:
SHELL := /bin/bash
to it. I recommend adding a comment there as well describing why bash specifically is needed.
Or you can modify your rule to work in a portable way by making the shell invocation explicit so that time only has one command to invoke:
exec:
time /bin/sh -c 'ls > ls.txt; echo $$? > code' 2>/time.txt
Put a semicolon in front of "time". As is, make is trying to parse your command as a list of dependencies.
The only suggestion that worked is to force bash in my makefile:
SHELL := /bin/bash
I checked: on my Ubuntu machine, /bin/sh is really /bin/dash whereas on the CentOS machine it is /bin/bash!
Thanks!
I have a testcase containing multiple Execute Commands (SSH Library) which are calling different commands in Linux environment. The main thing I would like to do is to run some of them in parallel. By default Robot performs one command and after it finishes, performs the next one.
As for me it is not a good behavior, I would like to have my command executed during execution of previous one. For example:
Execute Command ./script.sh
Execute Command ./script_parallel.sh
What I would like Robot to do:
Execute script.sh
During execution perform script_parallel.sh (which will finish before script.sh finishes)
Finish script.sh
Will it be possible to use GNU Parallel?
Execute Command parallel ::: ./script.sh ./script_parallel.sh
Have you tried Start command? It starts the command in background and returns immediately. To verify successful execution of commands you need Read Command Output.
Let me explain better. What is gonna happen if I run a command in Linux and before it's done and you could enter another command I close the terminal. Would it still do the command or not?
Generally, you must expect that closing your terminal will hangup your command. But fear not! Linux has a solution for that too!
To ensure that your command completes, use the nohup argument first. Simply place it before whatever you are trying to do:
nohup ./some_program
nohup ./do_a_thing -frx -file input_file.txt
nohup grep "something" giant_list_of_files/* > temp_file.txt
The nohup command stands for "no hangup" and it will ensure that the command you execute continues to run, even if you close your terminal.
It depends on the process and your environment (job control shell options, VNC, etc). But typically, no. The process will get a "hangup" signal (message) from the operating system, and upon receiving that, will quit.
The nohup command, for example, arranges for processes to ignore the hangup signal from the OS. There are many ways to achieve the same result.
I would say it will abort att the status you are in just before the session close.
If you want to be sure to complete the job, you will need to use the nohup command.
http://en.wikipedia.org/wiki/Nohup
Read about nohups and daemons (-d)...
A good link is [link]What's the difference between nohup and a daemon?
Worth look at screen command, Screen command offers the ability to detach a long running process (or program, or shell-script) from a session and then attach it back at a later time.