Scheduled triggers not running after server recovery

Hey there,

We had a bit of a Situation recently, in which our TC server was mistakenly restarted by a root account, rather than the dedicated user account—we quickly sorted that out, and restarted the server with the correct account.

Things seemed mostly okay at first, but I noticed that our VCS connections were bugged. It turned out, the root account had created/touched some files in the .BuildServer folder, which then prevented the user account running TC from accessing them. Fixing that problem was a simple matter of running chown to give those files the correct permissions.

Now we're running into a new issue: I've noticed that our nightly builds are no longer being triggered. I set our logging preset to debug-triggers overnight, and the relevant log seems to be here:

[2025-12-02 06:30:02,692]  DEBUG - ver.TRIGGERS.schedulingTrigger - BuildName: [/main/staging] No pending changes found since mod id: 13181
[2025-12-02 06:30:02,693]   INFO - ver.TRIGGERS.schedulingTrigger - BuildName: [/main/staging] Trigger state changed: lastProcessedBuildId_/main/staging: -1 was: null

I'll note that changeset 13181 is not on the /main/staging branch; and there are many changesets beyond that.

The VCS connection does seem successful, so I'm not sure how to diagnose the issue any further. The line lastProcessedBuildId_/main/staging: -1 was: null seems potentially suspicious to me, but I can't say much more than that.

Is there anything else I can try to get these triggers working again?

0
2 comments

Hi,

The was: null error seems consistent with the files having the wrong ownership.

Fixing that problem was a simple matter of running chown to give those files the correct permissions.

Did you run chown agains the entire Data Directory and made sure that system/, caches/, and config/ are all owned by the TC service account

If the affected triggers are not too many, you can try to open these triggers in the UI and save them without changing anything (or disabling & re-enabling).

Please let us if this helps and your findings as well.

Thanks

 

 

0

Oh yes, I think in the end it was just a question of properly applying `chown` recursively to the whole directory, as you say. Everything's working once again.

0

Please sign in to leave a comment.