TraceSM is already running – how to stop it

In the new version of Session Manager (6.3 and above), the traceSM process is supposed to timeout and stop on its own. However, I was just trying to run it today and got this error

[cust@la-sessionmanager ~]$ traceSM
ERROR: traceSM is already running. Only one instance is allowed.

Uh oh. I don’t know the root password so I cannot kill it. However, Avaya thought of this for me. Just run traceSM with the -k switch and all is well:

traceSM -k

This kills the old process and runs a new instance for me. Just another thing that sounds simple once you know it.

14 thoughts on “TraceSM is already running – how to stop it

  1. Jaime

    Hi
    Do you know what is the native password for to root from session manager , i cant to change the folder for to run traceSES , su – root , password. and i dont know what is it .
    Or how to get in to that option to traceSES ?

    Reply
    1. roger Post author

      For session manager, you just need to log in as ‘cust’ and then run ‘traceSM’. I don’t have SES, but I assume that trace utility would be on the SES server? On the SBC-E product, you login as ipcs, but then you need to issue the command ‘sudo su -‘ to elevate you to root without knowing the root password. Then you can ‘traceSBC’. Perhaps this works on the SES server as well?

      Reply
  2. Jaime

    Thankyou for the soon response.
    Im from Mexico , im no so good with english and thankyou for the help , you are very kind ,
    Well i tried to use the sudo but the same , mmmm do you think if get up a ticket witch AVAYA , they help me to know what is the password.

    [admin@sadcmty-smgr01 ~]$ sudo su

    We trust you have received the usual lecture from the local System
    Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

    Using major release number R016x on System Platform
    [sudo] password for admin:
    Sorry, user admin is not allowed to execute ‘/bin/su’ as root on sadcmty-smgr01.sigma-alimentos.com.
    [admin@sadcmty-smgr01 ~]$
    [admin@sadcmty-smgr01 ~]$
    [admin@sadcmty-smgr01 ~]$
    [admin@sadcmty-smgr01 ~]$
    [admin@sadcmty-smgr01 ~]$ traceSES
    -bash: traceSES: command not found
    [admin@sadcmty-smgr01 ~]$
    [admin@sadcmty-smgr01 ~]$ cd cd
    -bash: cd: cd: No such file or directory
    [admin@sadcmty-smgr01 ~]$ cd etc
    -bash: cd: etc: No such file or directory
    [admin@sadcmty-smgr01 ~]$
    [admin@sadcmty-smgr01 ~]$
    [admin@sadcmty-smgr01 ~]$

    Reply
  3. Jaime

    I got to log me with root , but the same result, Do you think is gonna missing something on the configuration?
    About my last comment i was write down wrong the command is TraceSM.

    root@sadcmty-smgr01 Avaya]# dir
    ABG IPTCMPatch
    ABGPatch JBoss
    AUS MESSAGING
    AUSPatch MESSAGINGPatch
    autoInstall_Avaya_AURA.properties Mgmt
    autoInstall_Conferencing.properties MMCS
    autoInstall_MMCS.properties Postgres
    autoInstall_PS_SysMgr_Extensions.properties PS_SysMgr_Extensions
    bin REPORTS
    cert-store Session_Manager
    Conferencing SessionManagerPatch
    CS1000 smgr_radius
    CS1000Patch SPIRIT
    HeapDump staging
    installdata SUM
    install_logs SUMPatch
    INVENTORY Uninstaller
    INVENTORYPatch UpdateEP.log
    IPTCM vsp
    [root@sadcmty-smgr01 Avaya]# cd bin
    [root@sadcmty-smgr01 bin]# traceSM
    -bash: traceSM: command not found
    [root@sadcmty-smgr01 bin]#
    [root@sadcmty-smgr01 bin]#
    [root@sadcmty-smgr01 bin]# traceSM
    -bash: traceSM: command not found
    [root@sadcmty-smgr01 bin]#

    Reply
    1. roger Post author

      It looks like you’re logged into your System Manager (Avaya did a terrible job naming the system manager and session managers – SM and SMGR could be either one) but smgr typically means System Manager. Can you log into your Session Managers and try there? If you need help finding those IP addresses, you can look in the “sip entities” in System Manager, or the node-names in Communication Manager. I can provide more detail if you need.

      Reply
  4. Jaime

    Hey Roger How are you , again me =)
    I´ve a question about something , currently on my company we have a trunk sip between Session manager 6.3 with a VCS cisco version 8 , this interporality unfortunatly is not working(fail) , but i would like to know what is the way to go over if the trunk on avaya SM is up and see is possible to get some logs about what is happen once do the calls towars VCS.

    I hope be crystal clear with my question.

    Regards!!!

    Jaime

    Reply
  5. Matt

    Hi Roger,

    traceSM -k didn’t work for me, traceSM -K did. Many thanks for pointing me in the right direction though, my VPN connection died and left a logged in session.

    Regards,

    Matt

    Reply
    1. roger Post author

      Wow Matt – that’s interesting and thanks for finding that. I checked the source code for traceSM and traceSBC and in my versions (6.3) it’s a lowercase k. What version are you running? I’ll update the post.

      Reply
        1. Nagesh

          By default, only one traceSM can be running on a Session Manager at any given time. To invoke multiple instances, it must be run with the -m option. However, Avaya advises against running multiple instance of traceSM in a production environment as it may cause performance problems.

          traceSM -m

          traceSM should be accessible through the default path, but in case you ever need to find it, look under /opt/Avaya/contrib/bin. Remember, Linux is case sensitive. It’s traceSM and never tracesm or Tracesm.

          Reply
          1. roger Post author

            Thanks Nagesh! The -m is handy when you want to compare two logs of traces side-by-side. I supposed you wouldn’t ever need to do live call traces in two instances. I haven’t looked at the source code, but I assume traceSM is simply parsing a log file in real time. I would think that two instances would simply parse the same log file, or do you think it’s duplicating the logging function too?

            Naturally, when one instance “clears” the log, the other instance would lose its log too. Probably avoided more out of confusion than performance. But who wants to volunteer to try it?

            Thanks for the tip. I appreciate your response and let us know how your SM is doing.

            Roger

Leave a Reply

Your email address will not be published. Required fields are marked *