Background Processing Mode??

[rwhtmv]

Stopped a client backup (6.1.3.1) from the server (5.5.2) using cancel SE. Nothing out of the ordinary. Went to client and stoppped TSM service after confirming the session was gone.

Attempting to restart the TSM Client Acceptor service I get:

Windows could not start the TSM Client Acceptor service on XXXXserver.
Error 400: The thread is already in background processing mode.

I have stopped backups for years, made changes to the opt files and restarted the service, but have never seen this? I expect a reboot of client node will fix, but why should that be needed?

 

[rwhtmv]

Reboot did NOT fix the issue. Still waiting on a call from IBM. Google only turns up MSDN scripts on how to create processes that run in background. Anyone have ANY idea?

 

[rwhtmv]

Since I know you all are just DYING to hear the solution to this...

REBOOT server: unsuccessful
BLUE SCREEN OF DEATH an hour later: after return of server, successful, and service is now started

So the lesson here is to schedule periodic bluescreens for all your servers. hmmm...maybe not.

 

[JamieK]

Hmmm, I'm not liking that fix I am trying to resolve the same issue right now though

 

[tariq.kaifi]

LOL, nice lesson rwhtmv...

By the way, how about recreating the TSM client services altogether? That might end some stuck thread.

 

[Drooza99]

I am also having the same issue but a reboot of a production server is not possible. Did anyone get a solution to this problem? The TSM Client Acceptor service was stopped manually, the opt file modified and now the service will not start. It is a windows 2008 R2 server with version 6.2.1.00 installed. Any help would be appreciated.

 

[fultonator]

this is a really old thread, but i came across this same issue. it happened due to my editing the dsm.opt file. I had mistakenly added a character to one of the options creating an invalid entry. I noticed the acceptor daemon and client scheduler were not updating the dsmsched.log file because of that. Restarting the Client Acceptor produced that same Error 400 message. After finding the invalid dsm.opt entry, and then attempting to restart the TSM Client Acceptor, activity went back to normal and the error message went away.

 

[BackupGuy]

fultonator had it right. Same problem over here. I had just changed my dsm.opt file and was trying to restart the CAD service (which controled the Scheduler service). There were some bad characters that got added to the file. Once removed and resaved, the service started up without issue. I probably hadn't run into this before because I typically try to start the BAC after a change to the dsm.opt file. If there is something wrong with the change, the BAC usually squawks right away and I know. I didn't do it this time....shameful.

 

[Meee]

I was having the same problem, here what I found out:

Since my exchange backup used filebackup for proxy, my problem was related to the dsm.opt for the filebackup, which contained a bunch of invalid “TCPCADAddress” entries.
Removed them, at startet the service right up..

 

[gcollins49]

In my case it turned out to be the option file. I added the parameter shown below while the CAD was running with no issue, but when trying to restart the CAD it failed. Comment out VMSKIPMAXVMDKS=yes, and all is well again. I have added and removed options in the past without experiencing this behavior so it is likely only certain options will result in this occurring. I will need to test more to narrow the field.
VMSKIPMAXVMDKS=yes