system vs init.d, Discuss...


Recommended Posts

I know about init.d, that it have scripts used for initializing the devices & drivers, but what "system" are you talking about? no specification?

Link to comment
Share on other sites

AFAIK there are talks about replacing init.d with system(.d) but Linus really don't want any of it.

Link to comment
Share on other sites

I haven't bothered to learn much about system.d yet, all I've heard so far is that it provides better management of dependencies and paralellism. It also moves away from the simple and easily readable init scripts.

Criticism seems to be that system.d is growing too complex, trying to control areas that were beyond the scope of init (like auth, network or mounts).

Link to comment
Share on other sites

Systemd is system and service manager like init but it also replaces the different distributions' home brew initscripts which reduces fragmentation between distributions.

It also includes different utilities for doing different things (such as a network/dhcp client and ntp client) all of which are separate binaries and their service files can be disabled (similarly to how you used to do in sysvinit).

 

It doesn't include pidof which has moved to procps-ng. It has backwards compatibility with sysvinit in that you can create a /usr/bin/reboot , poweroff, etc.. symlinks.

And also /usr/bin/init -> ../lib/systemd/systemd to avoid adding a init=/usr/lib/system/systemd boot parameter.

 

The main process (PID1) in systemd doesn't have many dependencies:

readelf -d /usr/lib/systemd/systemd | grep Shared
 0x0000000000000001 (NEEDED)             Shared library: [libpam.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libcap.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libkmod.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libseccomp.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

But the different tools that the package includes do have different depdencies. You don't absolutely have to use them and they shouldn't bother you unless you are out of disk space.

The unit files are different than the sysvinit scripts.

for example, this is the service that dials my pppoe connection.

cat /usr/lib/systemd/system/adsl.service
[Unit]
Description=ADSL Daemon

[Service]
Type=forking
ExecStart=/usr/bin/pppoe-start
ExecStop=/usr/bin/pppoe-stop

[Install]
WantedBy=multi-user.target

Instead of runlevels, it had something called targets.

 

Systemd also includes support for scheduled processing of units (services) known as timer units. It can run scheduled tasks (no need for an additional binary here as this is all managed by PID1).

 

Systemd also tracks processes using Linux cgroups. Systemd is pure Linux-ism in other words. It makes use of functionality available in modern Linux kernels.

 

It also uses symlinks to mark services as enabled or disabled like sysvinit did.

 

  • systemctl enable httpd (makes it start at boot).
  • systemctl disable httpd (removes the symlink that makes it start at boot)
  • systemctl start|restart|stop httpd (start or restart or stop the service)

 

Systemd also now bundles udev (which you had separately installed in the past),

 

Systemd will eventually also support factory resets which means resetting /etc/ and /var/ to a default state without user changes. Some of those plans are a bit sensitive because some distributions don't like that software is trying to dictate how their distribution is designed.

 

However, there are still distributions that are not excited about upstream replacing their own code (systemd replacing initscripts). But this will eventually change as more distributions contribute and push their own models into systemd.

 

But we have seen with Cyanogenmod's distribution of Android that you can follow someone else's design (in this case google's design of android) and still have your own touch (the Cyanogendmod distribution of Android).

 

Systemd also uses a non-plain text system journal (read by the command journalctl) but the journal can also be used alongside syslog (for people who need plain text system logs).

 

One interesting tool systemd contains is coredumpctl. If you compile systemd with elfutils installed, it can store not only coredumps but also record backtraces into the journal when your applications crash.

Link to comment
Share on other sites

Weird question for a job application......

 

I have never used, Heard of but no understanding

 

So I am asking Neowin.........

It's not weird if you're applying for *nix admin job. Quite relevant actually. Been using Systemd for a long time now. Arch was one of the first distros to switch to it.
Link to comment
Share on other sites

  • 4 weeks later...

I'd rather having a group of daemons managing startup processes than bloated init scripts.

I have the same opinion. Systemd keeps track of things and logs all exit codes for you so you can see WHY something closed or refused to start without forcing you to scroll through log files. Systemd also has socket activation which makes it even better. I keep sshd activated through socket activation so when ever I don't use SSH to access the server, sshd remaines unloaded.

 

 

To enable sshd and keep it loaded at all times:

systemctl enable sshd.service

To enable sshd but only start it when something wants to connect to it.

systemctl enable sshd.socket

This what I like about systemd:

root [ ~ ]# systemctl status sshd.socket
* sshd.socket
   Loaded: loaded (/lib/systemd/system/sshd.socket; enabled)
   Active: active (listening) since Tue 2014-10-21 01:15:57 CEST; 5 days ago
   Listen: [::]:22 (Stream)
 Accepted: 4; Connected: 1
root [ ~ ]# timedatectl
      Local time: Sun 2014-10-26 18:25:35 CET
  Universal time: Sun 2014-10-26 17:25:35 UTC
        RTC time: Sun 2014-10-26 17:25:35
       Time zone: Europe/Stockholm (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2014-10-26 02:59:59 CEST
                  Sun 2014-10-26 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2015-03-29 01:59:59 CET
                  Sun 2015-03-29 03:00:00 CEST

There are many control tools that can help you with various things. It has built in SNTP (I've replaced it with ntpd) and DHCP (it will configure your interfaces for you) but that can also be replaced by dhcpcd or dhclient. You can enable and disable the features you want. You can also make services stick to specific interfaces by typing something like this: systemctl enable dhcpcd@eth0.service

Systemd logs the boot from a very early start and keep track of all services and logs them which makes it a walk in the park to find most errors and mistakes.

The scripts are more difficult to grasp and they don't do anything if the service crashes. Systemd will restart the services after a crash if they are requested (socket activation required). syslog and dbus are socket activated, so if they somehow crash, the incoming datagrams will be queued up until the service starts and listens once again. In this way, syslog and dbus can de loaded at the same time at boot since dbus only requires the syslog socket.

There are plenty of informative videos on YouTube that explains what systemd really is and how it works. It's more than just an init program (which sysvinit is) and makes Linux easier to work with.

  • Like 2
Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.