/
Reasons Why You Can't See a TM1 Instance in Pulse

Reasons Why You Can't See a TM1 Instance in Pulse

Reasons Why You Can't See a TM1 Instance in Pulse

If a TM1 instance is not visible in the Pulse web client, this article covers the most common causes and how to resolve them.

Reason 1 - The Active Flag Is Set to False

Each TM1 instance in Pulse has an Active flag that controls whether Pulse monitors it. When set to false, the instance is hidden from most views.

Resolution:

  1. Go to Administration → Instance Settings.

  2. Select the instance and set Active to true.

  3. Click Save.

Reason 2 - The Instance Is Not Discovered Yet

If Pulse was just installed or a new TM1 instance was recently added, it may not have been discovered yet.

Resolution:

  • Restart the Pulse Monitor service on the TM1 server. The Monitor auto-discovers TM1 services from the Windows registry.

  • If using a centralized Pulse server, ensure the Pulse Monitor on the remote TM1 server is running and connected.

Reason 3 - The Pulse Monitor Is Not Running

The Pulse Monitor must be running on the TM1 server for Pulse to discover and monitor instances on that server.

Resolution:

  1. Open Windows Services on the TM1 server.

  2. Locate Pulse Monitor and confirm it is in the Running state.

  3. If stopped, start the service and wait a few seconds for instances to appear.

Reason 4 - The TM1 Service Is Not Running as a Windows Service

Pulse discovers TM1 instances by scanning the Windows registry for TM1 service entries. If a TM1 instance is started manually (not as a Windows service), it will not be discovered automatically.

Resolution:
Register the TM1 instance as a Windows service. Refer to IBM documentation for registering TM1 as a service.

Reason 5 - The autostartservicesonly Setting in monitor.yml

If autostartservicesonly is set to true in monitor.yml, the Pulse Monitor will only discover TM1 services with Startup Type = Automatic in Windows Services. Manually-started or disabled services are excluded.

Resolution:
Either set the TM1 service startup type to Automatic, or set autostartservicesonly = false in monitor.yml and restart the Pulse Monitor.

Reason 6 - The ShowDeletedServices Setting Is False

If an instance was previously deactivated or removed, it may be hidden from the interface.

Resolution:
In Pulse.cfg, set:

[Monitoring]\nShowDeletedServices = true

Restart the Pulse Application Server. Deactivated services will then appear with a visual indicator.

Reason 7 - Instance Security Is Restricting Visibility

If inclusion-based instance security is enabled, the logged-in user may not have access to view the instance.

Resolution:
Check Administration → Groups and ensure the user's group has access to the instance. See Configuring Pulse to Exclude or Include Instance Security for details.

Reason 8 - Extra Whitespace in the systemd Service File (Linux)

This cause applies to Linux deployments. On Linux, the Pulse Monitor discovers TM1 instances by scanning the *.service files in /etc/systemd/system and matching the ExecStart line that calls startup_tm1s.sh.

The regular expression used by the Monitor is strict about whitespace. If a service file contains a stray space in the wrong place (for example an extra space after Type=forking, which can leave a space in front of ExecStart), the line fails to match. When that happens, the Monitor never extracts the component and service name, and the instance is silently dropped from Pulse even though the service exists and is running.

A useful symptom is a mismatch in counts: the number of instances visible in Pulse is lower than the number of .service files on disk or the number of running instances shown in Arc. In monitor.log, the affected instance appears as a refreshServices "Possible reference" line but never gets a matching "Components" or "Service Name" line.

How to diagnose:

  1. Compare counts across sources: services in the Pulse environment configuration, files in /etc/systemd/system, running instances in Arc, and instances visible in Pulse.

  2. Run the same extraction the Monitor uses, then inspect the output for any line where a space appears before ExecStart:

    grep -ri '.*ExecStart.*startup_tm1s\.sh.*' '/etc/systemd/system' --include '*.service'

  3. A correct line reads service.name:ExecStart=... with no space after the colon. A broken line reads service.name: ExecStart=... with a leading space.

Resolution:
Edit or recreate the affected .service file to remove the stray whitespace (commonly found right after Type=forking), then reload systemd with systemctl daemon-reload. The instance will be picked up by Pulse on the next discovery cycle.