[SOLVED] /bin/systemctl overload

dlb101010 · 12-12-2016, 06:55 PM

This is on a Debian machine:
$ uname -r
debian 3.16.0-4-amd64

The following /sbin commands still work as expected, at least halt, reboot and shutdown do. So I'm curious how systemctl knows which one is being executed as they all link to the same command.

$ ls -l | grep systemctl
lrwxrwxrwx 1 root root 14 Nov 23 13:24 halt -> /bin/systemctl
lrwxrwxrwx 1 root root 14 Nov 23 13:24 poweroff -> /bin/systemctl
lrwxrwxrwx 1 root root 14 Nov 23 13:24 reboot -> /bin/systemctl
lrwxrwxrwx 1 root root 14 Nov 23 13:24 runlevel -> /bin/systemctl
lrwxrwxrwx 1 root root 14 Nov 23 13:24 shutdown -> /bin/systemctl
lrwxrwxrwx 1 root root 14 Nov 23 13:24 telinit -> /bin/systemctl

Thanks!

c0wb0y · 12-12-2016, 07:07 PM

systemctl changes its behavior depending on how it is being called.

jpollard · 12-12-2016, 08:12 PM

With a bit more explanation - systemctl determins its function based on the first parameter (shell value $0) after stripping off the path that may be included. The symbolic links permit the invocation of the execl (see manpage on execl). The first parameter is conventionally the path to the image to execute.

from the manpage on execl:

Quote:

The execv(), execvp(), and execvpe() functions provide an array of
pointers to null-terminated strings that represent the argument list
available to the new program. The first argument, by convention,
should point to the filename associated with the file being executed.
The array of pointers must be terminated by a null pointer.

Jjanel · 12-13-2016, 01:58 AM

Great to see your 'deep' Linux activity! (ref. your 1st IntroForum ThreadPost)

Look into how busybox works: it has either soft or hard links to hundreds like `ls`
$0 is whatever you invoked it as. Try this: create a script called name:

Code:

echo 'echo I will do $0 but I am just plain name' > name 
chmod 755 name; cat name 
ln -s name name1; ln name name2; ls -li name* 
./name1 
./name2

(./ needed if . not in $PATH)
Note name2 is a 'hard' link: same inode# as name! Thus 'physically' same file!

Best wishes! Enjoy always!
p.s. here's a recent 'deep' book you might like; 11.3.4 mentions $0; 2.9 $PATH

hazel · 12-13-2016, 02:12 AM

This logic applies to scripts as well as programs. In a bash script, the calling name is stored in $0. That's how sysv init scripts work. There is a directory for each run level in /etc/rc.d with links to the actual scripts in /etc/rc.d/init.d. Links whose names begin with "S" start services and links beginning with "K" kill them.

The first thing the scripts always do is to check the name under which they were called. Then they run in start or stop mode accordingly.

dlb101010 · 12-13-2016, 08:32 AM

Thanks all for the detailed explanation! The execl behavior explains it. And Jjanel, your script was a nice demonstration...if a picture is worth a thousand words, a working code example is worth two thousand. At least! (Also, thanks for suggesting "How Linux Works" Looks promising.)