The init.d/ic-serviced does not start automatically after a Linux Server reboot

Products

VMware Smart Assurance Network Observability

Issue/Introduction

Rebooted the Linux Server and the sm_service commands do not work and the ic-serviced service did not start automatically.
Manually starting the ic-serviced works fine, however the expectation is that the service starts up after the Linux Host Server is rebooted

[root@<hostname>]# /etc/init.d/ic-serviced status
sm_serviced is not responding.
[root@<hostname># /etc/init.d/ic-serviced start
Starting sm_serviced ...
sm_serviced started
[root@<hostname>]# /etc/init.d/ic-serviced status
sm_serviced is responding.

sm_service show command returns the following error signature:

[root@<hostname>]:/opt/InCharge/SAM/smarts/bin]# ./sm_service show
[Date & Time] t@<EPOCH> Primary Thread CI-E-EFLOWID-For flow CI_FlowBufferedHead_U [Client Buffered Head] HEAD|BUFFERED @0x0000000000ed3ac0 . Read buffer, 0 bytes available of 2145 . ?3?0000000000000000 0000000000000000 ^|0000000000000000 0000000000000000 . Write buffer, 0 bytes written of 2048 . ?3?[^0000000000000000 0000000000000000 0000000000000000 0000000000000000 . -CI_FlowPipe_U IN_FLOW|PHYSICAL|LOCAL @0x0000000000ed3900 . sm_service CI-EWHILE-While executing function "open" SYS-ECONNREFUSED-Connection refused; in file "/work/redcurrent/DMT-10.1.2.0/11/smarts/clsapi/ci_flow.c" at line 3060
OR
[root@<hostname>]:/opt/InCharge/SAM/smarts/bin]# ./sm_service show
[Date & Time] t@<EPOCH> <Primary Thread>
SMS-E-CLI_ENOPIPE-Cannot connect to sm_serviced.  Are you sure it is running?

Environment

All Supported Smarts Releases

Cause

During the Smarts install the ic-serviced is not set to automatically start up after Linux server reboot

Resolution

Contents of /usr/lib/systemd/system/ic-serviced.service:

 
[Unit]
Description=/etc/init.d/ic-serviced
ConditionFileIsExecutable=/etc/init.d/ic-serviced
After=network.target

[Service]
Type=forking
ExecStart=/etc/init.d/ic-serviced start
Restart=always
RemainAfterExit=yes
TimeoutSec=0
GuessMainPID=no

[Install]
WantedBy=multi-user.target

`Type=forking`	Tells systemd that the SysV script forks a background daemon and returns immediately; systemd does not track a single foreground PID.
`RemainAfterExit=yes`	Keeps the unit marked active after the start script exits, since `Type=forking` gives systemd no long-lived process to track. This is why `systemctl status` shows active (exited) — that is expected/normal for this unit, not a failure.
`Restart=always`	Has systemd restart the unit if it is stopped/killed outside of a normal `systemctl stop`.
`WantedBy=multi-user.target`	Declares that this unit should start when the system reaches the standard multi-user boot target — but only takes effect once the unit is enabled (see below).

Step 1 – Check Current Status and Enablement

Confirm the service is loaded and check whether it is currently enabled for boot:

systemctl status ic-serviced

Example output:

 
● ic-serviced.service - /etc/init.d/ic-serviced
   Loaded: loaded (/usr/lib/systemd/system/ic-serviced.service; enabled; vendor preset: disabled)
   Active: active (exited) since Mon 2026-04-13 03:26:01 PDT; 5 months 11 days ago
    Tasks: 0 (limit: 202995)
   Memory: 0B
   CGroup: /system.slice/ic-serviced.service

Also confirm the unit shows up in the full service listing:

 
systemctl list-units --type=service --all | grep serviced

Key things to check in the output:

Loaded: loaded — the unit file was found and parsed correctly.
enabled (shown next to Loaded) — the unit is wired to start at boot. If this instead shows disabled, the service will not start automatically after a reboot, which is the root cause of the reported symptom.
Active: active (exited) — normal/healthy state for this unit given Type=forking + RemainAfterExit=yes (see table above); this does not mean the service is down.

Step 2 – Enable the Service for Automatic Startup

If systemctl status shows the unit as disabled, or if the unit file was recently added/modified (e.g. as part of a patch), reload systemd's unit cache and enable the service:

 
sudo systemctl daemon-reload
sudo systemctl enable ic-serviced.service

daemon-reload — reloads systemd's in-memory configuration so it picks up any changes to the unit file on disk before acting on it.
enable — creates the symlink under /etc/systemd/system/multi-user.target.wants/ pointing back to the unit file, which is what causes the service to be started automatically at boot.

Step 3 – Verify Enablement

 
systemctl is-enabled ic-serviced.service
systemctl status ic-serviced

is-enabled should return enabled. The status output's Loaded: line should also show enabled (as in the sample output in Step 1).

Step 4 – Validate After a VM Reboot

After the next VM restart (e.g. following patch activity), confirm the service came up on its own without manual intervention:

systemctl status ic-serviced

Confirm that Active: shows active (exited) with a since timestamp matching the recent reboot time, and that no manual systemctl start ic-serviced was required.