program_invocation_short_name program_invocation_short_name is a variable (GNU extension) which contains the name used to invoke a program. The short indicates that if you call your program as /bin/myprogram, it is set to ‘myprogram’. There is also a program_invocation_name variable consisting of the entire path. Here is a demo:

Assume that the executable for the above program is created as myprogram, execute the program from a directory which is one level up from where it resides. For example, in my case, myprogram is in $HOME/work and I am executing it from $HOME:

> ./work/myprogram
myprogram
./work/myprogram

You can see the difference between the values of the two variables. Note that any command line arguments passed are not included in any of the variables.

Back to systemctl

Okay, so now we know that when we execute the poweroff command (for example), program_invocation_short_name is set to poweroff and this check matches:

if (strstr(program_invocation_short_name, "poweroff"))
..

and then the actual action of powering down the system takes place. Also note that how the halt_parse_argv function is called with the parameters argc and argv so that when you invoke the poweroff command with a switch such as --help, it is passed appropriately to halt_parse_argv:

Sorry for not being clear enough the first time. busybox implements the basic functionality of ls, mv, grep, sed and other utilities into a single binary. All those programs are just symlinks to busybox, e.g. ls is a symlink to busybox, mv is a symlink to busybox and so on. So when you run ls you’ll get a listing of the current directory and when you run mv you move files.

P.S. In case anyone wonders why would someone use busybox instead of coreutils plus sed plus other packages, the answer is disk space. It’s like the Pareto principle: 80% of the functionality with 20% of the space :-)

Thanks for that. I looked into busybox source code. BusyBox calls itself a multi-call binary (See http://www.redbooks.ibm.com/abstracts/tips0092.html?Open). I also learned that it calls the programs such as ‘ls’ which it implements as applets and it is in libbb/appletlib.c where all the magic happens.

When only the busybox binary is called, it displays all the currently registered applets. Else, it simply checks the argv[1], argv[2] and so on to execute the applets with their arguments. A good starting point to learn more is the function busybox_main().