We are currently experiencing intermittent login issues on Community.  The team is actively working on a fix.

Troubleshooting MID Server Startup Failures Caused by Java Security Manager Configuration!!

Selva Arun
Mega Sage
Mega Sage

30m ago - edited 24m ago

 

🔧 Troubleshooting MID Server Startup Failures Caused by Java Security Manager Configuration

📋 Summary: This article addresses MID Server startup failures caused by Java Security Manager configuration conflicts. When Java Security Manager is enabled with restrictive policies, it can prevent the MID Server from starting properly, resulting in java.security.AccessControlException errors.
💡 Why I Created This Article: A community member reached out about MID Server issues during upgrades. While investigating, I reproduced the issue in my home lab to test various scenarios and discovered that Java Security Manager misconfiguration is one potential cause of MID Server startup failures. This article documents my findings to help others who may encounter similar issues.
📑 Table of Contents

Overview

The ServiceNow MID Server may fail to start when Java Security Manager is enabled with restrictive security policies. This occurs because the MID Server requires the ability to manage its own internal security during startup. When external security configurations block this, the MID Server cannot complete initialization.

This is one of several possible causes for MID Server startup failures. If the solution in this article doesn't resolve your issue, please check the "Other Potential Causes" section below.

Symptoms

You may experience one or more of the following symptoms:

Symptom Description
MID Server Won't Start MID Server fails to start after multiple attempts (typically 5 consecutive failures)
Status Remains DOWN MID Server status stays DOWN and doesn't recover
Status Flipping MID Server alternates between UP and DOWN status (may indicate related but different issues)
Upgrade Failure MID Server fails during or after auto-upgrade process

Error Messages to Look For

Check your agent0.log.0 and wrapper.log files (located in <MID_SERVER_HOME>/agent/logs/) for these error patterns:

Primary Error: 
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "setSecurityManager")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
    at java.security.AccessController.checkPermission(AccessController.java:884)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)

Additional indicators in wrapper.log:

There were 5 failed launches in a row, each lasting less than 300 seconds. Giving up.
There may be a configuration problem: please check the logs.
JVM exited while loading the application.

Root Cause Analysis

The root cause is a Java Security Manager configuration conflict. Here's the technical explanation:

What Happens:

  1. Java Security Manager is enabled in the MID Server configuration (via wrapper.conf or wrapper-override.conf) with a restrictive security policy
  2. During startup, the MID Server attempts to set its own internal security manager using System.setSecurityManager()
  3. The active Security Manager denies this operation because java.lang.RuntimePermission "setSecurityManager" is not granted in the policy file
  4. The MID Server cannot complete initialization and the JVM exits
  5. The wrapper service detects the failure and attempts to restart, but the same failure repeats
  6. After 5 consecutive failures, the wrapper gives up

Why might Java Security Manager be enabled?

  • Corporate security hardening scripts modified the MID Server configuration
  • Antivirus or endpoint protection software added Java security policies
  • Manual configuration changes were made to wrapper.conf or wrapper-override.conf
  • Security compliance requirements led to JVM-level security configuration

Lab Simulation: How I Reproduced This Issue

To understand this issue better, I set up a home lab environment and intentionally triggered the failure. Here's what I did:

Lab Environment

Component Details
Operating System Windows Server
MID Server Version Washington DC / Xanadu
Java Version Bundled JRE with MID Server

Steps to Reproduce

1Created a restrictive Java security policy file

I created a file named restrictive.policy in the MID Server's agent/conf directory with permissions that intentionally do NOT include setSecurityManager:

// Restrictive policy - does NOT grant setSecurityManager permission
grant {
    permission java.io.FilePermission "<<ALL FILES>>", "read";
    permission java.util.PropertyPermission "*", "read";
    // NOTE: java.lang.RuntimePermission "setSecurityManager" is NOT granted
};

2Modified wrapper-override.conf to enable Security Manager

I added the following lines to agent/conf/wrapper-override.conf:

# Enable Java Security Manager with restrictive policy
wrapper.java.additional.50=-Djava.security.manager
wrapper.java.additional.51=-Djava.security.policy=../conf/restrictive.policy

3Restarted the MID Server service

sc stop "snc_mid_<MID_SERVER_NAME>"
sc start "snc_mid_<MID_SERVER_NAME>"

4Observed the failure

Result:
  • The MID Server service attempted to start but crashed immediately
  • The wrapper attempted restart 5 times before giving up
  • wrapper.log showed "JVM exited while loading the application"
  • agent0.log.0 showed java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "setSecurityManager")
  • MID Server status remained DOWN

