SystemD and the use of System Calls ?

[Lost In Cyberia]

Hi everyone,

I have a question about the process management, and deep level system functionality of system calls between SystemD and SystemV?

Does SystemD use the same system calls (fork(), exec(), bind() etc...) as SystemV? or Vice Versa?
If they both use the same or very very similar sys calls, do they handle them the same way? If a sys call is made in systemd, is it generally handled the same way on sysv?

I know SystemD uses unit files for processes now, do these come into effect with system calls?

Or are the differences between SystemV and SystemD more "higher level" than the low kernel level sys calls?

[cooper]

System calls are the means by which all programs communicate with the kernel, regardless of their function.

When your machine boots, your boot loader will kick the kernel into action. The kernel will first initialize itself and, once it's reached a certain state of functionality, it will start /sbin/init which sees to it that the higher-level bits of the system get initialized. This is why init is always active on your system as the process with PID 1. When you kill that process, you basically shut down your computer.

Aside from the init program there isn't a heck of a lot of assumptions the kernel makes about programs being available on your system.

[Lost In Cyberia]

Ehh... but Systemd doesn't use init, as I'm aware of...

[cooper]

SystemD doesn't *use* init, it *is* init.

From the Linux kernel v4.2.0 sourcecode, init/main.c line 968:

      if (!try_to_run_init_process("/sbin/init") ||
        !try_to_run_init_process("/etc/init") ||
        !try_to_run_init_process("/bin/init") ||
        !try_to_run_init_process("/bin/sh"))
        return 0;
 
    panic("No working init found.  Try passing init= option to kernel. "
          "See Linux Documentation/init.txt for guidance.");

[Lost In Cyberia]

Hmm sorry Cooper, still not following really... when I do a :

file /sbin/init

I get :

/sbin/init: symbolic link to /lib/systemd/systemd

So this tells me that the old init process/script is now a new file, called systemd. The systemd file i'm assuming is not the same as the old init script...

Anyway that's not really my question.. my question is more so, does the systemd architecture make use of the same system calls like fork(), exec() etc.. the same as a systemv architecture?

It seems like to me that Systemd's area of 'influence' is above anything regarding system calls.

Also is there an OSI type model, when it comes to the linux OS? You know how we have the OSI model for networking, that describes the different levels of the networking stack? Is there a model like this for the unix/linux OS?

[cooper]

SystemD makes use of the same kernel API (=system calls) as System V init does.

You can cut up the system into various layers based on how you want to see things. Like /sbin vs /usr/sbin where the latter might not be there during boot whereas the former most certainly is (or, well, should be).

Coming back to the symlink, no, systemd isn't the same *thing* obviously. But what happens is that the kernel during its boot process starts a grand total of *1* program. And that program is init as specified in that bit of kernel code I listed. The kernel doesn't care if this is the actual system V init, systemd, or something else - it makes ZERO assumptions on it. In fact, an early trick of getting a shell on your system in case of trouble was to pass the parameter init=/bin/sh to the kernel so that you would get a shell really early on. It makes you personally responsible for initializing the various parts of the system.

To the kernel, init is a program just like any other program you run. The only thing is that a process always has a parent and init tends to be the only regular userspace program that has a parent id of 0 (= the kernel). When a daemon process (say, samba) invokes fork() you get 2 processes, one is the parent which has a PID of X and typically a PPID of <PID of the shell> whereas the child has a PID of Y and a PPID of X. Typically the parent, having accomplished its task of starting the service daemon, will now exit and return you to the shell. The child process with PID Y gets its PPID reassigned to 1 by the kernel, which we know is the PID of init. When you kill the process with PID 1 that triggers the kernel to shut down the system again. So like I said if you pass that init parameter to the kernel so you get a really early shell, when you exit that shell the system shuts down again.