Time to learn systemd init system, and stop using the filesystem as a crutch for discovering services

During my day-gig I run a bunch of CentOS machines which require maintenance and updates. For years now I have used the filesystem as a crutch to understand which ‘System V’ init services are available for me to use. To be fair for a last few years CentOS has migrated to using the ubuntu ‘upstart‘ init system. However this still behaved like the old System V init system as far as usage and filesystem layout goes. Therefore I did not even notice the change.

Consider the following example, I need to start my database. In the old system you would do.

$ chkconfig --list |grep -i postgres
postgresql-9.3 	0:off	1:off	2:on	3:on	4:on	5:on	6:off

So now you know which service command to run.

$ service postgresql-9.3 status

However, consider you did not remember the name of the service at all… what would you do? This is where I used to use the filesystem as a crutch to discover the installed services.

$ cd /etc/init.d/
$ ls -1
... snip ...
network
nmb
ntpd
ntpdate
postfix
postgresql-9.3
rabbitmq-server
... snip ...

So now you can see the filesystem will tell you what services are currently installed and available to you. Fast-Forward to CentOS 7.

CentOS 7 uses systemd. RedHat is the primary inventor of systemd, therefore CentOS uses it as well. The commands ‘service’ and ‘chkconfig’ do still exist, and are still usable. However they are deprecated and will disappear, so you might as well stop using them now.

However, here is where the differences begin. Our beloved /etc/inittab gone. Systemd uses ‘targets’ instead of runlevels. By default there are two main targets ‘multi-user.target‘: which is analogous to runlevel 3 and graphical.target: which is analogous to runlevel 5

To view the current default target, run:

$ systemctl get-default

to set the default

$ systemctl set-default multi-user.target

So now what we need to do is

$ systemctl list-unit-files |grep post
postfix.service                             enabled 
postgresql-9.3.service                      disabled
$ sudo systemctl start postgresql-9.3.service

Is the service started?

$ sudo systemctl status postgresql-9.3.service
postgresql-9.3.service - PostgreSQL 9.3 database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql-9.3.service; disabled)
   Active: active (running) since Tue 2015-09-01 19:02:32 UTC; 1min 13s ago
  Process: 12248 ExecStart=/usr/pgsql-9.3/bin/pg_ctl start -D ${PGDATA} -s -w -t 300 (code=exited, status=0/SUCCESS)
  Process: 12241 ExecStartPre=/usr/pgsql-9.3/bin/postgresql93-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
 Main PID: 12251 (postgres)
   CGroup: /system.slice/postgresql-9.3.service
           ├─12251 /usr/pgsql-9.3/bin/postgres -D /var/lib/pgsql/9.3/data
           ├─12252 postgres: logger process   
           ├─12254 postgres: checkpointer process   
           ├─12255 postgres: writer process   
           ├─12256 postgres: wal writer process   
           ├─12257 postgres: autovacuum launcher process   
           └─12258 postgres: stats collector process   

Sep 01 19:02:31 localhost.localdomain systemd[1]: Starting PostgreSQL 9.3 database server...
Sep 01 19:02:31 localhost.localdomain pg_ctl[12248]: < 2015-09-01 19:02:31.282 UTC >LOG:  redirecting log output...cess
Sep 01 19:02:31 localhost.localdomain pg_ctl[12248]: < 2015-09-01 19:02:31.282 UTC >HINT:  Future log output wil...og".
Sep 01 19:02:32 localhost.localdomain systemd[1]: Started PostgreSQL 9.3 database server.
$ sudo systemctl show postgresql-9.3.service

Lots of fun configuration items come out of that command.

$ sudo systemctl  |grep postgre
UNIT                                            LOAD   ACTIVE SUB       DESCRIPTION
postgresql-9.3.service                          loaded active running    PostgreSQL 9.3 database server

I however am still really a filesystem guy. I gotta know how all of this is glued together. Those are the bits of bread crumbs that I will pick up and find when its time to do some system maintenance.

$ ls -al /etc/systemd/system/multi-user.target.wants
... this dir contains all of the currently enabled symlinks...
... and finally ...
$ ls -al /usr/lib/systemd/system |grep -i post

Whala.. I have learned all I need to know about systemd for now.

Related Reference