I was reading about system calls and I got a doubt whether any command runs without making even a single system call. If not then what is the command with minimum number of system calls? I used strace
for some commands but it is giving some long list. Can someone tell me such a command?
5 Answers
/bin/true
and /bin/false
should be the preinstalled commands with the least system calls.
You could save some system calls by static linking:
Save the following as e.g. minimal.c
int main() {
return 0;
}
and compile it using
gcc --static -o minimal minimal.c
This will get you the program minimal
in your current working folder.
-
Yet this program do use system calls, which begs the question... why a program would ever do anything without system calls?– BraiamAug 23, 2015 at 3:50
-
-
Speaking about what syscalls are actually executed in order to "run" ("run" therefore interpreted in an acceptation wider than the acceptation you're probably referring to) a program, no: for one, the execve()
syscall is always executed just to run the command (in this case I think we're better off talking about executable) itself, and the exit()
syscall is always executed upon main()
's return:
the C compiler places a call to exit() after main() returns
(Source)
To somehow address your question, which is executable-dependent and hence very broad: as a proof-of-concept to state that probably any executable actually useful will make use of at least one syscall, it's worthwhile to state that, for one, an exit()
syscall is very likely to be executed from the program itself in case of errors; not to mention that any executable opening / closing a file descriptor will make use of the open()
/ close()
syscalls.
In the end in any command actually useful there will very likely be at least one syscall (e.g. such as exit()
if the program experiences an error during the execution and / or open()
/ close()
if the command has to read a file whatsoever).
-
There's a difference - the shell (or other calling program) runs
exec
, not the program itself.– muruAug 22, 2015 at 10:46 -
@muru " i got a doubt whether any command runs without making even a single system call": I guess that should be included since a program needs
execve()
to run (from a GUI also)?– kosAug 22, 2015 at 10:49 -
-
@muru I agree it didn't fit the question exactly, which on the other hand I think was kinda addressed by the
open()
/close()
part which were meant to act more as proof of concept than else, but I thought it could have been of interest; I've made that clearer in my answer.– kosAug 22, 2015 at 11:38 -
Indeed, in Linux at least, there's no way for a process to cease to exist other than calling
sys_exit
or raising and failing to handle a signal.– RuslanAug 22, 2015 at 18:07
Yes. There are a few commands that run without making any system calls.
One prerequisite of such commands is that they are built into the shell (bash
, for my system). This eliminates both the setup overhead (a number of system calls performed by the linker and libc to set up the environment for the code to run) and the eventual exit() call.
strace
will not help you identify these commands, though, since they are not actual programs. There is no file that corresponds with built-in commands, and so if strace
does find the command, it will be an external version, complete with the setup and teardown any process entails.
The bash
command help
lists all available internal commands. Note that many of these make system calls, as well. Some that don't use system calls:
function
for
declare
true
(the built-in version; not/bin/true
)false
(the built-in version; not/bin/false
)shift
set
case
alias
/unalias
set
/unset
In general... if a command is internal to the shell, reads no input, writes no output, and only works with variables in memory, it probably doesn't use a syscall.
-
Interesting. May I ask how did you get such a list? Did you went through
bash
's source code? I highly doubt those would use syscalls as well tough. Also shouldn'tif
/else
/while
statements (per se) be a part of it as well?– kosAug 22, 2015 at 13:48 -
Some shell builtins (e.g.
cd
orulimit
) run a syscall inside the shell Aug 22, 2015 at 17:13 -
If we are being pedantic, some of these might allocate memory and thus could call
mmap
orsbrk
. Aug 23, 2015 at 1:12
System calls are the only way the program can communicate with the outside world, including announcing that it has run to completion.
So a program that does not use any system calls has no observable effect, and cannot terminate or relinquish the CPU, and thus must run forever using full CPU power. Not very useful.
There isn't a lot a program can meaningfully do without making any system calls at all. System calls is the primary method through which a program communicates with anything outside the program itself.
Communicating through memory mapped files or shared memory is possible, but it still requires system calls to set this up in the first place. Afterwards it can be used to communicate without further system calls.
A program can receive information from the outside through signals. But if no signal handler is installed the signal would just kill the program, and installing the signal handler in the first place requires a system call. In principle a program also need to make a system call at the end of processing a received signal, but if the signal was set up to not block signals at receipt, then leaving the signal handler could be done without a system call. This is more of a curiosity than a meaningful technique with real life applications.
A program which doesn't make any system calls will be consuming all the CPU time it can get because sleeping (in most cases) requires a system call. A program can be sleeping because it is waiting for mapped pages to be loaded from disk. But without system calls the only mapped pages to be loaded would be the executable itself, which would soon be cached.
While running the program can make partial results visible to other programs by modifying its own command line or environment variables. Those can be modified without a system call.
Even a normal termination of a program involves a system call. But a program can trigger a signal to terminate without a system call. Signals which could possibly be triggered include SIGILL, SIGBUS, SIGFPE, SIGSEGV.
Given all of this it would be possible to write a program which when started would do some calculations on the values provided on the command line and eventually terminate through a different signal depending on the result of that calculation. This is not the most useful way to indicate the result of a calculation, but it is certainly possible.
strace
output