Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

test: rename TEST-EXECRELOAD to avoid name conflict #13575

Merged
merged 1 commit into from
Sep 17, 2019
Merged

test: rename TEST-EXECRELOAD to avoid name conflict #13575

merged 1 commit into from
Sep 17, 2019

Conversation

mrc0mmand
Copy link
Member

@mrc0mmand mrc0mmand commented Sep 17, 2019 •
edited
Loading

As discussed in #13369 (comment), let's rename the TEST-37-EXECRELOAD to TEST-39-EXECRELOAD to avoid conflict with the already existing TEST-37-RUNTIMEDIRECTORYPRESERVE.

Following changes in other PRs should be also pursued to avoid possible future conflicts:

cc @anitazha (ExecXYZEx PR), @msekletar (freezer PR), @keszybz

@keszybz keszybz added the good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed label Sep 17, 2019
@yuwata yuwata merged commit 8813a8c into systemd:master Sep 17, 2019
@mrc0mmand
Copy link
Member Author

The EXECRELOAD test failed on aarch64 probably because of this:

...
execreloadRTJ.service: Trying to enqueue job execreloadRTJ.service/stop/replace
Added job execreloadRTJ.service/stop to transaction.
execreloadRTJ.service: Installed new job execreloadRTJ.service/stop as 195
execreloadRTJ.service: Enqueued job execreloadRTJ.service/stop as 195
execreloadRTJ.service: Changed running -> stop-sigterm
Received SIGCHLD from PID 73 (sleep).
Child 73 (sleep) died (code=killed, status=15/TERM)
execreloadRTJ.service: Failed to read oom_kill field of memory.events cgroup attribute: No such file or directory
execreloadRTJ.service: Child 73 belongs to execreloadRTJ.service.
execreloadRTJ.service: Main process exited, code=killed, status=15/TERM
execreloadRTJ.service: Succeeded.
execreloadRTJ.service: Changed stop-sigterm -> dead
execreloadRTJ.service: Job 195 execreloadRTJ.service/stop finished, result=done
execreloadRTJ.service: Collecting.
Configuration file /etc/systemd/system/execreloadRTJ.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
execreloadRTJ.service: Collecting.
Configuration file /etc/systemd/system/execreloadRTJ.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
execreloadRTJ.service: Collecting.
execreloadRTJ.service: Failed to send unit change signal for execreloadRTJ.service: Connection reset by peer
Received SIGCHLD from PID 28 (bash).
Child 28 (bash) died (code=exited, status=1/FAILURE)
testsuite.service: Failed to read oom_kill field of memory.events cgroup attribute: No such file or directory
testsuite.service: Child 28 belongs to testsuite.service.
testsuite.service: Main process exited, code=exited, status=1/FAILURE
testsuite.service: Failed with result 'exit-code'.
testsuite.service: Changed start -> failed

I'm not sure if the Failed to send unit change signal for execreloadRTJ.service: Connection reset by peer message has to do anything with why the bash process suddenly received a non-zero exit code (most likely from systemctl stop), but it's the only explanation I was able to read out from the logs, which are somewhat confusing due to missing pieces.

@keszybz isn't this related to this #13369 (comment)?

@mrc0mmand mrc0mmand deleted the bump-number-for-TEST-EXECRELOAD branch September 17, 2019 15:42
@keszybz
Copy link
Member

keszybz commented Sep 17, 2019

Failed to send unit change signal for execreloadRTJ.service: Connection reset by peer normally means that systemctl (or something else), which started the job terminated before the signal was sent. So I don't think that's directly related.

In #13369 the code was status=2.

@mrc0mmand mrc0mmand mentioned this pull request Sep 17, 2019
Merged
@mrc0mmand
Copy link
Member Author

Hm, I see, thanks. I'll try to create a local aarch64 VM to debug this further then.

@mrc0mmand
Copy link
Member Author

Well, I tried a QEMU aarch64 VM and also a real aarch64 hardware, and after a couple of hundreds iteration I couldn't reproduce the issue. Let's hope it was indeed a fluke, at least until we get more information about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed quick-review 🏃‍♂️ tests
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@mrc0mmand @keszybz @yuwata