There are articles by others describing how to set up “systemd” to automate starting IDS and HQ when a host Linux machine is rebooted, such as:
There are many variations and pitfalls. Other operating systems such as AIX and Windows obviously require different solutions. On many systems, it is preferred not to have IDS automatically start so that checks can be run first. With HDR or RSS replication, you might need to start IDS in a different way after a failure.
There is little point starting HQ without IDS, and it would be better to have a mechanism which is portable across operating systems. Whether starting IDS is automated or manual, it is much more convenient have it also start HQ itself. For example, this is what the Task Scheduler already does as standard (if enabled) for the JSON/Mongo/REST listeners via the “json_listener_start.sh” shell script in $INFORMIXDIR/etc:
Running the following SQL with “dbaccess” as user “informix” will create a stored procedure and insert a startup sensor to execute the procedure, both called “hq_start”:
It can then be seen in the Task Scheduler:
This version of “hq_start” has been updated to do the following:
1) Stop HQ first
Experience has shown that this may be necessary on some versions if HQ was already running with IDS down, as it won’t otherwise reconnect.
2) Start HQ via “at”
Without this, on some systems where IDS is started and stopped via “systemd”, it will see HQ as a sub-process – even though it’s started in background by the calling script – and fail to stop IDS promptly on shutdown or reboot.
Note that there is never any real need to stop HQ before stopping the host, and there is no such thing as a shutdown sensor in the task scheduler anyway.
See the previous article for a listing and details of the “informixhq-control.sh” shell script called by this stored procedure, which starts or stops the HQ server and/or agent(s) depending on the existence of properties files in the $INFORMIXDIR/hq directory. Note that IBM provide a shell script “InformixHQ.sh” for similar purposes with newer versions of IDS, but we prefer ours.