Introducing WebLogic to Systemd
Gepubliceerd: Auteur: Mark Otting Categorie: OracleAs 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.
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:
I use the stopNodeManager.sh 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.
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:
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.
In my case, the NodeManager file should have environment variables to work.
Environment=MW_HOME=/opt/wls
Environment=JAVA_HOME=/usr/lib/jvm/java-8-oracle
Hoe laat je systemctl detecteren of een managed server draait die vanuit de Weblogic Console is gestart?
What are you doing about starting components? I tried
ExecStart=... startComponent.sh ohs1
But that's not staying running.
Try with:
[Service]
Type=oneshot
RemainAfterExit=true
Nice and useful post Mark, thanks. Rather different from OL6.x
I have configured weblogic but it failed to start and logs are not writing to standard.out file . Below is the unit file
[Unit]
Description=WebLogic Adminserver service
After=network.target
[Service]
User=weblogic
Type=forking
WorkingDirectory=/opt/oracle/bea/weblogic12c/wls12.2.1.3/user_projects/domains/test
ExecStart=/opt/oracle/bea/weblogic12c/wls12.2.1.3/user_projects/domains/test/bin/start_Adminserver.sh
[Install]
WantedBy=multi-user.target
How do you start "Managed Servers" with systemd? If I use the shell script startManagedWebLogic.sh, the Nodemanager doesn't know which Managed Servers are started. If I use WLST the process exits and systemd doesn't know which Managed Servers are started.
As of version 236 of systemd log can be written to a file:
StandardOutput=file:/var/log/my.log
StandardError=file:/var/log/my.log
Older version of systemd has to redirect output:
ExecStart=/bin/bash -c '/oracle/startWeblogic.sh > /var/log/my.log 2>&1'
Great work.
It is not clear to me from this post whether the node manager should start first, the admin server should start first, or whether this really does not matter. Unfortunately it's difficult to find the exact answer to this in Oracle's documentation. Does anyone know?
The nodemanager should start first, in order to pick up the state of the AdminServer in this case. Then, when there is a systemsbreakdown, during start the nodemanager wil recognized the break and tries to start it.