Solaris

Scenario: I have installed a service. When I start it by running /etc/init.d/<service> start it generates a massive amount of audit data (auditd) in /var/audit. So much so that running the service for any length of time is inadvisable due to overhead.

However if I reboot the system the service runs at startup and does not generate any additional audit data while performing the same functions. This tells me that what the service is and does is not relevant to the audit information generated but rather how it is started. When started interactively by the user it blows up. When started by a system process it runs flawlessly.

My question is simply is there anyway in Solaris to run startup scripts after the system boots? Or have init re-initialize the script in /etc/init.d? I am simply looking for a way to start the service in the same fashion it is started after a reboot without rebooting the box every time I want to stop/start the service. As a note it must be run as root.

Hi,

I would suggest that you should be starting the service using the "svcadm" utility, you should check the documentation here.

Regards

Gull04

*I had to remove the URL from original post to comply with forum rules.

I should've been more clear. It's a legacy service hence using /etc/init.d/ instead of svcadm. I'm looking into converting it from a legacy service to something the SMF can manage. However since this is something I will be needing to repeat Occam's Razor does indeed apply.

Can you tell more about the service, the generated logs, the audit configuration and the account you use to log in ?

If your system is configured to audit everything you launch, it is right for it to audit log a service launched manually.

if you are stuck using /etc/init scripts, perhaps you need to investigate starting the service prior to starting auditd

Or better yet, properly provisioning hardware to handle the audit output from the server apparently doing what it's supposed to do.

I disagree. I've worked on systems where they were specifically configured to prevent usage if audit filled up. This was done to prevent work being done on the server without an audit trail. There is a security benefit to configure a server to shutdown if audit can't write logs.