Introducing WebLogic to Systemd

Introducing WebLogic to Systemd

Published on: Category: Oracle

As an administrator, you've now probably run into RedHat or Oracle Linux 7 systems with systemd instead of the old init.d system. You might not have even noticed it and put your old start scripts in /etc/init.d, still maintaining a few hundred lines of boilerplate BASH code. If so, here’s a short introduction into systemd and how to configure WebLogic as a system service.

The old init.d system we ran on Linux 6 (5.. 4..) was basically a lot of shell scripts, tied together over a somewhat common interface. You had to worry about logging, about process id's, permissions and a lot more. Systemd replaced that with a unified system, which leads us into the biggest contrast between the old and the new world: now you configure a service file and Systemd handles everything from there. It reduces the starting of running daemons up to the point of just filling out a few parameters. This is a simplified explanation, Systemd goes way beyond that, but for us this is more than enough.

My goal is to automate starting the WebLogic adminserver and nodemanagers on a single machine. To begin, I'll have to create a configuration for my services, a so-called unit file. Unit files live in /etc/systemd/system.

Setting up unit files

Let's start with the nodemanager:

  1. vi /etc/systemd/system/wls_nodemanager.service
  2. [Unit]
  3. Description=WebLogic nodemanager service
  5. [Service]
  6. Type=simple
  7. # Note that the following three parameters should be changed to the correct paths
  8. # on your own system
  9. WorkingDirectory=/data/domains/base_domain
  10. ExecStart=/data/domains/base_domain/bin/
  11. ExecStop=/data/domains/base_domain/bin/
  12. User=oracle
  13. Group=oinstall
  15. [Install]

I use the script here, but I could have easily dropped that parameter as Systemd first gives a polite 'kill' command, to which the nodemanager would respond with a shutdown. Also note that contrary to Linux best practice I did not name an explicit PID file – the nodemanager service maintains its own.

  1. vi /etc/systemd/system/wls_adminserver.service
  2. [Unit]
  3. Description=WebLogic Adminserver service
  5. [Service]
  6. Type=simple
  7. WorkingDirectory=/data/domains/base_domain
  8. ExecStart=/data/domains/base_domain/
  9. ExecStop=/data/domains/base_domain/bin/
  10. User=oracle
  11. Group=oinstall
  13. [Install]

Monitoring your services

Similar to the nodemanager I have included the optional stopWebLogic script. Now we can test our unit files by attempting to start these new services for the first time:

systemctl start wls_nodemanager
systemctl start wls_adminmanager

Note that by default, systemd will not report anything in response to your command. To check on the status of our newly-created services:

  1. systemctl status wls_nodemanager wls_adminserver
  3. ● wls_adminserver.service - WebLogic Adminserver service
  4. Loaded: loaded (/etc/systemd/system/wls_adminserver.service; enabled; vendor preset: disabled)
  5. Active: active (running) since Fri 2017-01-20 12:48:47 CET; 26min ago
  6. Main PID: 774 (startWebLogic.s)
  7. CGroup: /system.slice/wls_adminserver.service
  8. ├─774 /bin/sh /data/domains/base_domain/
  9. ├─783 /bin/sh /data/domains/base_domain/bin/
  10. ├─900 /data//jdk/bin/java -Dderby.system.home=/data/domains/base_domain/common/db -classpath /data/Oracle...
  11. └─903 /data//jdk/bin/java -server -Xms512m -Xmx1024m -Dweblogic.Name=AdminServer
  13. ● wls_nodemanager.service - WebLogic nodemanager service
  14. Loaded: loaded (/etc/systemd/system/wls_nodemanager.service; enabled; vendor preset: disabled)
  15. Active: active (running) since Fri 2017-01-20 12:48:47 CET; 26min ago
  16. Main PID: 805 (startNodeManage)
  17. CGroup: /system.slice/wls_nodemanager.service
  18. ├─805 /bin/sh /data/domains/base_domain/bin/
  19. ├─812 /bin/sh /data/Oracle/middleware/wlserver/server/bin/
  20. └─911 /data//jdk/bin/java -server -Xms32m -Xmx200m -Dcoherence.home=/data/Oracle/middleware/wlserver/../coherence

Notice the process tree and included PID numbers. Additional commands are for example:

systemctl restart wls_nodemanager wls_adminserver
systemctl stop wls_nodemanager wls_adminserver

(Note once again: systemd by default returns no text after returning successfully from these commands.)

Systemd runs its own logger, by default all output from scripts is logged here. You can use the journalctl command to follow those log:

journalctl -u wls_adminserver -f

The -f parameter allows tailing entries as they are being logged. If both your services are up and running, this would be a good moment to enable them to start at system boot time:

systemctl enable wls_nodemanager wls_adminserver

And finally, if we need to change the unit configuration files, we need to tell Systemd to reload the configuration before additional actions are taken:

systemctl daemon-reload

Log configuration

Before swinging this configuration into your production system, there is one caveat: the adminserver by default logs everything into standard out. Standard out is now captured by the systemd logging. This might not be what you want. A saner configuration would be to redirect the stdout logging to the more easily managed WebLogic logging system, as follows:

  • Open the adminserver server configuration in your WebLogic admin console
  • Open the logging tab, enable "Redirect stdout logging" and 'Redirect stderr logging'
  • Optionally, under advanced, set the severity level of Standard Out to 'Off' to prevent (most) logging to Systemd

The brave should now reboot...

There. The brave should now reboot their system to see if these services work as intended. For further reading on Systemd, there are a lot of resources. I like this comprehensive summary.

Mark Otting
About the author Mark Otting

Mark is an administrator with more then 10 years of experience in Weblogic server, the Oracle Service Bus and Oracle SOA Suite. Coming from a background as a developer and having a broad spectrum of technical interests, he is often found in the role of linking pin and troubleshooter between departments. His specialties include optimising, system administration, both on the technical as on the governing aspects.

More posts by Mark Otting