5Applied the fix and verified recovery

After removing the security manager configuration from wrapper-override.conf and restarting, the MID Server came back UP successfully.

Solution

Step-by-Step Resolution

1Stop the MID Server service

Windows:

sc stop "snc_mid_<MID_SERVER_NAME>"

Linux:

cd /opt/servicenow/mid-server/agent
./stop.sh

2Check wrapper-override.conf (PRIMARY LOCATION)

Navigate to: <MID_SERVER_HOME>/agent/conf/wrapper-override.conf

Look for and remove or comment out any lines containing:

# REMOVE OR COMMENT OUT THESE LINES IF PRESENT:
# wrapper.java.additional.X=-Djava.security.manager
# wrapper.java.additional.X=-Djava.security.policy=...

3Check wrapper.conf (SECONDARY - usually not recommended to edit)

Navigate to: <MID_SERVER_HOME>/agent/conf/wrapper.conf

⚠️ Important: Per ServiceNow KB0869393, you should NOT edit wrapper.conf directly as it gets replaced during upgrades. Any custom configurations should be in wrapper-override.conf. However, if security manager settings exist here, note them and consider whether they were added intentionally.

4(Alternative) Grant required permissions in policy file

If Java Security Manager MUST remain enabled for compliance reasons, ensure the policy file grants the required permissions.

Add to your java.policy file:

grant {
    permission java.security.AllPermission;
    // OR more specifically:
    // permission java.lang.RuntimePermission "setSecurityManager";
    // permission java.lang.RuntimePermission "createSecurityManager";
};

5Start the MID Server service

Windows:

sc start "snc_mid_<MID_SERVER_NAME>"

Linux:

cd /opt/servicenow/mid-server/agent
./start.sh

6Verify MID Server status

  1. Navigate to MID Server > Servers in ServiceNow
  2. Verify your MID Server shows status UP
  3. Monitor for a few minutes to ensure it remains stable

Also check logs for successful startup:

# Windows PowerShell
Get-Content "<MID_SERVER_HOME>\agent\logs\agent0.log.0" -Tail 30

# Linux
tail -30 /opt/servicenow/mid-server/agent/logs/agent0.log.0
✅ Expected Result: MID Server status should be UP and remain stable. The logs should show normal startup without AccessControlException errors.

Other Potential Causes of MID Server Startup Failures

If the solution above doesn't resolve your issue, consider these other common causes:

Potential Cause How to Identify Reference
Wrapper.conf file lock during upgrade Check if upgrade failed with file lock errors KB1646567
Antivirus blocking MID Server files Check if Cisco AMP or other AV is blocking wrapper executable KB0827747
Service account permissions Verify service account has proper permissions to restart services KB1116916
JVM memory configuration issues Check wrapper-override.conf for incorrect memory settings KB0635200
SSL/Certificate issues Look for SSL handshake errors in agent log KB0744261
Corrupted installation Missing files in agent/bin folder KB0713557

Prevention Best Practices

Best Practice Description
Avoid enabling Java Security Manager on MID Servers ServiceNow MID Server manages its own security internally. External security policies can conflict with its operation.
Use wrapper-override.conf for customizations Never edit wrapper.conf directly. Use wrapper-override.conf for any custom JVM arguments, as wrapper.conf is replaced during upgrades.
Test upgrades in non-production first Always test MID Server upgrades in a dev/test environment before applying to production.
Coordinate with security teams Ensure corporate security hardening scripts exclude MID Server Java configuration from modifications.
Monitor MID Server health Set up alerts for MID Server status changes and review logs regularly.
Document any custom configurations Keep records of any changes made to MID Server configuration files for troubleshooting.

Was this article helpful?

If the solution provided has adequately addressed your query, could you please mark it as 'Helpful'? This will help other community members who might have the same question find the answer more easily.

Thank you for your consideration! 🙏

👤 About the Author

Selva Arun

ServiceNow Developer | UMass Memorial Health Care

🌟 Rising Star 2024 🌟 Rising Star 2025 🎤 Knowledge Speaker

Co-founder, NowDivas YouTube Channel - Creating educational content on Discovery, CMDB, Certificate Management, and ITOM Automation.

The Now Divas - YouTube | Selva Arun | LinkedIn

Article created: November 2025
Applicable versions: Washington DC, Xanadu, and later

0 Helpfuls
  • 18 Views
Version history
Last update:
24m ago
Updated by:
Mega Sage
Contributors