"Shutting down seosd is not allowed because there is another system call intercepting product" error message stopping seosd

Products

• CA Privileged Access Manager - Server Control (PAMSC)

Issue/Introduction

Trying to shut down PAM SC results in error message

Shutting down seosd is not allowed because there is another system call intercepting product

and the product is not stopped. Actually rc returned is 0

This article explains what that message is and how to proceed

Environment

PAM SC 14.10.50 and later

Cause

Error message,

 

"Shutting down seosd is not allowed because there is another system call intercepting product started after CA Privileged Access Manager Server Control.",

 

indicates that there is another system call intercepting product running on the system and it is enabled after PAMSC.

 

This error has nothing to do with processes still intercepted by PAMSC, so command "secons -scl" will have no effect as it  shows processes still intercepted by PAMSC.  Terminating or restarting these processes will not resolve the problem.

 

What the problem is that you have attempted to shut down PAMSC out of order.  

 

There are multiple system call intercepting products, such as PAMSC, TrendMicro or some anti-virus product, enabled on the system that use the traditional interception method.  The traditional interception method is to patch the system call table.  To coexist in this scenario, all enabled products have to be shut down in the reverse order of enabling.  

 

In this case,  seosd it cannot be shut down because there is another product enabled after PAMSC.  

 

Most of this kind of product, including PAMSC, have built-in safeguard to prevent disabling out of order.  This method works for most of other products that  but it is not sufficient for PAMSC.  

 

This is because PAMSC is enabling and disabling system call interception when starting and shutting down seosd respectively, not when loading and unloading the SEOS_syscall module.

 

 The safeguard we used to have was in the SEOS_syscall module and it would prevent SEOS_syscall module from unloading but the problem was that seosd had already shut down.  To properly resolve it, users need to restart PAMSC.  This works usually; however, if another product does not handle this condition, the system might panic.

This error message was introduced in a new feature since 14.1 CP5.  

 

With this feature, seosd will check prior to disable system call interception during shutdown.  If it detects that another product has been enabled after PAMSC, it will abort the shutdown with this error message and all will continue work without issue.  To resolve this, one needs to find out which product has been enabled after PAMSC and shut it down before shutting down PAMSC.

Resolution

Please make sure that the products are shut down in the reverse order they were started, so that any product having been started after PAM SC is stopped before it

Additional Information

See more details in the following Technical Document : Troubleshooting “secons -sk” error message '.. there is another system call intercepting ..'