x/build: frequent "unexpected stale targets" on linux-arm-arm5spacemonkey after bootstrapping is complete

2019-11-20T22:38:34-39a9cb4/linux-arm-arm5spacemonkey
2019-11-20T22:37:23-be04718/linux-arm-arm5spacemonkey
2019-11-19T06:10:03-8cf5293/linux-arm-arm5spacemonkey
2019-11-19T06:08:56-1046a9c/linux-arm-arm5spacemonkey
2019-11-16T20:31:45-6ba0be1/linux-arm-arm5spacemonkey
2019-11-16T02:06:39-c20b71e/linux-arm-arm5spacemonkey
2019-11-16T00:02:02-5042317/linux-arm-arm5spacemonkey
2019-11-15T22:47:41-72f333a/linux-arm-arm5spacemonkey
See also #33598, but the failure mode here is somewhat different: in that issue the failure always occurs during toolchain3 bootstrapping, whereas here it always occurs after make.bash is complete.
CC @jayconrod @cagedmantis @toothrot @dmitshur @bradfitz

This failure mode is now happening on every build.
@esnolte, you are listed as the owner of that builder here. Could you please investigate?
I wonder if the problem is somehow that multiple builds are running at the same time. (A similar failure mode in #35749 turned out to be an older builder running concurrently with the current one.)

The builder is in a loop filling the logs and eventually the filesystem with:
Dec 18 19:01:57 localhost logger: stage0: 2019/12/18 19:01:57 downloading https://storage.googleapis.com/go-builder-data/buildlet.linux-arm-arm5 to ./buildlet.exe ...
Dec 18 19:01:57 localhost logger: stage0: 2019/12/18 19:01:57 downloaded ./buildlet.exe (12317133 bytes)
Dec 18 19:01:57 localhost logger: stage0: 2019/12/18 19:01:57 downloaded buildlet in 200ms
Dec 18 19:01:57 localhost logger: 2019/12/18 19:01:57 buildlet starting.
Dec 18 19:01:57 localhost logger: 2019/12/18 19:01:57 unlinkat<EMAIL_ADDRESS>permission denied
Here is the service we're running:
root@go-builder-2:/home/builder# cat /etc/service/stage0/run
#!/bin/bash
set -e
SCRATCH=~builder/stage0scratch
export TMPDIR=${SCRATCH}/tmp
export WORKDIR=${SCRATCH}/workdir
mkdir -p ${TMPDIR}
mkdir -p ${WORKDIR}
chown -R builder:builder ${SCRATCH}
cd ${SCRATCH}
export GO_BUILDER_ENV=linux-arm-arm5spacemonkey
export GO_TEST_TIMEOUT_SCALE=5
export USER=builder
export HOME=/home/builder
exec bash -c "setuidgid builder /usr/local/bin/stage0 2>&1 | logger"k
The builder is a binary installed in 2017:
root@go-builder-2:/usr/local/bin# ls -l
total 4912
-rwxr-xr-x 1 root root 5013776 Aug 29  2017 stage0
root@go-builder-2:/usr/local/bin# file stage0
stage0: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
root@go-builder-2:/usr/local/bin# sha1sum stage0
74ae93f72bcb193778383fd7113a5310f74c2e7c  stage0
Should I delete stage0scratch and see if that helps or am I running an old builder and need to upgrade it?

Erik

On 18 Dec 2019, at 10:54, Bryan C. Mills<EMAIL_ADDRESS>wrote:
This failure mode is now happening on every build.
@esnolte https://github.com/esnolte, you are listed as the owner of that builder here https://github.com/golang/build/blob/6b2867eab46056b7c8e75fbfadfa40dc43dbdf91/dashboard/builders.go#L217. Could you please investigate?
I wonder if the problem is somehow that multiple builds are running at the same time. (A similar failure mode in #35749 https://github.com/golang/go/issues/35749 turned out to be an older builder running concurrently with the current one.)

I deleted stage0scratch and restarted the builder and things look better.  I'm not sure when the results will show up on https://build.golang.org/# https://build.golang.org/#

On 18 Dec 2019, at 12:11, Erik Nolte<EMAIL_ADDRESS>wrote:
The builder is in a loop filling the logs and eventually the filesystem with:
Dec 18 19:01:57 localhost logger: stage0: 2019/12/18 19:01:57 downloading https://storage.googleapis.com/go-builder-data/buildlet.linux-arm-arm5 https://storage.googleapis.com/go-builder-data/buildlet.linux-arm-arm5 to ./buildlet.exe ...
Dec 18 19:01:57 localhost logger: stage0: 2019/12/18 19:01:57 downloaded ./buildlet.exe (12317133 bytes)
Dec 18 19:01:57 localhost logger: stage0: 2019/12/18 19:01:57 downloaded buildlet in 200ms
Dec 18 19:01:57 localhost logger: 2019/12/18 19:01:57 buildlet starting.
Dec 18 19:01:57 localhost logger: 2019/12/18 19:01:57 unlinkat<EMAIL_ADDRESS><EMAIL_ADDRESS>permission denied
Here is the service we're running:
root@go-builder-2:/home/builder# cat /etc/service/stage0/run
#!/bin/bash
set -e
SCRATCH=~builder/stage0scratch
export TMPDIR=${SCRATCH}/tmp
export WORKDIR=${SCRATCH}/workdir
mkdir -p ${TMPDIR}
mkdir -p ${WORKDIR}
chown -R builder:builder ${SCRATCH}
cd ${SCRATCH}
export GO_BUILDER_ENV=linux-arm-arm5spacemonkey
export GO_TEST_TIMEOUT_SCALE=5
export USER=builder
export HOME=/home/builder
exec bash -c "setuidgid builder /usr/local/bin/stage0 2>&1 | logger"k
The builder is a binary installed in 2017:
root@go-builder-2:/usr/local/bin# ls -l
total 4912
-rwxr-xr-x 1 root root 5013776 Aug 29  2017 stage0
root@go-builder-2:/usr/local/bin# file stage0
stage0: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
root@go-builder-2:/usr/local/bin# sha1sum stage0
74ae93f72bcb193778383fd7113a5310f74c2e7c  stage0
Should I delete stage0scratch and see if that helps or am I running an old builder and need to upgrade it?

Erik

On 18 Dec 2019, at 10:54, Bryan C. Mills<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
This failure mode is now happening on every build.
@esnolte https://github.com/esnolte, you are listed as the owner of that builder here https://github.com/golang/build/blob/6b2867eab46056b7c8e75fbfadfa40dc43dbdf91/dashboard/builders.go#L217. Could you please investigate?
I wonder if the problem is somehow that multiple builds are running at the same time. (A similar failure mode in #35749 https://github.com/golang/go/issues/35749 turned out to be an older builder running concurrently with the current one.)

That doesn't seem to have fixed the problem. (https://build.golang.org/log/08d3ac2849287e18678df797c542b7329dab3d3e)

I've unplugged a rogue builder we no longer have access to (go-builder-3).  It looks like the other 2 builders are passing tests.

On 19 Dec 2019, at 07:41, Bryan C. Mills<EMAIL_ADDRESS>wrote:
That doesn't seem to have fixed the problem. (https://build.golang.org/log/08d3ac2849287e18678df797c542b7329dab3d3e https://build.golang.org/log/08d3ac2849287e18678df797c542b7329dab3d3e)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/35740?email_source=notifications&email_token=ADY27VMKXKRTK2HR6ZV35DLQZOB2RA5CNFSM4JQDMVCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHJZ3AA#issuecomment-567516544, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADY27VMKJ5CK5SQ6OGPDG4TQZOB2RANCNFSM4JQDMVCA.

Hmm, now https://farmer.golang.org/ shows 0/2 host-linux-arm5spacemonkey hosts available, but lists them both as connected:

Reverse pool by host type (in use / total)

[…]
host-linux-arm5spacemonkey: 0/2 (1 missing)

go-builder-1 (<IP_ADDRESS>:38292) version 24, host-linux-arm5spacemonkey: connected 50m45.9s, idle for 3.41s
go-builder-2 (<IP_ADDRESS>:27320) version 24, host-linux-arm5spacemonkey: connected 1h18m43.9s, idle for 10.2s

linux-arm-arm5spacemonkey rev a197c7bb; waiting_for_machine, 2m28s ago

I've unplugged a rogue builder we no longer have access to (go-builder-3).  It looks like the other 2 builders are passing tests.

By now, this seems to be accurately reflected under the "Reverse pool by host type (in use / total)" section of https://farmer.golang.org/#pools:

host-linux-arm5spacemonkey: 2/2 (1 missing)

I'm not sure why it was showing something else before.

I rebooted everything 30 minutes ago.  Maybe that unwedged the builders.

On 19 Dec 2019, at 11:42, Dmitri Shuralyov<EMAIL_ADDRESS>wrote:
I've unplugged a rogue builder we no longer have access to (go-builder-3). It looks like the other 2 builders are passing tests.
By now, this seems to be accurately reflected under the "Reverse pool by host type (in use / total)" section of https://farmer.golang.org/#pools https://farmer.golang.org/#pools:
host-linux-arm5spacemonkey: 2/2 (1 missing)
I'm not sure why it was showing something else before.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/35740?email_source=notifications&email_token=ADY27VJ6QHJGU7A5EBVH7P3QZO6C3A5CNFSM4JQDMVCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHKRGIA#issuecomment-567612192, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADY27VKLN4B6LLK4MIMUF4TQZO6C3ANCNFSM4JQDMVCA.

The original problem is still happening.

IIRC, the arm5 builders start with a cross-compiled make.bash from a linux-amd64 machine. Perhaps the two environments have drifted?

Closing this issue as the associated builder has been removed as part of #41027.


Allow self signed certificated

As I assume this is an issue with the base I created the original issue here:
https://github.com/steverhoades/oauth2-openid-connect-client/issues/41

if it is going to be implemented in steverhoades/oauth2-openid-connect-client, it will likely be in provider options (options to \OpenIDConnectClient\OpenIDConnectProvider constructor), and we will automatically gain support of it in config/oidc-auth.php provider key with a dependency upgrade.

if it is going to be implemented in steverhoades/oauth2-openid-connect-client or thephpleague/oauth2-client, it will likely be in provider options, and we will automatically gain support of it in config/oidc-auth.php provider key with a dependency upgrade.

https://github.com/thephpleague/oauth2-client/issues/829
does this work for this package here too?

hmm that's a rather DIY approach (bring your own http client)
we do not directly support tweaking the second parameter (instead of the first one, the common options) of provider class yet, but you can override LaravelOIDCAuth\OIDCProviderService, via laravel service provider bindings, for that

yes i did it with this workaround


Removed brackets of light_onoff_brightness_colortemp_colorxy

Addition of GL-B-008Z introduced a bug where light_onoff_brightness_colortemp_colorxy was used as a function. Corrected this bug.

Thanks!