IBM Build Forge incidents are resolved faster when you gather the right evidence before making changes. This guide is for Build Forge administrators and support engineers who need a repeatable way to collect version details, capture relevant logs, and run first-pass triage on common errors.
Originally published on 2013-05-16; fully revised and updated.
Start with incident context before changing anything
Before troubleshooting, capture baseline context so you can correlate symptoms with logs and recent changes.
- Exact Build Forge version (full build string, not just major version).
- Management Console host OS version and architecture.
- Agent host OS version for the selector/agents involved.
- Database version used by Build Forge.
- When the behavior started, under what conditions, and whether it is reproducible.
Collect version and platform details
The original checklist emphasizes complete version identification. In Build Forge, the full application version can be seen in the console by hovering over the Build Forge icon in the upper-left area.
| Component | How to collect | Why it matters |
|---|---|---|
| Build Forge server | Console UI version indicator (full build string) | Confirms exact release for known defects and support matching |
| Management Console OS | Run OS-specific version command on console host | Validates platform assumptions and compatibility |
| Agent host OS | Run OS-specific version command on each relevant agent host | Helps isolate selector/agent-specific behavior |
| Database server/version | Use your DB platform version method | Required for diagnosing schema, connectivity, or performance issues |
OS version commands from the original checklist
# AIX
oslevel
# HP-UX
uname -r
# Solaris
uname -r
# Red Hat
cat /etc/redhat-release
# SUSE
cat /etc/SuSE-release
# Windows (from cmd.exe)
winverCode language: PHP (php)Collect the three primary Build Forge log sources
Use logs from today or the exact date when the issue first appeared. Time alignment across logs is critical.
- Tomcat (Catalina) logs:
$BF_HOME/server/tomcat/logs/(for example,catalina.YYYY-MM-DD.log) - Build Forge engine log directory:
$BF_HOME/log - Database log used by platform:
$BF_HOME/Platform/db.log
# Inspect Tomcat logs for the incident day
ls -1 $BF_HOME/server/tomcat/logs
tail -n 200 $BF_HOME/server/tomcat/logs/catalina.YYYY-MM-DD.log
# Inspect Build Forge engine logs
ls -1 $BF_HOME/log
# Inspect platform database log
tail -n 200 $BF_HOME/Platform/db.logCode language: PHP (php)Triage workflow for recurring Build Forge errors
A lightweight triage flow keeps investigations consistent across teams and shifts.
flowchart TD
A[User reports failure] --> B[Capture symptom and start time]
B --> C[Collect Build Forge OS and DB versions]
C --> D[Collect Tomcat engine and db logs for same window]
D --> E{Known symptom pattern}
E -- yes --> F[Run first checks and retest]
E -- no --> G[Prepare escalation bundle]
F --> H{Resolved}
H -- yes --> I[Document cause and prevention]
H -- no --> G
Common symptoms from the original post and first checks
The original post lists symptoms but only one external solution reference. Use the table below as a first-check matrix, then confirm with logs and environment specifics.
| Symptom | First checks | Evidence to attach |
|---|---|---|
| API: Access denied | Validate user role/permissions, authentication backend health, and recent security changes | Catalina and engine log excerpts around request time |
| Console gets slow after login | Check server resource pressure and concurrent workload during login period | Timestamps for slow login, corresponding engine and DB log lines |
| API: Access denied while opening Environments | Review environment-level permissions and recent edits to environment metadata | Request path, user role, and related log entries |
| “A valid Engine Unique Identifier must be specified” in Catalina log | Review engine registration/config consistency and startup sequence | Catalina lines before and after the error plus engine startup logs |
| Access denied after repeated environment variable duplication | Inspect recent bulk variable operations and possible metadata integrity issues | Change sequence, affected environment names, db.log snippets |
Quick log searches
grep -i "access denied" $BF_HOME/server/tomcat/logs/catalina.YYYY-MM-DD.log
grep -i "Engine Unique Identifier" $BF_HOME/server/tomcat/logs/catalina.YYYY-MM-DD.log
grep -i "environment" $BF_HOME/Platform/db.log | tail -n 100Code language: PHP (php)Legacy reference from the original article: IBM support note for API access denied.
Build a complete escalation bundle
- Full Build Forge version string
- OS versions for console host and affected agent hosts
- Database version details
- Exact reproduction steps and first observed timestamp
- Relevant excerpts from Catalina, engine, and db logs for the same timeframe
- What was already tried and the observed result
Common pitfalls to avoid
- Collecting logs from the wrong date or timezone window
- Sharing partial versions (for example major version only)
- Changing permissions/config before capturing baseline evidence
- Escalating without reproducible steps and correlated log timestamps
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals
