Saminnet-Search Article Wiki Forum Piwigo SNS Cloud vtiger Sugar

  • Data-Articles
    • Labuanbajo2 (287) Sat09,12:10pm

      Hari pertamaSailingKomodo, kapal kami menuju ke pulau Kanawa. Bukan Kenawa yang di Sumba itu, ya. Karena biasanya sering tertukar. Pulau Kanawa sendiri sebuah pulau kecil yang memiliki dermaga dan sebuah resort. Kalian bisa menginap di resort ini dengan fasilitas antar jemput dari pelabuhan Labuan Bajo-Kanawa. Bisa dilihat paketnya di situs-situs penjualan reservasi hotel. Kami akan mampir untuksn



Systemd components graphic

Image courtesy Wikimedia Commons, CC BY-SA 3.0

Like it or not,ツsystemdツis here to stay, so we might as well know what to do with it.

systemdツis controversial for several reasons: It's a replacement for something that a lot of Linux users don't think needs to be replaced, and the antics of theツsystemdツdevelopers have not won hearts and minds. But rather the opposite, as evidenced in thisツfamous LKML threadツwhere Linus Torvalds bannedツsystemdツdev Kay Sievers from the Linux kernel.

It's tempting to let personalities get in the way. As fun as it is to rant and rail and emit colorful epithets, it's beside the point. For lo so many years Linux was content with SysVInit and BSD init. Then came add-on service managers like theツserviceツandツchkconfigツcommands. Which were supposed to make service management easier, but for me were just more things to learn that didn't make the tasks any easier, but rather more cluttery.

Then came Upstart andツsystemd, with all kinds of convoluted addons to maintain SysVInit compatibility. Which is a nice thing to do, but good luck understanding it. Now Upstart is being retired in favor ofツsystemd, probably in Ubuntu 14.10, and you'll find a ton ofツsystemdツlibs and tools in 14.04. Just for giggles, look at the list of files in theツsystemd-servicesツpackage in Ubuntu 14.04:

$ dpkg -L systemd-services

Check out the man pages to see what all of this stuff does.

It's always scary when developers start monkeying around with key Linux subsystems, because we're pretty much stuck with whatever they foist on us. If we don't like a particular software application, or desktop environment, or command there are multiple alternatives and it is easy to use something else. But essential subsystems have deep hooks in the kernel, all manner of management scripts, and software package dependencies, so replacing one is not a trivial task.

So the moral is things change, computers are inevitably getting more complex, and it all works out in the end. Or not, but absent the ability to shape events to our own liking we have to deal with it.


Red Hat is the inventor and primary booster ofツsystemd, so the best distros for playing with it are Red Hat Enterprise Linux, RHEL clones like CentOS and Scientific Linux, and of course good ole Fedora Linux, which always ships with the latest, greatest, and bleeding-edgiest. My examples are from CentOS 7.

Experienced RH users can still useツserviceツandツchkconfigツin RH 7, but it's long past time to dump them in favor of nativeツsystemdツutilities.ツsystemdツhas outpaced them, andツserviceツandツchkconfigツdo not support nativeツsystemdツservices.

Our belovedツ/etc/inittabツis no more. Instead, we have aツ/etc/systemd/system/ツdirectory chock-full of symlinks to files inツ/usr/lib/systemd/system/.ツ/usr/lib/systemd/system/ツcontains init scripts; to start a service at boot it must be linked toツ/etc/systemd/system/. Theツsystemctlツcommand does this for you when you enable a new service, like this example for ClamAV:

# systemctl enable clamd@scan.service
ln -s '/usr/lib/systemd/system/clamd@scan.service' '/etc/systemd/system/'

How do you know the name of the init script, and where does it come from? On Centos7 they're broken out into separate packages. Many servers (for example Apache) have not caught up tosystemdツand do not haveツsystemdツinit scripts. ClamAV offers bothツsystemdツand SysVInit init scripts, so you can install the one you prefer:

