Managing ZENWorks services using systemctl

As we know every major Linux distribution has adopted systemd as their default init system. Init system is the one which manages the services. Prior to using systemd, Linux distributions were using various init systems with System V(SysV) being the most common one.

This article is not about systemd. There are already enough details on the web. This article is about how this systemd change has affected ZENWorks and ZENWorks users.

ZENWorks is supported primarily on enterprise Linux distributions like SUSE Linux Enterprise and ReHat Enterprise Linux. SLE12 and RHEL7 onwards the distributions are using systemd to manage services. As of ZENWorks 11.4, SLE12 is a supported distribution, but RHEL7 is not. So as of now this article is useful for SLE12 only. But whenever RHEL7 will be supported, this article will be useful for it or any future ZENWorks supported Linux distribution using systemd.

When ZENWorks is installed on Linux, many services like novell-zenserver, novell-zenloader, novell-zenworks-xplatzmd etc. are installed. Detail list of ZENWorks services is provided in the table at the end of this article. Now we will see how to manage these services using systemd and how the management is different from SysV.

Start/Stop services

Previously with SysV init scripts we could start/stop services by executing those scripts with arguments start or stop.

For e.g.

$ /etc/init.d/novell-zenserver stop # Stops ZENWorks server
$ /etc/init.d/novell-zenserver start # Starts ZENWorks server

The commands to start/stop services with systemd are different. The command line tool which is used to perform these operations on services is systemctl. So the commands to start/stop services look like these..

$ systemctl stop novell-zenserver.service # Stops ZENWorks server
$ systemctl start novell-zenserver.service # Starts ZENWorks server
$ systemctl status novell-zenserver.service # Shows status of ZENWorks server

Note :

  • As a standard with systemctl, “.service” can be ignored from the service name in the above commands. For e.g. “systemctl stop novell-zenserver” will work too.

  • Service name auto-completion using Tab key works fine.

Running services in debug mode

One good thing about SysV init scripts was that you could write the scripts to accept any custom arguments apart from standard “start” and “stop” arguments. Based on the argument they could do different things. For e.g. many ZENWorks SysV init scripts could accept “debug” argument and start the service daemon in debug mode. But in case of systemctl it accepts fixed predefined set of commands like start/stop/status etc. It does not accept any custom argument which it can pass to the service.

To pass any custom argument to the service, the actual service file needs to be edited. Now the first issue is how to know the path of the actual file for ZENWorks services. Usually some files reside in /opt/novell/zenworks/lib/systemd/system and some files in /usr/lib/systemd/system . Searching in those folders, you can find the ZENWorks service files like novell-zenserver.service, novell-zenloader.service, casa_atsd.service etc. However the easiest way to find the service file path is using the "systemctl status <Service Name>" command. The output of the command prints the service file path along with other information.

For e.g.
$ systemctl status novell-zenserver.service  
novell-zenserver.service - Novell ZENworks Server service
Loaded: loaded (/opt/novell/zenworks/lib/systemd/system/novell-zenserver.service; enabled)
Active: active (running) since Fri 2015-11-13 11:34:29 IST; 1 weeks 5 days ago
Main PID: 1851 (systemd.zenserv)
CGroup: /system.slice/novell-zenserver.service
-1851 /bin/sh /opt/novell/zenworks/lib/systemd/system/systemd.zenserver start
-1907 jsvc.exec -jvm server -nodetach -user zenworks -home

The black colored bold text in the above truncated output shows the absolute file path of novell-zenserver.service

Now that we know how to locate the service files lets come back to our original topic of passing custom arguments to service daemons. In order to do that open the service file in any of the editors like vi. There will be a line starting with “ExecStart=” which tells what is script/command to run to start the service. Usually it will be a path to the startup script with some optional argument (usually “start”). You can edit this line to pass any valid custom argument that the startup script of the service accepts. To know what are the valid arguments that you can pass to the script, you need to check the startup script. There is no standard convention for this. For e.g. ZENServer accepts “debug” where as ZENWorks agent (xplatzmd) accepts “debug”, “--clean” and “--osgiclean”. You can modify the line to pass appropriate argument to start the services in debug mode.

For e.g.

  • For novell-zenserver.service and novell-zenworks-xplatzmd.service you can edit the “ExecStart=” line and replace “start” with “debug” to start them in debug mode

  • For novell-zenloader.service just append “ --debug” to the line “ExecStart=/opt/novell/zenworks/bin/zenloader” to start it in debug mode

After making any changes to any service file you need to run “systemctl daemon-reload” command to tell systemd to reload the service files. After that whenever you use the usual “systemctl start ...” command to start the service, the service will be started with the custom argument that you have put in the service file.

Missing ZENWorks Monitor systemd service

There is a SysV init service /etc/init.d/novell-zenmntr which ensures that other ZENWorks services keep running all the time. There is no such systemd service present. The reason for dropping the service is that systemd itself performs the job that monitor service was performing. The systemd ZENWorks services are configured in such a way that whenever the service process crashes or is killed, systemd will take care of restarting it. However if you gracefully stop any ZENWorks service using “systemctl stop...” , systemd will not automatically start it until you start it using “systemctl start” command or system is rebooted (which anyway starts all the enabled services).

This is a good feature compared to SysV init services, because in SySV init systems, if you want to replace any files related to any process like ZENServer or ZENLoader, you needed to stop the corresponding service and also stop the ZENWorks monitor service so that monitor service does not start the service back even before you could replace the files. With systemd you dont need to bother about stopping an additional service. Just stop the desired service, replace the files and start the service.

List of ZENWorks services



SysV init Script

Systemd service

ZENWorks Server



ZENWorks Loader



ZENWorks Agent



ZENWorks Monitor


Not Available

Sybase service for ZENWorks Database



Sybase service for ZENWorks Audit Database



ZENWorks Join Proxy



ZENWorks Imaging



Proxy DHCP Service for PXE



TFTP Server



Imaging zislnx service



Preboot Policy Engine Daemon



Casa Authtoken Service Daemon



miCASA daemon Service




How To-Best Practice
Comment List