Originally published at aideazz.xyz — cross-posted here with canonical link.
My algom-stream process has restarted 55193 times in 41 days. This isn't a new issue; it's a persistent anomaly that stands in stark contrast to other processes running on the same Oracle Cloud instance. While algom-stream continues to report as "online" via pm2 jlist, its restart count indicates a deep-seated instability that hasn't triggered a full system failure. This behavior is distinct from other processes like algom-poll, which has 0 restarts over 60 days, or n8n, also with 0 restarts over 44 days. The system is operating, but one critical component is in a constant state of self-recovery.
The Scale of Instability
To put the algom-stream restart count into perspective, consider the other processes. dragontrade-dashboard has 1 restart over 41 days. dragontrade-main has 3 restarts over 41 days. Even cto-aipa, which I've previously debugged for restart issues, shows 167 restarts over 3 days – a high number, but still orders of magnitude less than algom-stream's 55193 restarts over 41 days. The algom-stream process is designed to handle real-time data ingestion, and this level of churn suggests it's constantly hitting an edge case or resource contention that forces a restart.
The pm2 jlist output confirms algom-stream is "online" and consuming 53 MB of memory. This indicates the process manager is successfully restarting it, preventing a complete outage. However, each restart implies a brief interruption in data processing, potential loss of in-flight data, and increased CPU cycles for re-initialization. For a streaming process, this is far from ideal, even if it's not a hard crash.
Contrasting Stability: algom-poll and n8n
The same pm2 jlist output highlights processes that exhibit remarkable stability. algom-poll has 0 restarts and has been up for 60 days, consuming 72 MB. n8n also shows 0 restarts, running for 44 days and using 497 MB. These processes demonstrate that stable, long-running operation is achievable on this infrastructure. The difference in behavior points to algom-stream's specific implementation or its interaction with external dependencies as the source of the problem, rather than a systemic infrastructure issue.
The algom-poll process is responsible for polling external APIs, a task that can be prone to network issues or API rate limits. Yet, it remains stable. n8n handles workflow automation, often integrating with various services. Its stability suggests robust error handling or less volatile external dependencies. This contrast is crucial for diagnosing algom-stream's problem: it's not the environment, it's the code or its immediate runtime context.
The Impact of Constant Restarts
- Data Integrity: Each restart risks losing data that was being processed at the moment of failure. While I do not have that measured for
algom-streamspecifically, it's a general concern for streaming applications. - Resource Consumption: Frequent restarts consume CPU cycles for process initialization and memory allocation. While
algom-streamonly uses 53 MB, the cumulative effect of 55193 restarts adds overhead. - Debugging Complexity: The process is always "online," masking the underlying instability. Standard monitoring might not flag it as down, making it harder to prioritize. The
pm2 jlistoutput is the only clear indicator of this specificAlgom-Stream Restart Anomaly. - Hidden Errors: The rapid restart cycle might be suppressing detailed error logs, as the process might not stay up long enough to write comprehensive diagnostics before the next restart. I need to investigate its specific log output, which I do not have measured here.
Next Steps: Deep Dive into algom-stream Logs
The wiki-ship.log shows an error: failed to push some refs to 'https://github.com/ElenaRevicheva/aideazz.git' 22.0 hours ago, indicating a different kind of operational issue. Other logs like apply-queue.log, atlas-ga4-sync.log, and cita-sort.log show successful operations or expected outcomes. The hs-watch-manual-emails.log shows "ok": true outcomes, and reply-radar.log shows REPLIES MATCHED 0 but no errors. This suggests the core system is generally functioning.
The algom-stream issue is isolated. My immediate next step is to analyze the specific logs for algom-stream. I need to configure more verbose logging or capture the output of the process before it restarts. The current pm2 jlist only provides the restart count, not the reason. Without detailed error messages, diagnosing the root cause of 55193 restarts is speculative. Given the presence of oracledb in the proven technologies, a common source of streaming issues is database connection drops or query timeouts, but I do not have that measured for algom-stream specifically.
The NOW.md file, which serves as a shared session for my disconnected AI agents (Cursor Cloud, Cursor Desktop, and Claude Code), highlights the challenge of inter-agent communication. While this isn't directly related to algom-stream's restarts, it underscores the fragmented nature of my AI-driven operations. Each agent works independently, and there's no shared context for debugging or problem-solving across them. This means the algom-stream issue will likely require manual investigation, as no AI agent is currently tasked with monitoring or diagnosing this specific restart anomaly.
Frequently Asked Questions
Q: Why isn't algom-stream considered "down" if it restarts so frequently?
A: pm2 is a process manager designed to keep applications running. When algom-stream crashes, pm2 immediately restarts it, so it's technically "online" from pm2's perspective. The high restart count is an indicator of instability, not a complete outage.
Q: What specific errors are causing the 55193 restarts?
A: I do not have that measured from the provided pm2 jlist output. The pm2 command only reports the restart count and uptime, not the underlying error messages. A deeper dive into algom-stream's specific application logs would be required.
Q: How does this compare to other processes like cto-aipa?
A: cto-aipa has 167 restarts over 3 days, which is also high but significantly less than algom-stream's 55193 restarts over 41 days. While both show instability, algom-stream's issue is far more severe in terms of frequency.
Q: Is this a problem with the Oracle Cloud infrastructure?
A: Given that algom-poll (0 restarts, 60 days up) and n8n (0 restarts, 44 days up) run stably on the same instance, it's unlikely to be a general infrastructure problem. The issue is more likely specific to algom-stream's code, its dependencies, or its interaction with external services.
Top comments (0)