I'll preface this by stating I'm not a Linux specialist, but I still need to know the basics when designing Commvault solutions.

On a number of freshly installed SuSE Enterprise Linux 12 virtual machines, I experience that the Commvault services will not automatically start after a reboot.

I've had a collegue who is more experienced in Linux look over the configuration with regards to the init system, and he states the configuration looks fine from a glance.

The command "commvault start" works fine and backups and restores works from that point. I'd rather not tinker around with config files unless clearly stated in the documentation. Am I missing something? 

Same results if I do a local install or a push install.

Hi sechm, could you clarify when/how you are experiencing this, during a backup operation or are you just looking at the status of the services thru the OS?

Does the backup operation generate an errorcode or is the process dumping core on the Linux side (CVD process)?

Once the commvault services are started on the Linux VM all backups and restores work as expected. I have not seen any crashes or core dumps.

A fresh install of the commvault agent software works fine, the services start automatically after install.

It's only when the Linux VM reboots, for example after applying OS patches, the commvault services do not start automatically. I'm sure it's an easy fix, just looking for insight on the best way to go about it.

Simpana 10 is not systemd aware. On some systems not all I have seen that services will not start post boot automatically... as such you can use the workaround around below to have this work moving forward...

Simpana 10
Create the file below...

# vi /etc/systemd/system/simpana.service
Below is the contents that the file should contain and be saved with:

-------
[Unit]
Description=CommVault Simpana v10
After=network.target

[Service]
Type=oneshot
ExecStart=/opt/simpana/Base/Galaxy start
ExecStop=/opt/simpana/Base/Galaxy stop
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
-------

Now you have saved the file with the contents above, if you run the command below it will show the systemd service is disabled.

# systemctl list-unit-files | grep simpana
Now run the following command to enable it, so that during each reboot the simpana.service script will be executed by systemd during startup.

# systemctl enable simpana.service

I do hope this helps... feel free to post back and/or mark post as answered :)

I am having the same problem with my SLES 12 SP2 OES 2018 server.  After upgrading to OES 2018, the commvault services no longer load automatically.  Following Michael's suggestion I created the simpana.service file in the /etc/systemd/system/ directory.  When I do a:

# systemctl list-unit-files | grep simpana

it comes back with a state of 'Bad'.  I don't think I fat-fingered the config file, in fact I copied the text from Michael's post.

If I do a "systemctl list-unit-files" and look at all the Unit Files, I see that there is also a commvault.service. This points to the /etc/init.d directory for Galaxy but there is no Galaxy file there.  Otherwise the syntax is the same in both files with the exception that the 'Description' parameter is slightly different.

What does 'Bad' mean for the state?

Thanks,

Dan

I believe that all new installs from v11 SP12 will register the Commvault services in systemd if the OS requires it.