$ yum search clamav

So what's inside these init scripts? We can see for ourselves:

$ less /usr/lib/systemd/system/clamd@scan.service
.include /lib/systemd/system/clamd@.service
Description = Generic clamav scanner daemon
WantedBy =

Now you can see howツsystemctlツknows where to install the symlink, and this init script also includes a dependency on another service,ツclamd@.service.

systemctlツdisplays the status of all installed services that have init scripts:

$ systemctl list-unit-files --type=service
UNIT FILE              STATE
chronyd.service        enabled
clamd@.service         static
clamd@scan.service     disabled

There are three possible states for a service: enabled or disabled, and static. Enabled means it has a symlink in aツ.wantsツdirectory. Disabled means it does not. Static means the service is missing the [Install] section in its init script, so you cannot enable or disable it. Static services are usually dependencies of other services, and are controlled automatically. You can see this in the ClamAV example, asツclamd@.serviceツis a dependency ofツclamd@scan.service, and it runs only whenツclamd@scan.serviceツruns.

None of these states tell you if a service is running. Theツpsツcommand will tell you, or useツsystemctlツto get more detailed information:

$ systemctl status bluetooth.service
bluetooth.service - Bluetooth service
   Loaded: loaded (/usr/lib.systemd/system/bluetooth.service; enabled)
   Active: active (running) since Thu 2014-09-14 6:40:11 PDT
  Main PID: 4964 (bluetoothd)
   CGroup: /system.slice/bluetooth.service
           |_4964 /usr/bin/bluetoothd -n 

systemctlツtells you everything you want to know, if you know how to ask.


These are the commands you're probably going to use the most:

# systemctl start [name.service]
# systemctl stop [name.service]
# systemctl restart [name.service]
# systemctl reload [name.service]
$ systemctl status [name.service]
# systemctl is-active [name.service]
$ systemctl list-units --type service --all

systemdツhas 12 unit types.ツ.serviceツis system services, and when you're running any of the above commands you can leave off theツ.serviceツextension, becauseツsystemdツassumes a service unit if you don't specify something else. The other unit types are:

  • Target: group of units
  • Automount: filesystem auto-mountpoint
  • Device: kernel device names, which you can see in sysfs and udev
  • Mount: filesystem mountpoint
  • Path: file or directory
  • Scope: external processes not started by systemd
  • Slice: a management unit of processes
  • Snapshot: systemd saved state
  • Socket: IPC (inter-process communication) socket
  • Swap: swap file
  • Timer: systemd timer.

It is unlikely that you'll ever need to do anything to these other units, but it's good to know they exist and what they're for. You can look at them:

$ systemctl list-units --type [unit name]

Blame Game

For whatever reason, it seems that the proponents of SysVInit replacements are obsessed with boot times. Myツsystemdツsystems, like CentOS 7, don't boot up all that much faster than the others. It's not something I particularly care about in any case, since most boot speed measurements only measure reaching the login prompt, and not how long it takes for the system to completely start and be usable. Microsoft Windows has long been the champion offender in this regards, reaching a login prompt fairly quickly, and then taking several more minutes to load and run nagware, commercialware, spyware, and pretty much everything except what you want. (I swear if I see one more stupid Oracle Java updater nag screen I am going to turn violent.)

Even so, for anyone who does care about boot times you can run a command to see how long every program and service takes to start up:

$ systemd-analyze blame
  5.728s firewalld.service
  5.111s plymouth-quit-wait.service
  4.046s tuned.service
  3.550s accounts.daemon.service

And several dozens more. Well that's all for toda


0 #1 Guest 2020-07-07 01:43
Wow, that's what I was exploring for, what a information! existing here at this website, thanks
admin of this web site.

Also visit my website - google feud

Articles by Date

TweetTweet Share on LinkedInShare on LinkedIn Share on Google+Google+ Submit to RedditReddit Publish on WordPress WordPress Send emailSend email