3

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?

8
  • 1
    What's the problem with system calls?
    – kos
    Aug 22, 2015 at 10:25
  • @kos I don't think OP has any specific problem with syscalls. OP is curious about syscalls and wants to know if it is possible at all.
    – Ron
    Aug 22, 2015 at 10:28
  • 1
    @Ron Indeed, I was just wondering why such thing was of interest for OP. However thinking about this again this might be a job for SO / U&L, since at least from a certain point of view it addresses more programming than else (and in any case Linux in general rather then Ubuntu).
    – kos
    Aug 22, 2015 at 12:33
  • 1
    stackoverflow.com/questions/12920976/… might give you some idea about 'making some sense' of strace output
    – Ron
    Aug 22, 2015 at 12:41
  • 4
    @Ron I flagged this asking to move it to Unix & Linux, I think it would fit there the most
    – kos
    Aug 22, 2015 at 13:05

5 Answers 5

9

/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.

3
  • Yet this program do use system calls, which begs the question... why a program would ever do anything without system calls?
    – Braiam
    Aug 23, 2015 at 3:50
  • nitpick: true and false are programs, not commands.
    – mike3996
    Aug 23, 2015 at 7:19
  • @progo Most shells define them internally.
    – Behrooz
    Aug 23, 2015 at 8:53
6

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).

5
  • There's a difference - the shell (or other calling program) runs exec, not the program itself.
    – muru
    Aug 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)?
    – kos
    Aug 22, 2015 at 10:49
  • Not the program itself.
    – muru
    Aug 22, 2015 at 10:50
  • @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.
    – kos
    Aug 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.
    – Ruslan
    Aug 22, 2015 at 18:07
1

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.

3
  • 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't if / else / whilestatements (per se) be a part of it as well?
    – kos
    Aug 22, 2015 at 13:48
  • Some shell builtins (e.g. cd or ulimit) 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 or sbrk. Aug 23, 2015 at 1:12
1

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.

0

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.

Not the answer you're looking for? Browse other questions tagged .