[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Spacewalk-devel] [PATCH] Added systemd unit files

On 04/02/2012 11:42 PM, Pablo Hess wrote:
Hello Folks,

     In an effort to port Spacewalk's sysV init script to the
all-new-and-shiny systemd, Marcelo Mello and I have created quite a few
"unit files" (systemd speak for init script).

     Due to service dependencies, we want to propose a new layout to make
it compatible with the systemd approach.

Mandatory and dependent services

     Since Spacewalk is not a daemon, but a collection of daemons, we
created a target-type file (named spacewalk.target) which will just call
all child services required by Spacewalk (jabberd, osa-dispatcher,
tomcat, httpd, rhn-search, cobbler and taskomatic). On start, stop,
restart and reload, spacewalk.target will perform the same action on all

The idea of having separate target is interesting, But I'm not sure if it is wise. We already have script spacewalk-service and since it just wrapper around "service" command, it works on RHELs and Fedoras. No matter if system-V or systemd is used.

     We also had to include dependency info in a few of those services,
so we named them spacewalk-SERVICENAME, as in spacewalk-httpd,
spacewalk-cobblerd and spacewalk-tomcat6. The original httpd, cobblerd
and tomcat6 service files remain untouched. However, starting the
original httpd service file will immediately stop spacewalk-httpd, and
so on for cobblerd and tomcat6.

Why should I have two services for one binary command (e.g httpd or tomcat).
I would not touch or care about tomcat* httpd, cobbled and jabberd. They provide their own systemd unit files.

Independent services

     DB_service (postgresql) and Monitoring and MonitoringScout - since
these services are not mandatory for running Spacewalk, they will
require a second step from the sysadmin which is to enable it manually:

Do not worry about DB. DB is and always have been managed separately.
Monitoring and MonitoringScout are in sys-v started always. Just when they determine that they are not enabled, they will exit.

              # systemctl enable<service>.service

For example:

              # systemctl enable MonitoringScout.service

What is wrong on chkconfig which works with both sys-v and systemd?

Changes for sysadmins

Systemd is different from sysV and Upstart and it requires a few changes
in the way sysadmins enable the Spacewalk service. For instance, if the
DB service is independent from Spacewalk, then a regular "systemctl
enable spacewalk.target" should suffice.

However, if the DB service is PostgreSQL and its only reason to live is
to serve Spacewalk, it should be associated to the Spacewalk service
file like this:
# systemctl enable spacewalk-postgresql.service

Again do not worry about DB.
If you would like to not make regression. Then you have to parse (in fact execute) /etc/rhn/service-list, where admin can set variable SERVICES and override the default which is (in script spacewalk-service):

if [ -x /etc/init.d/oracle ]; then

if [ -x /etc/init.d/tomcat5 ]; then

if [ -x /etc/init.d/tomcat6 -o -x /lib/systemd/system/tomcat6.service ]; then

SERVICES="jabberd $DB_SERVICE $TOMCAT httpd osa-dispatcher Monitoring MonitoringScout rhn-search cobblerd taskomatic"
if [ -f /etc/rhn/service-list ] ; then
   . /etc/rhn/service-list

+++ b/spacewalk/systemd-units/MonitoringScout.service
@@ -0,0 +1,14 @@
+Description=NOCpulse Monitoring Scout

Why is there that Before? rhn-search can be started in paralel with Monitoring.

+++ b/spacewalk/systemd-units/osa-dispatcher.service
@@ -0,0 +1,15 @@
+Description=osa-dispatcher daemon used by Spacewalk

Tomcat needs osa-dispatcher?

+++ b/spacewalk/systemd-units/spacewalk-db.target
@@ -0,0 +1,5 @@
+Description=Spacewalk Database

This can be tricky. And I currently do not know how to say start after db is up. Especially when db is oracle or postgresql.

+++ b/spacewalk/systemd-units/rhn-search.service
@@ -0,0 +1,14 @@
+Description=Spacewalk search engine
+After=Monitoring.service MonitoringScout.service

Again, why is there Before?
And why is there this line:
+After=Monitoring.service MonitoringScout.service
at all?

+ExecStart=/etc/init.d/osa-dispatcher start
+ExecStop=/etc/init.d/osa-dispatcher stop

You define ExecStart and ExecStop in this manner for all service. Which does not have sense for me.
Why not use directly?:
ExecStart=/usr/sbin/osa-dispatcher --pid-file /var/run/osa-dispatcher.pid

Miroslav Suchy
Red Hat Satellite Engineering

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]