You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This seems to have started today and seems to be making it all but impossible to get a green CI on Raspberry Pi (arm-fanned).
Inspector tests are leaving around stale jobs. Here's a partial copy/paste of an exchange between @refack and me in the node-build IRC channel:
me:
Hanging process is:
home/iojs/build/workspace/node-test-binary-arm/out/Release/node --inspect=0 -p process.debugPort
I don't have access to test-requireio_kahwee-debian9-arm64_pi3-1 but it looks like it could use the same treatment. refack rvagg
Took that one offline. Guess it needs to be added to the ansible playbook for writing the ssh config file.
refack:
I saw home/iojs/build/workspace/node-test-binary-arm/out/Release/node --inspect=0 -p process.debugPort on ceejbot-debian9-armv6l_pi1p-1 as well . Opening an issue
me:
Gotta be test/sequential/test-inspector-port-zero-cluster.js since that one fails so often. Probably leaves a process around when it fails.
Different one on test-requireio_mininodes-debian9-armv6l_pi1p-1 but still an inspector test.
/home/iojs/build/workspace/node-test-binary-arm/out/Release/node --inspect -e const assert = require('assert'); const inspector = process.binding('inspector'); assert( !!inspector.isEnabled(), 'inspector.isEnabled() should be true when run with --inspect'); process._debugEnd(); assert( !inspector.isEnabled(), 'inspector.isEnabled() should be false after _debugEnd()');
Not seeing the issue. Did you open it, refack? Maybe I'm looking in the wrong repo.
Meanwhile test-requireio_continuationlabs-debian9-armv6l_pi1p-1 has 18 of these running:
$ ssh test-requireio_bengl-debian9-armv6l_pi1p-1The authenticity of host '192.168.2.43 (<no hostip for proxy command>)' can't be established.ECDSA key fingerprint is SHA256:87BtCkbkmfMLPwfh69OjNKsCHyGkDsuGcAuazlA4QJM.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added '192.168.2.43' (ECDSA) to the list of known hosts.Linux test-requireio--bengl-debian9-armv6l--pi1p-1 4.14.34+ #1110 Mon Apr 16 14:51:42 BST 2018 armv6lThe programs included with the Debian GNU/Linux system are free software;the exact distribution terms for each program are described in theindividual files in /usr/share/doc/*/copyright.Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extentpermitted by applicable law.Last login: Wed May 30 19:58:35 2018 from 192.168.1.10pi@test-requireio--bengl-debian9-armv6l--pi1p-1:~ $ ps -ef| grep Releaseiojs 22070 883 0 19:20 ? 00:00:01 /home/iojs/build/workspace/node-test-binary-arm/out/Release/node --inspect=0 -e process._debugEnd();process.exit(42);iojs 22084 883 0 19:26 ? 00:00:02 /home/iojs/build/workspace/node-test-binary-arm/out/Release/node /home/iojs/build/workspace/node-test-binary-arm/test/sequential/test-inspector-open.jspi 23194 23150 0 23:10 pts/0 00:00:00 grep --color=auto Releasepi@test-requireio--bengl-debian9-armv6l--pi1p-1:~ $ sudo kill -9 22070 22084pi@test-requireio--bengl-debian9-armv6l--pi1p-1:~ $ ps -ef | grep Releasepi 23208 23150 0 23:10 pts/0 00:00:00 grep --color=auto Releasepi@test-requireio--bengl-debian9-armv6l--pi1p-1:~ $ exitlogoutConnection to 192.168.2.43 closed.Killed by signal 1.
Not really sure how many more of these I need to log.
(Can't assign, actually - will be looking into it)
OK, I just assigned you to it.
@joyeecheung It appears that Collaborators only have Read access to this repo. Any reason not to give them Write access? (Or maybe this issue is in the wrong repo and I should open it in the main repo?)
Is there a way to get SSH access to one of those systems?
To get SSH access to CI machines, you'd open an issue in the Build repo. To expedite things, I'll do that for you right now. Once one or two other Build WG people approve the request (which hopefully won't take more than 10 or 15 minutes, but we'll see), I or someone else can give you access.
Are those processes from my CI runs (ones I started for https://github.com/pulls) or a result of other collaborators running the tests?
@eugeneo I'm not sure. I assumed other collaborators, but I suppose it could have been from your own PRs. I guess we can wait and see if the come back now that I've terminated them all (or at least all the ones I know about). If they come back, they're happening in other PRs. If they don't come back, maybe it was all from your stuff and we can ignore them?
By the way, this kind of suggests a build issue too, because Makefile tries to terminate the processes when it finds them. Unfortunately, I was only able to terminate these processes with root privileges and I suspect we don't run it with root privs on the Raspberry Pi devices (although we do elsewhere.)
Activity
Trott commentedon Jun 7, 2018
Another one:
Not really sure how many more of these I need to log.
Trott commentedon Jun 7, 2018
Another one:
Did a
kill -9there too so it's back to working again.eugeneo commentedon Jun 7, 2018
I'm confident this is because of nodejs/node@327ce2d, assigning to me.
eugeneo commentedon Jun 7, 2018
(Can't assign, actually - will be looking into it)
Is there a way to get SSH access to one of those systems?
Trott commentedon Jun 7, 2018
OK, I just assigned you to it.
@joyeecheung It appears that Collaborators only have Read access to this repo. Any reason not to give them Write access? (Or maybe this issue is in the wrong repo and I should open it in the main repo?)
Trott commentedon Jun 7, 2018
To get SSH access to CI machines, you'd open an issue in the Build repo. To expedite things, I'll do that for you right now. Once one or two other Build WG people approve the request (which hopefully won't take more than 10 or 15 minutes, but we'll see), I or someone else can give you access.
eugeneo commentedon Jun 7, 2018
Are those processes from my CI runs (ones I started for nodejs/node#21182) or a result of other collaborators running the tests?
Upd: PR URL
Trott commentedon Jun 7, 2018
@eugeneo I'm not sure. I assumed other collaborators, but I suppose it could have been from your own PRs. I guess we can wait and see if the come back now that I've terminated them all (or at least all the ones I know about). If they come back, they're happening in other PRs. If they don't come back, maybe it was all from your stuff and we can ignore them?
eugeneo commentedon Jun 7, 2018
@Trott Sounds good. If they are caused by the pending PR, I will be extra careful when running next CI.
Trott commentedon Jun 7, 2018
@eugeneo I checked the build history for one of the hosts that had stalled processes. It last succeeded in https://ci.nodejs.org/job/node-test-binary-arm/RUN_SUBSET=3,label=pi1-docker/1700/ which was started by addaleax and then first failed in https://ci.nodejs.org/job/node-test-binary-arm/RUN_SUBSET=0,label=pi1-docker/1702/ which was started by you, so that strongly suggesting the CIs done in the course of nodejs/node#21182.
Trott commentedon Jun 7, 2018
By the way, this kind of suggests a build issue too, because
Makefiletries to terminate the processes when it finds them. Unfortunately, I was only able to terminate these processes with root privileges and I suspect we don't run it with root privs on the Raspberry Pi devices (although we do elsewhere.)Trott commentedon Jun 7, 2018
CI is running fine now that I've terminated all the stalled jobs. I'm going to close this, since @eugeneo is aware. We can re-open if this recurs.
joyeecheung commentedon Jun 8, 2018
@Trott I've given Collaborators write access now. Should I just give the Core write access?
Trott commentedon Jun 8, 2018
I think Collaborators is probably fine. We can always expand it further later.