Concurrent Puppeteer sessions yield error 124. Below is an alternative NodeJS and PHP example:
const browserLib = require('puppeteer');
(async () => {
const instance = await browserLib.launch({ args: ['--no-sand', '--disable-uid'] });
const tab = await instance.newPage();
await tab.goto('http://dummy');
await tab.screenshot({ path: 'image.png' });
await instance.close();
})();
exec('node altScript.js 2>&1', $result);
print_r($result);
hey, try running each puppeteer in their own enviroments. sometime error 124 means reusable configs interfering. maybe check your async ports or make sure every instance has its own deps. hope that helps!
The challenge with running concurrent Puppeteer instances often originates from overlapping configurations or resource contention. In my experience, assigning each instance a unique configuration or user profile can mitigate many of these issues, including error 124. I encountered similar problems when multiple instances accessed shared filesystem locations. Isolating configurations by, for example, assigning distinct user-data directories proved to be an effective solution. Additionally, verifying the compatibility of dependencies and environment settings can help ensure that the concurrent sessions do not interfere with one another.
In my work with Puppeteer, I ran into error 124 when running concurrent instances which led me to investigate system resource allocations. What I found is that the error wasn’t only about conflicting configurations, but also about how your environment handles simultaneous processes. I ended up optimizing the performance by spacing out the launching times for each instance and using separate user profiles. This not only reduced resource contention but also helped in isolating individual session errors more effectively. In addition, I implemented detailed logging which made tracking down issues much more manageable over time.