app can't send extrinsic and waits forever

second time this happened to me with 1.13.2 after the app was active for a long time

send Leu
wait on confirmation screen forever

there are no pending extrinsics, so the app most likely didn't even attempt to send
kill app and retry fixes the issue

I had this once while testing too. The extrinsic reaches the node apparently, because we get an extrinsic update as a return value, where it says that the txStatus update is 'ExtrinsicUpdate: invalid'. I don't know yet why this happens yet.

Interestingely, I also got this error the rust-cli against a rococo-local setup (https://github.com/encointer/encointer-parachain/commit/5c320a1bbdff256956b0e148d5ad7f5f32282833):
./bootstrap_demo_community.py --client ../target/release/encointer-client-notee                      ok | 19:13:04
IPFS environment not set up for using gateway
connecting to remote chain:  ws://<IP_ADDRESS>
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UnexpectedTxStatus(Invalid)', client/src/utils.rs:68:78
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

So maybe the error has nothing to do with our dart api, and we just need to make sure to catch it on the dart side and offer, or do automatically, a retry.

With txpool trace logs, it seems that it happens when a transaction is resubmitted from retracted block:
2024-03-19 19:42:48.023 DEBUG tokio-runtime-worker txpool: [Parachain] [0xd9b0e7fc0b71dc3e607accfa09c8da93971044bd8dc9691af4bf41d4f7af186e]: Resubmitting from retracted block 0x2a6d3538913d4f5c31cd4c3977c42de1593b4cb563533029c0ada2be773e8ba3
2024-03-19 19:42:48.023 DEBUG tokio-runtime-worker txpool: [Parachain] Sent 1 transactions to revalidation queue
2024-03-19 19:42:48.024 DEBUG tokio-runtime-worker txpool: [Parachain] Updated revalidation queue at 0xa9eab83603d7acd3929d3fc9dd20cb1b3dfaeceec03030e42b9c0c8202e7a099. Transactions: {0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca: 0xa9eab83603d7acd3929d3fc9dd20cb1b3dfaeceec03030e42b9c0c8202e7a099}
2024-03-19 19:42:48.026 TRACE tokio-runtime-worker txpool: [Parachain] Transaction pool already processed block  #39
2024-03-19 19:42:48.026 DEBUG tokio-runtime-worker txpool: [Parachain] [0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca] Reported as invalid. Will skip sub-chains while iterating.
2024-03-19 19:42:48.026 DEBUG tokio-runtime-worker txpool: [Parachain] Removing invalid transactions: [0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca]
2024-03-19 19:42:48.026 TRACE tokio-runtime-worker txpool: [Parachain] [0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca] Removed as part of the subtree.
2024-03-19 19:42:48.026 DEBUG tokio-runtime-worker txpool: [Parachain] Removed invalid transactions: [Transaction { hash: 0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca, priority: 8, valid_till: 102, bytes: 195, propagate: true, source: TransactionSource::External, requires: [], provides: [90b5ab205c6974c9ea841be688864633dc9ca8a357843eeacf2314649965fe2203000000], data: 840090b5ab205c6974c9ea841be688864633dc9ca8a357843eeacf2314649965fe22013eead0752247203b8d39e1e2b640927325dbf39d0a9834090d36f5aaff16591e85433466af056d03f77fe1511aa8d599df7a6ebb61418bd873f42643a78cf78a75020c000173716d3176f08c911c3d0373716d3176f08c911c0300000008d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d8eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a48}]

I found this issue that might be related https://github.com/paritytech/polkadot-sdk/pull/3079 and have the following thoughts:

Either the behavior implemented in that PR is not quite correct, and submitting a transaction from a retracted block doesn't work.
The PR description made me wonder if we send a tx based on the best block (instead of the latest finalised block) and if that best block is no longer in the canonical chain, we might get this error.

I actually think it is the latter because the above log, doesn't always occur when I get an invalid transaction, hmm.

Ok, I have to revert my statement, I am now quite positive that the above log always occurs when we have a retracted block. However, I wonder if my second bullet point is related to the first one. If we construct the transaction based on finalized block data instead of best block, then the validation of the resubmitted transaction should work. Aka, this just means that we need to supply the latest finalized blockhash/-number instead of the best blockhash/-number. I will try that.


Add SDK artifacts

This allows referencing the extras with the simplified syntax:
<Project Sdk="MSBuild.Sdk.Extras/1.2.2">
...
</Project>

The Microsoft.NET.Sdk is automatically imported at the right
time, so the workaround for Microsoft/msbuild#1045 is no longer
needed.

Do you know if that removes the need for the Import at the bottom of the project file? I think it would this sdk is imported after the .net sdk.

Indeed, it removes the need for the manual import :)

@kzu in the SDK style imports, can we get rid of https://github.com/onovotny/MSBuildSdkExtras/blob/master/MSBuild.Sdk.Extras/build/MSBuild.Sdk.Extras.Core.targets#L92-L108
(in 1.3 when the older usage is removed perhaps?)
I think that if the these targets run before the built-in ones, we'd be ok? That was one of the ordering hacks I had, and I don't like having to copy that from the built-in targets.

Don't know about that. Maybe?
Also, can you push this PR pkg to the myget CI feed so I can demo? ;)

building now

I think there's a fair bit of clean-up we can do once we can go to SDK-only. The trick is that tooling still is bad for it; NuGet won't add it to the right place by default.
I can probably add an error target that gets pulled in for NuGet imports (but not SDK) with a message telling people to remove this reference and put it at the top. Would also help ppl who update the package.
Ideally, NuGet should know what to do with this kind of package.

Yeah, absolutely. An actionable error would be best for the time being
On Tue, Feb 27, 2018, 4:49 PM Oren Novotny<EMAIL_ADDRESS>wrote:

I think there's a fair bit of clean-up we can do once we can go to
SDK-only. The trick is that tooling still is bad for it; NuGet won't add it
to the right place by default.
I can probably add an error target that gets pulled in for NuGet imports
(but not SDK) with a message telling people to remove this reference and
put it at the top. Would also help ppl who update the package.
Ideally, NuGet should know what to do with this kind of package.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/onovotny/MSBuildSdkExtras/pull/36#issuecomment-369003120,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKW62-Phpi59O8QxEr1kAzMuh7mbBS5ks5tZFvbgaJpZM4SVemM
.

--
--
/kzu from mobile

I can probably add an error target that gets pulled in for NuGet imports (but not SDK) with a message telling people to remove this reference and put it at the top. Would also help ppl who update the package.

Already have one for this and the corefx dotnet msbuild & netfx msbuild issue. Will add this to my PR as soon as possible.


@JuliaRegistrator register()

@JuliaRegistrator register()

Error while trying to register: Version 1.0.0 already exists


Add a reference to pybadges

Messages

:book:

:sparkles: Thanks for your contribution to Shields, @brianquinlan!

:book:

Thanks for contributing to our documentation. We :heart: our documentarians!

  Generated by :no_entry_sign: dangerJS

Thanks!


_resolveImage should be smarter about whether the image has actually changed or not

The _ImageState class tries to resolve the image every time it is rebulit/dependencies change.
This works fine when the image is in the cache.  However, we should also try to make it work if the image is still available in the render tree (i.e. the image is still on screen or almost on screen), but not in the cache.
This could possibly be achieved by having some object that tracks on-screen ui.Images, perhaps one that RenderImage adds its images to and removes from when it's detached.
/cc @gaaclarke @liyuqian @goderbauer @Hixie @cbracken @zmtzawqlp @jonahwilliams

What I think we'd want for this is to have some way for the widget to check if the PictureProvider.obtainKey key has changed between states.  If not, then just reuse its render object's image. So before we call image.resolve, we'd want to do something like widget.image.obtainKey and see if the key has changed from the old key.
Where the widget state tries to resolve the image:
https://github.com/flutter/flutter/blob/beb86d2cc408eb54d92ab96ddef8a8fb69182071/packages/flutter/lib/src/widgets/image.dart#L1008-L1016
Where ImageProvider resolves the image:
https://github.com/flutter/flutter/blob/beb86d2cc408eb54d92ab96ddef8a8fb69182071/packages/flutter/lib/src/painting/image_provider.dart#L274-L336

xref https://github.com/flutter/flutter/pull/46357 and https://github.com/flutter/flutter/issues/47380
With this logic, we could be less concerned about whether the image is "long term" cached in the ImageCache, making it easier to work on those issues.

Thank you @dnfield for the proposal! If the fix you suggested were implemented, I wonder if one of our existing driver/performance tests (with ImageCache size set to 0) would reveal the improvement? If not, it might be helpful to first come up with a test. It would also help us understand exactly what the problem looks like.

Does the existing test you wrote to capture memory usage while scrolling track memory during the scrolling, or only at the end?

Alternatively, I would expect us to perform much better with this change and cache size set to 0 on any of the existing tests (we'd not be decoding images every frame).  But I'm not sure if we have any tests that set the size to 0 - if not it should be esay to add one.

My test doesn't track memory during the scrolling. I expect that it would become easy to track the memory during the scroll after https://github.com/flutter/flutter/issues/44013 is solved.
For now, I agree that modifying one of our existing test and setting its cache size to 0 is promising.

Hmm.  I'm doing some pretty simple testing here and I'm having a hard time finding a case where we end up calling _resolveImage while the widget/render object are still in the tree.
I could probably contrive an example to try to force it to happen, but I'm having trouble coming up with one that would occur naturally.
For a simple case of a grid or list view of images, just scrolling isn't enough to trigger this.

@dnfield I just spent some time trying to create a pathological case too and I also couldn't get _resolveImage to get called again either.  I created a custom ImageCache that throws everything out and triggered build on the StatefulWidget which was the parent to the AssetImage.
You know more about how the framework works, is this a non-issue because of the caching mechanism that appears to be at work at a higher level?

I'm pretty sure there's some path where this happens, and we should fix it, but at this point I'm also convinced that such a path is unlikely to arise in normal usage.

I found a way to make this happen.  If you subscribe the image widget to some inherited widget, didChangeDependencies will get called when that widget changes, which could result in trying to resolve the image multiple times.
We don't currently do this in the image widget and it's not clear to me that we ever will.  We should still fix this issue, but I still don't think it's a pressong one.

I'm going to close this as a less interesting sub-issue of #49456 - fixing that issue will fix this one, and this one is a bit too narrowly scoped to be a serious issue anyway.


Cluster selection - on edit items are not vertically aligned

We should align all the items vertically when editing a context

As a note, these should be aligned to the top, not centered vertically

Fixed in #2060


Fix backslash character in Font16

Fix backslash character (0x5C) so that it looks like "\" and NOT
look like normal slash "/" (0x2F) in Font16.

You could also recommend this change in the library we've used in our project

I just noticed that it was already corrected (Nov 11) in the library you indicated.
https://github.com/Bodmer/TFT_eSPI/commit/943b95ec797db5202c2d236cf32d8c69fef8f21b


When opening the console using c it show c in the console

typing c again closes it again unfortunately

Maybe we could open the console with something like ctrl+c

@TheKnarf sounds like a duplicated of #404

Feel free to mark it as duplicate issue and close it.


Compatibility with GATlab

Package works on Catlab#main. Do not merge until after next Catlab release.
Closes #62.

I don't know if we care, but noting that meshes.md generates a 20 MB HTML file.


People and company templates

This pull request creates template files for both the people and companies sections. Thanks to the underscore, these files do not create entries in those sections when viewing the website. Also updated the readme to reflect the new procedure.
Feel free to reject if you want to stick with the current way. Just thought this might be easier for less technical folks.

Can you add a template for FAQs also?
On Jun 22, 2016 12:34 AM, "Sean Ryan"<EMAIL_ADDRESS>wrote:

This pull request creates template files for both the people and companies
sections. Thanks to the underscore, these files do not create entries in
those sections when viewing the website. Also updated the readme to reflect
the new procedure.
Feel free to reject if you want to stick with the current way. Just
thought this might be easier for less technical folks.
You can view, comment on, or merge this pull request online at:
https://github.com/charlestontechnology/charlestontechnology.github.io/pull/52
Commit Summary

Create template file for people section
Create template file for companies section
Update README.md file to use templates
Remove the rest of my personal information from the people template

File Changes

M README.md
https://github.com/charlestontechnology/charlestontechnology.github.io/pull/52/files#diff-0
(31)
A _companies/_template.md
https://github.com/charlestontechnology/charlestontechnology.github.io/pull/52/files#diff-1
(8)
A _people/_template.md
https://github.com/charlestontechnology/charlestontechnology.github.io/pull/52/files#diff-2
(10)

Patch Links:

https://github.com/charlestontechnology/charlestontechnology.github.io/pull/52.patch
https://github.com/charlestontechnology/charlestontechnology.github.io/pull/52.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/charlestontechnology/charlestontechnology.github.io/pull/52,
or mute the thread
https://github.com/notifications/unsubscribe/AACh2T3QyPvPNMQfsK5JWF8EaLPbNdxWks5qOLtXgaJpZM4I7ZeO
.


Typescript Typescript Typescript

Your get blob properties example doesn't compile in Typescript.... so, as is often the case, have spend a while rewriting MS's javascript ... it's 2023, all your code samples should be in Typescript... please!!!!!!
(your typescript samples are missing blob properties, funnily enough)

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 88e9a981-e1ed-07c4-3e75-f39a4b3c828a
Version Independent ID: 7b0db6b3-0d36-81f0-24b4-3be114fcf8fe
Content: Manage properties and metadata for a blob with JavaScript - Azure Storage
Content Source: articles/storage/blobs/storage-blob-properties-metadata-javascript.md
Service: storage
Sub-service: blobs
GitHub Login: @pauljewellmsft
Microsoft Alias: pauljewell

@72gm
Thanks for your feedback! We will investigate and update as appropriate.

@72gm
I'm going to assign this to the document author so they can take a look at it accordingly.
@pauljewellmsft
Can you please check and add your comments on this doc update request as applicable.

https://learn.microsoft.com/en-us/samples/azure/azure-sdk-for-js/storage-blob-typescript/
There is no example with regard to accessing file properties (and specifically metadata) ....
You really need to show some way of safely accessing the metadata properties... at the moment I am having to do this to get a 'reference' metadata key/value pair when (based on your JS example)
properties[property].reference
which is obviously invalid in typescript so having to turn of my linting... it's not entirely obvious what to do so there should be guidance
thanks

@72gm Thank you for explaining the issue.
Both metadata and tags are key/value pairs. The TypeScript type of key/value pairs isn't unique to blob storage so you could use the same type you use in the rest of your source code for this. There are many ways to implement key/value pairs depending on what you store in your value, which is unique to your own project so the exact type would depend on your own metadata.
When I look at the tests for blob storage, I do see a lot of tests include metadata and the metadata doesn't have any typing but the metadata is simple.
What type of compiler error did you get when compiling your code and what type of metadata are you trying to store - that would help resolve how the documentation can better support your usage of Storage?

I understand that you are frustrated with the code samples provided by Microsoft and are requesting that they be updated to TypeScript, as the provided example does not compile in TypeScript, and that the TypeScript samples are missing blob properties.

It sounds like you're requesting that they update the samples to include TypeScript, which would make things a lot easier for you since the current examples aren't compiling. And it's a bummer that the blob properties are missing from the TypeScript samples, too.
Have you tried reaching out to Microsoft for support or posting in a forum for some help? Sometimes the community can be really helpful when it comes to solving coding issues.

The TypeScript samples are coming. Should be ready next week or the week after.

 Are you looking for specifically how to get blob properties in typescript, how to use the properties after your received them, or some other task?

Hi,
On an individual occurrence it's not that big a deal but it's across the board so it's generally frustrating as you seem to be all the time refactoring the samples to get them to work in typescript... the B2C stuff was worse
Some better samples would be good also... if I have a bloblist and look to get metadata props then I'm direct to something like this via (https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-properties-metadata-javascript#get-blob-properties)
async function getProperties(blobClient) {
  const properties = await blobClient.getProperties();
  console.log(blobClient.name + ' properties: ');

  for (const property in properties) {
    switch (property) {
      // nested properties are stringified and returned as strings
      case 'metadata':
      case 'objectReplicationRules':
        console.log(`    ${property}: ${JSON.stringify(properties[property])}`);
        break;
      default:
        console.log(`    ${property}: ${properties[property]}`);
        break;
    }
  }
}

which you try to incorporate in your code not realising blobClient.getProperties() does a network call for each blob in your list... which you don't notice until you try to scale it... so a better way it to include the metadata with the container client call.... I had 70 files so instead of doing 71 calls I now do 1
export const getBlobsAndMetadata = async (
  containerClient: ContainerClient
): Promise<FileBlob[]> => {
  const blobItems: FileBlob[] = [];

  for await (const fileBlob of containerClient.listBlobsFlat({ includeMetadata: true,  })) {
    const newBlob: FileBlob = { name: fileBlob.name, url: '', meta: [] };
    newBlob.url = containerClient.getBlobClient(fileBlob.name).url;

    for (const meta in fileBlob.metadata) {
      newBlob.meta.push({
        key: meta,
        val: fileBlob.metadata[meta],
      });
    }
    blobItems.push(newBlob);
  }
  return blobItems;
};

Ok the await might have given that away but you might have just thought that was the only way to do it....

Ok, I see where you are going. Let me see if I can get close to your needs.

@72gm @AlexandraBeshaws @HughSinarathD
Thanks so much for this helpful feedback. We've attempted to address the initial ask for TypeScript samples by adding an additional article set specifically for TypeScript.
There is also ongoing work to provide consistent and relevant code samples across all languages for these types of articles. If you have further suggestions on a particular article, please feel free to open an issue.
I do like the idea of mentioning potential scalability issues. Even if the focus here is mostly around usage of the getProperties() method, I think we can call out some of those scenarios where an alternative approach is best.
Feel free to reach out if you have further questions. We're glad to engage more on this, if needed.
FYI - @diberry

Closing this issue out as the initial request was addressed, but please feel free to re-open if you'd like to engage further.
FYI - @diberry
#please-close


Fixes#571 Adds returncode for CalledProcessError

Hello @JayjeetAtGithub! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file cli/popper/tests.py:

Line 6:33: E231 missing whitespace after ','
Line 7:22: W292 no newline at end of file

@ivotron Can you please tell me why this import is failing in travis while behaving correctly in local ?

[test cli_test] ./cli_test
+python ../../cli/popper/tests.py
Traceback (most recent call last):
  File "../../cli/popper/tests.py", line 1, in <module>
    import popper.utils as pu
ModuleNotFoundError: No module named 'popper'

@ivotron Please have a look !

thanks!


[FEATURE] vignette removal

Elden Ring has a really strong vignette effect. An option to remove / reduce it would be welcome.

+1!

Added with this PR, in case you want it: https://github.com/uberhalit/EldenRingFpsUnlockAndMore/pull/111


Fix missing unit-tests test:device & better debug output

Plus:

add rspy.log.debug_indent()
add rspy.test.print_separator()
fix some weird behavior with rspy.log color output

Everything looks good :)


Updated triggers

Commented out - frontend/* trigger, it seems to trigger all pipelines quite often, causes a big CPU usage spike. Is it needed?

Codecov Report

Merging #794 (911ee9d) into develop (b306351) will decrease coverage by 47.65%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           develop     #794       +/-   ##
============================================
- Coverage    63.29%   15.64%   -47.66%
============================================
  Files          791       44      -747
  Lines        20011      537    -19474
  Branches      1952       69     -1883
============================================
- Hits         12666       84    -12582
+ Misses        6981      437     -6544
+ Partials       364       16      -348

Impacted Files
Coverage Δ

backend/kesaseteli/companies/api/v1/views.py

...it/terms/migrations/0002_termsofserviceapproval.py

.../migrations/0006_field_changes_for_employee_api.py

backend/benefit/messages/apps.py

frontend/benefit/handler/jest.config.js

...end/shared/src/components/toast/ToastContainer.tsx

frontend/shared/src/utils/typescript.utils.ts

...mponents/attachmentsIngress/AttachmentsIngress.tsx

frontend/kesaseteli/employer/src/pages/login.tsx

...rc/hooks/application/useToggleSerialNumberInput.ts

... and 737 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b306351...911ee9d. Read the comment docs.


We need to improve the release process

Currently releases are done when PRs are merged, we should be able to stack up a few PRs and release that under a single version.

Some resources that may be useful for this:

Release Please Action - https://github.com/google-github-actions/release-please-action
Release Please - https://github.com/googleapis/release-please

Did we make any changes to this? With the bumping of the provider, we should probably release a new major release version -- what's the process we want to use for that?


Module on How to debug k8s

What would you like to be added?
a module how to debug a broken kubernetes system for common issues. For example, why is my pod not being exposed. Or why is my database crashlooping (say, the volume is full).
Justin Garrison shared this with me on the AWS Twitch Stream (2023-02-08). Might be a good starting point
https://thenewstack.io/living-with-kubernetes-12-commands-to-debug-your-workloads/
Why is this needed?
It's needed because in the real world things WILL go wrong at some point. There might be a multitude of reasons why it goes wrong and a very important part of being a developer/devops engineer is figuring out what's wrong, and eventually finding a proper solution.

Thanks for opening this issue @mkraenz. While we initially considered including Kubernetes basics content, one of our core tenets is to keep the content Amazon EKS-focused. That being said, we do link heavily to Kubernetes and other open-source documentation. We have no plans at the moment to include a dedicated module for debugging Kubernetes.
I'd be open to a PR with links to debugging resources such as this.


TypeError: e.slice is not a function when calling removeNodeId

I'm encountering an error when trying to remove a node using editor.removeNodeId(nodeId) in the Drawflow library. The error message is:
TypeError: e.slice is not a function

It seems that removeNodeId expects the node ID to be a string to always start with 'node-'
Steps to Reproduce

Add a Node:
const nodeId = editor.addNode('example', 1, 1, 100, 100, 'example-node', {}, '
Example Node
');

addNode returns a numeric nodeId.

Attempt to Remove the Node:
editor.removeNodeId(nodeId); // nodeId is a number

Error Occurs:
TypeError: e.slice is not a function

Workaround
I found a workaround by converting the numeric ID to a string with 'node-' prefix:
editor.removeNodeId('node-' + nodeId);

This resolves the error and the node is removed as expected.
Suggestion
It would be helpful if removeNodeId could handle numeric IDs directly! Alternatively, changing the documentation to specify the expected ID format would be great.
Additional Information

Drawflow Version: 0.0.60
Browser: Chrome Version 128.0.6613.138 (Official Build) (arm64)
Operating System: macOS 14.1.1 (23B81)

Thank you for your time and for developing this useful library!

Hello
There is confusion with the function parameters, some are "node-x" others are just the ID.
But it is to maintain the same format as previous versions. So that there are no breaking changes.
In the description there is an example in each case:
https://github.com/jerosoler/Drawflow#methods
Regards, Jero

Hey, thanks for the quick response, I already thought it would be something like that, makes sense :)
Maybe it would make it a bit easier for beginners if you were to add a small paragraph to the readme, maybe something like:

In Drawflow, some functions expect node IDs as "node-x" strings (e.g., "node-5"), while others use numeric IDs (e.g., 5). This is intentional to maintain compatibility with previous versions and avoid breaking changes.


Carthage fix

We solve that error
`** CLEAN FAILED **
The following build commands failed:
Check dependencies
(1 failure)
** BUILD FAILED **
The following build commands failed:
Check dependencies
(1 failure)
A shell task (/usr/bin/xcrun xcodebuild -project /Users/XXX/XXX/iOS/Carthage/Checkouts/SlideMenuControllerSwift/SlideMenuControllerSwift.xcodeproj -scheme SlideMenuControllerSwift-iOS -configuration Release -sdk iphoneos ONLY_ACTIVE_ARCH=NO BITCODE_GENERATION_MODE=bitcode CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES clean build) failed with exit code 65:
** CLEAN FAILED **
The following build commands failed:
Check dependencies
(1 failure)
** BUILD FAILED **
The following build commands failed:
Check dependencies
(1 failure)`

same issue with swift 3.0.1 xcode 8.1

thanks!

@dekatotoro You're welcome


Community driven examples

I think after terraform v12 I would like to improve/enrich our examples of the provider.

If you have any examples that you want to share with community, how you use the provider, feel free to spend a PR for enriching the examples directory. (https://github.com/dmacvicar/terraform-provider-libvirt/tree/master/examples)

if you have an upstream opensource project which use the provider, (https://github.com/dmacvicar/terraform-provider-libvirt#upstream-projects-using-terraform-libvirt) feel free to send a PR for link to it

IMHO, it can be also intersting to update the various distro there examples, something like this: https://github.com/MalloZup/ceph-open-terrarium/tree/master/examples/libvirt

we are ok more or less. closing for moment


Typo and sentence structure

form -> from
then network interface -> then the network interface
then target IP -> then the target IP

@prateek9us - Please review the proposed changes.  Thanks

Thanks.
#sign-off

If sign-off was given two weeks ago, how come changes have not yet been merged?


ReferenceError: meteor_runtime_config is not defined

I am trying to use this with my webpack project
but I get this error
ReferenceError: __meteor_runtime_config__ is not defined
Here are the steps I did
create a new meteor project
then I run the client bundler like this
meteor-client bundle —source=./ —destination=./meteor-client.bundle.js —config=meteor-client.config.json
and here is the config
{
  "runtime": {
    "DDP_DEFAULT_CONNECTION_URL": "http://localhost:3000"
  },
  "import": [
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>    "react-meteor-data"
  ]
}

then I copy my meteor-client.js to my webpack project node_modules
and import it like this
import 'meteor-client'
then I bundle webpack and run dev-server and I get the above mentioned error.

please try again with the new 0.4.0 version


Investigate document.onClick handler not firing in AR

@EdwardLu2018 confirming this issue resolved w/ aframe reversion?

A mixture of aframe reversion and the fact that globals.lastMouseTarget was never being set for some reason


Recording unavailable

Steps to reproduce the behaviour:

Go to https://superhero.com/league
Join the event
Click on the burger menu
Click on Start Recording button
Click on Start Recording on the pop-up
See an error:

OS: Mac 10.15.7
Wallet: Superhero 5d91965 / v.0.3.3
superhero ui: b9a82bc / 0.2.1

This is because jibri was not started

I have checked that the error is reproducible again on my side.


[Schema] The Kuma Schema is not generated accurately, missing fields for rjsf rendering

Description
The kuma components in all its latest version follow the same pattern with no schema generation that can be used as a rjsf field.
All the schema follow the same format as below.
Screenshots
Add screenshots, if applicable, to help explain your problem.
Enviroment:

OS: [e.g. Ubuntu]
Browser: [e.g. Chrome, Safari]
Version: [e.g. 22]
Device: [e.g. laptop, iPhone 8]

[Optional] To Reproduce
Steps to reproduce the behavior:

Start a latest kuma adapater
See the workloads

[Optional] Additional Context
Add any other context about the problem here.
Contributor Resources
The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the master branch.

See the Contributing to Meshery.io Website section of the readme.md and other contributing instructions, too.
See Meshery site designs in this Figma designfile. Fill-in the Layer5 Community Member Form and join the Layer5 Community Slack for access.

// @iamsdas

@Revolyssup ANy workaround or approach for this in your mind?


Deadlock when using hipSYCL in multithreaded applications

Bug summary
Trying to use hipSYCL from a multi-thread (POSIX threads) application occasionally leads to a never-ending queue::wait(). The more threads there are, the likelier it is.
The deadlock happens when calling queue.wait() from one of the threads. Looking at a stack trace, the thread is stuck on a _condition_wait.wait call inside worker_thread::wait, despite the _enqueued_operations being empty.
Apparently, this thread was not awoken by _condition_wait.notify_one() from the executor thread.
The issue is resolved by replacing all notify_one() with notify_all() in async_worker.cpp, but that may be a bit heavy-handed?
To Reproduce
Happens pretty regularly in GROMACS runs, with both CUDA and HIP backends. I can come up with a shorted reproducer if needed, but I hope the description would be sufficient to reason through.
Expected behavior
worker_thread::wait() should return as soon as there are no more tasks in the queue.
Describe your setup

hipSYCL 46d6b3c (latest develop)
Describe the dependencies that hipSYCL sits on top of in your setup:

clang-11 from Ubuntu repos for CUDA build, clang-13 from ROCm for HIP build.
CUDA 11.4 (clang-11.0)
ROCm 4.3

Tested with cuda:sm_75 and hip:gfx906 backends (separate builds)

Thanks for reporting!

The issue is resolved by replacing all notify_one() with notify_all() in async_worker.cpp, but that may be a bit heavy-handed?

I think this is the correct approach.  I'm not sure if there's anything more lightweight than this, but I'll check to make sure.


[BUG] Vertical overflow on Design-inspiration subcategory in mobile view

Is there any existing issue for this?

[X] I have searched the existing issues

Description
There is some vertical overflow in the design-inspiration subcategory on mobile view
Screenshots

Any additional information?
No response
What browser are you seeing the problem on?
Firefox

@ConradQQ thank you noticing :)

Hi! Can I work on this issue?

@zvolcsey sure, assigning to you


Implement naive trader

Problem:

We need a trader agent that buys and sells based on the predicted signal
Very naive strategy: simply market buy and market sell 5 mins later

This exists already. It's the trader bot.
It's in pdr_backend/trader/*
And for the simulations, it already exists too, as part of pdr_backend/predictoor/approach3/.


How can I navigate between weeks/months/year ?

Your timetable is the most beautiful one I've been finding out there and best suits my need (Time Schedule for School). However I don't see any property supporting week navigation. And I don't see one in the Usage.
Please show me or add this function if you haven't built. Thank you very much.

Thanks for your support!
As this timetable component is designed for a repetitive schedule (i.e. same schedule for every week), no week navigation is supported.
If you want to add calendar-based events, you may use react-native-calendars to select a date and recompute the events for that week, you may also want to hide the header & tick (will provide options in the next release) to update the dates for that week.

Thanks for your response. Because other calendar doesn’t show the info of the event card by default (which needs pressing to show) so I chose yours.
Also my idea is that there are subjects which ends sooner or starts on next weeks so I think Week navigation helps students see the Schedule better and prepare well.
Did you mean to import their calendar while using your library to use their Week navigation along with your Time table ?
I am new to React native so I now can only rely on libraries. Therefore I don’t know if we can combine functions from different libraries and they don’t conflict. If you accept to build the navigation, it’d be a Great help. Thanks again.

I understand that you wish to build a timetable with distinct events every week, and navigate between weeks.
I agree that it will be great for this component to support it. Nevertheless, it requires a substantial change in logic and API of this component, and I am sorry that I do not have the time to do it in the foreseeable time.
You may fork this component to build your own logic on top of the event card UI. Gook luck with your project!

Okay, I see. Thanks for spending your time!


I was going to report a vey weird situation with flexbox but your issue template turned me off, I think you need to change the repository name.

Hello!
As the "web" thinks this is the repository for "flebox bugs" I was going to report something that I think is a bug. But then I found this issue template.
So I think you should rename the repo to "flexbox workarounds" or something like that. Because the current name is confusing, in your own words about the repository named "flexbugs":

This repo is not for reporting Flexbox bugs

lol, You making me and others lose our time,
### Important! Please read before opening an issue:

- This repo **is not** for reporting Flexbox bugs in browsers. Please report those directly to the browsers themselves. Here's a link to all major browser bug trackers: https://developers.google.com/web/feedback/#reporting-bugs

- This repo **is not** for asking Flexbox quesions, please use Stack Overflow for that.

- This repo **is** for reporting cross-browser workarounds to already-reported Flexbox bugs. Please only open an issue if you know of a good, cross-browser workaround and the bug has already been reported to all affected browsers.

### Things to include in your issue:

- Please include links to the bugs for each affected browser's bug tracker.

- Please include a live demo ([CodePen](https://codepen.io/) or [JSBin](https://jsbin.com)) showing both the issue and the workaround.

- Please clearly explain exactly what the expected behavior is and what's not happening in the affected browser(s). It's not always immediately obvious from looking at a demo what is wrong.

Maybe the web changed the scope of your own repository and you should change the scope of it. You don't have any obligation to maintain it of course. But at least something is clear between you and the world.

Lul
On Mar 2, 2019, at 2:27 PM, Tito <notifications<EMAIL_ADDRESS>wrote:
Maybe the web changed the scope of your own repository and you should change the scope of it. You don't have any obligation to maintain it of course. But at least something is clear between you and the world.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/philipwalton/flexbugs/issues/267#issuecomment-468957073, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AtVOLexEv_qinavUIEgjLogV5UaNgOvUks5vSt6VgaJpZM4bamQv.

I do understand the confusion but he is right to say that actual browser bugs should be reported to the browser developers directly.

I agree also but how I am supposed to find for a workaround, the point of
opening the issue was to find a workaround about something that looks like
flexbox bug
On Mon, 4 Mar 2019, 11:48 Garrett W<EMAIL_ADDRESS>wrote:

I do understand the confusion but he is right to say that actual browser
bugs should be reported to the browser developers directly.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/philipwalton/flexbugs/issues/267#issuecomment-469278679,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD6nB1p4y-59hGOM8B09N-JBrd1824Dks5vTTJagaJpZM4bamQv
.

--
__
Tito

You can ask for assistance on Stack Overflow or the SitePoint forums. If you reply here with a link, I (or someone else here) might take a look at it too.

Search in your browser's bug tracker to see if it's been reported.


UI rendering problems

Type: Bug
When working in Visual Studio Code, user inteface elements sometimes are not rendered correctly, including text rendering of open files, toolbars, like search one, version control one, so everywhere in application.
It happens almost always. Problems started maybe about couple of months ago. (maybe it is realted to upgrade to latest ubuntu, not sure)
It is very bad, app feels broken. Workaround is to reopen file, to change windows, tabs, and so on.
VS Code version: Code 1.81.1 (6c3e3dba23e8fadc360aed75ce363ba185c49794, 2023-08-09T22:18:39.991Z)
OS version: Linux x64 6.2.0-32-generic snap
Modes:
Remote OS version: Linux x64 6.2.0-32-generic

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz (16 x 2724)

GPU Status
2d_canvas: unavailable_softwarecanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: disabled_softwaremultiple_raster_threads: enabled_onopengl: disabled_offrasterization: disabled_softwareraw_draw: disabled_off_okvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: unavailable_softwarewebgl2: unavailable_softwarewebgpu: disabled_off

Load (avg)
3, 2, 1

Memory (System)
30.55GB (23.74GB free)

Process Argv
--no-sandbox . --crash-reporter-id cdb8874b-fade-4371-bce1-8ea4823c1674

Screen Reader
no

VM
0%

DESKTOP_SESSION
ubuntu

XDG_CURRENT_DESKTOP
Unity

XDG_SESSION_DESKTOP
ubuntu

XDG_SESSION_TYPE
x11

Item
Value

Remote
Dev Container

OS
Linux x64 6.2.0-32-generic

CPUs
11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz (16 x 800)

Memory (System)
30.55GB (23.75GB free)

VM
0%

Extensions (17)

Extension
Author (truncated)
Version

jupyter-keymap
ms-
1.1.2

remote-containers
ms-
0.304.0

pdf
tom
1.2.2

Kotlin
mat
1.7.1

vscode-docker
ms-
1.26.0

python
ms-
2023.14.0

vscode-pylance
ms-
2023.8.50

java
red
1.21.0

vscode-xml
red
0.26.1

intellicode-api-usage-examples
Vis
0.2.8

vscodeintellicode
Vis
1.2.30

vscode-gradle
vsc
3.12.7

vscode-java-debug
vsc
0.54.0

vscode-java-dependency
vsc
0.23.1

vscode-java-pack
vsc
0.25.13

vscode-java-test
vsc
0.39.1

vscode-maven
vsc
0.42.0

(1 theme extensions excluded)

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
py29gd2263:30792226
vscaac:30438847
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
vsccc:30803844
3biah626:30602489
f6dab269:30613381
showlangstatbar:30737416
03d35959:30757346
57b77579:30736110
pythonfmttext:30731395
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
pythonnosmt12:30797651
pythonidxptcf:30805731
pythonnoceb:30805159
dsvsc013:30795093
dsvsc014:30804076
diffeditorv2:30821572
dsvsc015:30829745

/gifPlease

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.
If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.
Happy coding!

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


fix: Cancel previous authenticate session when new is started

Currently only autocomplete: true auth session will abort previous one.
A common scenario is to have autocomplete session "running" but still present to user with additional "Login with passkey" option.

Makes sense. Thanks for the PR 👍


[Improvement] More Android testing guides, especially unit and UI testing

Hi,
I don't feel comfortable writing unit testing in my Android app. I know how important part of writing any code that is, so I would like you @google-admin @googlebot ask of any useful materials to improve my testing skills.
I really like Udacity courses about Android development, design, performance and much more... but there are no courses about writing test cases.
Which tools do you recommend and where I can find some about it materials, tutorials?
Regards.

There is a Google codelab to get you started.

Closing as not related to samples but we got the message, thanks!

@IgorGanapolsky, I've already found this site :+1: . Could you give some more related to topic?
@JoseAlcerreca sorry, but I didn't know where put this message .
Thanks for response


Update spotless and refactor WordUtils

Codecov Report

Merging #749 (ddbb750) into main (17575b9) will increase coverage by 92.86%.
The diff coverage is 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main     #749       +/-   ##
===========================================
+ Coverage        0   92.86%   +92.86%
- Complexity      0     2595     +2595
===========================================
  Files           0      281      +281
  Lines           0     5127     +5127
  Branches        0      530      +530
===========================================
+ Hits            0     4761     +4761
- Misses          0      240      +240
- Partials        0      126      +126

Impacted Files
Coverage Δ

.../java/net/datafaker/internal/helper/WordUtils.java
83.33% <100.00%> (ø)

... and 280 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Large amounts of messages will start to overlap on each other in Safari

If you write, say, 20 messages in the box they'll start to overlap on each other (only in Safari, other browsers are fine). The reason is the class 'message container' doesn't want to properly wrap around the content, hence eventually creating the mess.

Thanks! I'll look into it.

This issue is still not solved. Any ideas how to perfectly wrap around the content so that messages don't begin to over lap?

Now Fixed! Sorry for the delay!


Fix typo in repr

It follows the Issue #255.

Codecov Report

Merging #256 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #256   +/-   ##
=======================================
  Coverage   68.29%   68.29%
=======================================
  Files           9        9
  Lines        2747     2747
=======================================
  Hits         1876     1876
  Misses        871      871

Impacted Files
Coverage Δ

ross/bearing_seal_element.py
65.39% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1538633...93100df. Read the comment docs.

Codecov Report

Merging #256 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #256   +/-   ##
=======================================
  Coverage   68.29%   68.29%
=======================================
  Files           9        9
  Lines        2747     2747
=======================================
  Hits         1876     1876
  Misses        871      871

Impacted Files
Coverage Δ

ross/bearing_seal_element.py
65.39% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1538633...93100df. Read the comment docs.


dep ensure -vendor-only does not work as expected

When using dep ensure -vendor-only I expect that the Gopkg.toml will not be parsed and that the vendor folder will be built entirely using the Gopkg.lock; especially using the source="" keys strictly to determine sources.
The problem (relates to #860 but that's grown long and unfocused, and hasn't been fixed for 1+ years), is that we have some dependencies (both direct and nested) that are in a repo that is not and cannot be available to our CI pipeline. Thus I've mirrored those repos into GitHub in a location that is accessible. This should be easy, but bugs in dep are blocking. There seem to be two issues:
1 - dep ensure -add totally.private.intranet.repo/amazing/package:github.com/accessible/amazing/package should just work and should NOT attempt to read nor connect to totally.private.intranet.repo/amazing/package but it does.
2 - dep ensure -vendor-only should just trust the Gopkg.lock file and install using the source keys when specified. So, in the case of the following projects block in the Gopkg.lock, dep should not attempt to connect to "name" and should only read from source. It shouldn't care about the Gopkg.toml, since after all we're using -vendor-only.
[[projects]]
  branch = "master"
  digest = "1:..."
  name = "totally.private.intranet.repo/amazing/package"
  packages = [
    "thing1",
    "thing2",
    "thing3",
  ]
  pruneopts = "UT"
  revision = "completely valid commit hash"
  source = "https://github.com/accessible/amazing/package"

Instead, this happens:
dep ensure -vendor-only
The following issues were found in Gopkg.toml:

  ✗ unable to deduce repository and source type for "totally.private.intranet.repo/amazing/package": unable to read metadata: unable to fetch raw metadata: failed HTTP request to URL "http://totally.private.intranet.repo/amazing/package?go-get=1": Get http://totally.private.intranet.repo/amazing/package?go-get=1: dial tcp: lookup totally.private.intranet.repo on <IP_ADDRESS>:53: no such host

ProjectRoot name validation failed

Of course the host in inaccessible, isn't that the point of using an alternate location?? Why is a -vendor-only install even reading the .toml?  Why is it trying contact the named package instead of the source?
Is it possible dep is trying to be a little too smart and making bad assumptions?
dep:
 version     : v0.5.0
 build date  : 2018-07-26
 git hash    : 224a564
 go version  : go1.10.3
 go compiler : gc
 platform    : darwin/amd64
 features    : ImportDuringSolve=false

Help resolving this would be greatly appreciated. We really need a fix on this and I see lots of folks seem to be affected (referencing the stale, #860).
Other than dropping dep and checking in the whole source folder, what option do we have?

Thanks for the report. Do you have a public repo that can reproduce the problem you describe?
FWIW I would also recommend checking in the source folder if that's possible.

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!


exclude .git by default

TODO tags in the .git directory are obviously what we don't want to track...

Thanks! Fixed in 2ed93d55d413428152ddd318ed8238293765cf6f

It seems to me the .github directory was wrongly excluded since it contains a prefix of .git...
xref: https://github.com/deepmodeling/deepmd-kit/issues/3520#issuecomment-2007907909

Good point. Fixed in v0.4.10 of this action.


first iteration on bdd files

added steps & features files
first pass at creating shopcarts + items model in steps file
created background for both shopcarts + items in feature file
did not refactor index.html

@nyu-kaitlyn copied and pasted over the changes from lab-flask-bdd. Made a first pass at generating the items + shopcarts model but not 100% sure it's correct and it v likely needs refactoring (I'm not entirely sure how to connect the two tables in the steps and features file). FYI bc we have two models, we will have to do everything twice like we did in TDD


containerdiag.sh didn't collect javacore file.

I tried the containerdiag.sh on OCP 4.8.43 and it didn't collect the javacore files from the pod. I needed to manually copy the javacore file.
[root@symposia1 cp4a]# oc get deployment
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
simplehighcpu   1/1     1            1           5m24s
[root@symposia1 cp4a]# chmod +x containerdiag.sh
[root@symposia1 cp4a]# ./containerdiag.sh -d simplehighcpu libertyperf.sh
[2022-07-06 23:21:38 PDT] containerdiag.sh: Script started with oc and quay.io/ibm/containerdiag:latest
[2022-07-06 23:21:38 PDT] containerdiag.sh: Querying available replicas for deployment simplehighcpu in namespace defaulte
[2022-07-06 23:21:38 PDT] containerdiag.sh: There are 1 available replicas
[2022-07-06 23:21:38 PDT] containerdiag.sh: Querying deployment selector label
[2022-07-06 23:21:38 PDT] containerdiag.sh: Selector labels are deployment=simplehighcpu
[2022-07-06 23:21:38 PDT] containerdiag.sh: Getting pods by selector
[2022-07-06 23:21:39 PDT] containerdiag.sh: Found the following pods:\nsimplehighcpu-6d79ccfbbd-6fqfm worker2.aaaaa.cp.fyre.ibm.com
[2022-07-06 23:21:39 PDT] containerdiag.sh: Processing pod simplehighcpu-6d79ccfbbd-6fqfm on worker node worker2.aaaaa.cp.fyre.ibm.com with libertyperf.sh simplehighcpu-6d79ccfbbd-6fqfm
Starting pod/worker2aaaaacpfyreibmcom-debug ...
To use host binaries, run `chroot /host`
Pod IP: <IP_ADDRESS>
If you don't see a command prompt, try pressing enter.
Writing to /tmp/containerdiag.SGVo71GpkN/
/tmp/containerdiag.SGVo71GpkN /
[2022-07-07 06:22:01.139674115 UTC] run.sh: started on worker2.aaaaa.cp.fyre.ibm.com
[2022-07-07 06:22:01.210255824 UTC] run.sh: gathering first set of system info.
[2022-07-07 06:22:05.737489403 UTC] run.sh: executing command: sh -c linperf.sh -q<PHONE_NUMBER>92 && DUMPS="$(libertydump.sh   -p simplehighcpu-6d79ccfbbd-6fqfm)"; podfscp.sh  -s  -p simplehighcpu-6d79ccfbbd-6fqfm /logs /config /output/javacore* ${DUMPS} ; podfsrm.sh   -p simplehighcpu-6d79ccfbbd-6fqfm /output/javacore* ${DUMPS}
[2022-07-07 06:22:05.740421610 UTC] run.sh: waiting for background commands (PID 266504) to finish...
Thu Jul 7 06:22:05 UTC 2022 MustGather>> linperf.sh script starting...
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Script version:  2022.05.03.
Thu Jul 7 06:22:05 UTC 2022 MustGather>> PROBLEMATIC_PID is:  260388
Thu Jul 7 06:22:05 UTC 2022 MustGather>> PROBLEMATIC_PID is:  260292
Thu Jul 7 06:22:05 UTC 2022 MustGather>> SCRIPT_SPAN = 240
Thu Jul 7 06:22:05 UTC 2022 MustGather>> JAVACORE_INTERVAL = 30
Thu Jul 7 06:22:05 UTC 2022 MustGather>> TOP_INTERVAL = 60
Thu Jul 7 06:22:05 UTC 2022 MustGather>> TOP_DASH_H_INTERVAL = 5
Thu Jul 7 06:22:05 UTC 2022 MustGather>> VMSTAT_INTERVAL = 5
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collecting user authority data...
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collection of user authority data complete.
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Creating output files...
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Output files created:
Thu Jul 7 06:22:05 UTC 2022 MustGather>>      vmstat.out
Thu Jul 7 06:22:05 UTC 2022 MustGather>>      ps.out
Thu Jul 7 06:22:05 UTC 2022 MustGather>>      top.out
Thu Jul 7 06:22:05 UTC 2022 MustGather>>      topdashH.260388.out
Thu Jul 7 06:22:05 UTC 2022 MustGather>>      topdashH.260292.out
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collecting the first netstat snapshot...
Thu Jul 7 06:22:05 UTC 2022 MustGather>> First netstat snapshot complete.
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Starting collection of top data...
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collection of top data started.
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Starting collection of top dash H data...
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collection of top dash H data started for PID 260388.
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collection of top dash H data started for PID 260292.
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Starting collection of vmstat data...
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collection of vmstat data started.
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collecting a ps snapshot...
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collected a ps snapshot.
Thu Jul 7 06:22:05 UTC 2022 MustGather>> Collecting a javacore...
:
:
Thu Jul 7 06:25:36 UTC 2022 MustGather>> Collected a javacore for PID 260388.
Thu Jul 7 06:25:36 UTC 2022 MustGather>> Collected a javacore for PID 260292.
Thu Jul 7 06:25:36 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-07 06:25:40.772175739 UTC] run.sh: waiting for script to complete
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Collecting the final ps snapshot...
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Collected the final ps snapshot.
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Collecting the final javacore...
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Collected the final javacore for PID 260388.
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Collected the final javacore for PID 260292.
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Collecting the final netstat snapshot...
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Final netstat snapshot complete.
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Collecting other data.  This may take a few moments...
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Collected other data.
Thu Jul 7 06:26:06 UTC 2022 MustGather>> Preparing for packaging and cleanup...
[2022-07-07 06:26:10.776188683 UTC] run.sh: waiting for script to complete
Thu Jul 7 06:26:11 UTC 2022 MustGather>> Compressing output files into linperf_RESULTS.tar.gz
netstat.out
vmstat.out
ps.out
top.out
screen.out
dmesg.out
whoami.out
df-hk.out
topdashH.260388.out
topdashH.260292.out
Thu Jul 7 06:26:11 UTC 2022 MustGather>> Cleaning up...
Thu Jul 7 06:26:11 UTC 2022 MustGather>> Clean up complete.
Thu Jul 7 06:26:11 UTC 2022 MustGather>> linperf.sh script complete.
[2022-07-07 06:26:11.356722735 UTC] libertydump.sh: started with  simplehighcpu-6d79ccfbbd-6fqfm
/usr/local/bin/libertydump.sh: line 90: [: /proc/260388: binary operator expected
[2022-07-07 06:26:14.879070953 UTC] libertydump.sh: Error:  Could not find proc inforrmation for pod simplehighcpu-6d79ccfbbd-6fqfm PID<PHONE_NUMBER>92
[2022-07-07 06:26:14.880672784 UTC] libertydump.sh: script returning
[2022-07-07 06:26:14.884040463 UTC] podfscp.sh: started with /logs /config /output/javacore* for  simplehighcpu-6d79ccfbbd-6fqfm
unshare: cannot change root directory to '/host//var/lib/containers/storage/overlay/a3828bb840fc158b0a8026fcef6614e8b5e35b00d499cf435dab3d413171739b/merged /var/lib/containers/storage/overlay/0c849138cf6f34019325af673bea4d584445b5f63b5c917174e5fae0a6bc755d/merged/': No such file or directory
[2022-07-07 06:26:16.665903844 UTC] podfscp.sh: Path /logs for pod simplehighcpu-6d79ccfbbd-6fqfm does not evaluate to a real path within /var/lib/containers/storage/overlay/a3828bb840fc158b0a8026fcef6614e8b5e35b00d499cf435dab3d413171739b/merged /var/lib/containers/storage/overlay/0c849138cf6f34019325af673bea4d584445b5f63b5c917174e5fae0a6bc755d/merged
unshare: cannot change root directory to '/host//var/lib/containers/storage/overlay/a3828bb840fc158b0a8026fcef6614e8b5e35b00d499cf435dab3d413171739b/merged /var/lib/containers/storage/overlay/0c849138cf6f34019325af673bea4d584445b5f63b5c917174e5fae0a6bc755d/merged/': No such file or directory
[2022-07-07 06:26:16.669766445 UTC] podfscp.sh: Path /config for pod simplehighcpu-6d79ccfbbd-6fqfm does not evaluate to a real path within /var/lib/containers/storage/overlay/a3828bb840fc158b0a8026fcef6614e8b5e35b00d499cf435dab3d413171739b/merged /var/lib/containers/storage/overlay/0c849138cf6f34019325af673bea4d584445b5f63b5c917174e5fae0a6bc755d/merged
unshare: cannot change root directory to '/host//var/lib/containers/storage/overlay/a3828bb840fc158b0a8026fcef6614e8b5e35b00d499cf435dab3d413171739b/merged /var/lib/containers/storage/overlay/0c849138cf6f34019325af673bea4d584445b5f63b5c917174e5fae0a6bc755d/merged/': No such file or directory
[2022-07-07 06:26:16.673459252 UTC] podfscp.sh: Path /output/javacore* for pod simplehighcpu-6d79ccfbbd-6fqfm does not evaluate to a real path within /var/lib/containers/storage/overlay/a3828bb840fc158b0a8026fcef6614e8b5e35b00d499cf435dab3d413171739b/merged /var/lib/containers/storage/overlay/0c849138cf6f34019325af673bea4d584445b5f63b5c917174e5fae0a6bc755d/merged
cp: cannot stat '/host//var/log/pods/defaulte_simplehighcpu-6d79ccfbbd-6fqfm_d9d6840e-961d-425f-853d-183ab18b1c56/simplehighcpu/0.log /var/log/pods/defaulte_simplehighcpu-6d79ccfbbd-6fqfm_d9d6840e-961d-425f-853d-183ab18b1c56/cea4d3b529ab7df53826e3bdfbbd02a445e8f1eb6ae9bae4c415775140ba9cb3.log': No such file or directory
cp: cannot stat '/host/proc/260388 260292/cgroup': No such file or directory
cat: '/host/proc/260388 260292/cgroup': No such file or directory
[2022-07-07 06:26:20.102486005 UTC] podfscp.sh: script returning
[2022-07-07 06:26:20.105265277 UTC] podfsrm.sh: started with /output/javacore* for  simplehighcpu-6d79ccfbbd-6fqfm
unshare: cannot change root directory to '/host//var/lib/containers/storage/overlay/a3828bb840fc158b0a8026fcef6614e8b5e35b00d499cf435dab3d413171739b/merged /var/lib/containers/storage/overlay/0c849138cf6f34019325af673bea4d584445b5f63b5c917174e5fae0a6bc755d/merged/': No such file or directory
[2022-07-07 06:26:21.938306709 UTC] podfsrm.sh: Path /output/javacore* for pod simplehighcpu-6d79ccfbbd-6fqfm does not evaluate to a real path within /var/lib/containers/storage/overlay/a3828bb840fc158b0a8026fcef6614e8b5e35b00d499cf435dab3d413171739b/merged /var/lib/containers/storage/overlay/0c849138cf6f34019325af673bea4d584445b5f63b5c917174e5fae0a6bc755d/merged
[2022-07-07 06:26:21.940075206 UTC] podfsrm.sh: script returning
[2022-07-07 06:26:40.780180533 UTC] run.sh: command completed.
[2022-07-07 06:26:40.783168191 UTC] run.sh: gathering second set of system info.
[2022-07-07 06:26:45.426275995 UTC] run.sh: All data gathering complete.
[2022-07-07 06:26:45.428912393 UTC] run.sh: Packaging for download.
[2022-07-07 06:26:45.471634984 UTC] run.sh: Finished with output in /tmp/containerdiag.SGVo71GpkN.tar.gz
[2022-07-07 06:26:45.472870236 UTC] run.sh: Debug pod is worker2aaaaacpfyreibmcom-debug in namespace defaulte
-rw-r--r--. 1 root root 414K Jul  7 06:26 /tmp/containerdiag.SGVo71GpkN.tar.gz
[2022-07-07 06:26:45.475895765 UTC] run.sh: Files are ready for download. Download with the following command in another window:

  oc cp worker2aaaaacpfyreibmcom-debug:/tmp/containerdiag.SGVo71GpkN.tar.gz containerdiag.SGVo71GpkN.tar.gz --namespace=defaulte

After the download is complete, type OK and press ENTER: OK
[2022-07-07 06:28:44.017012647 UTC] run.sh: Processing finished. Deleting /tmp/containerdiag.SGVo71GpkN.tar.gz
[2022-07-07 06:28:44.019170974 UTC] run.sh: finished.

Removing debug pod ...
[2022-07-06 23:28:44 PDT] containerdiag.sh: Finished
[root@symposia1 cp4a]#

[root@symposia1 cp4a]# oc cp worker2aaaaacpfyreibmcom-debug:/tmp/containerdiag.SGVo71GpkN.tar.gz containerdiag.SGVo71GpkN.tar.gz --namespace=defaulte
tar: Removing leading `/' from member names
[root@symposia1 cp4a]# mkdir tmp
[root@symposia1 cp4a]# cp containerdiag.SGVo71GpkN.tar.gz ./tmp/
[root@symposia1 cp4a]# cd tmp
[root@symposia1 tmp]# tar xzf containerdiag.SGVo71GpkN.tar.gz
[root@symposia1 tmp]# tar xzf linperf_RESULTS.tar.gz
[root@symposia1 tmp]# tree
.
|-- containerdiag.SGVo71GpkN.tar.gz
|-- df-hk.out
|-- dmesg.out
|-- linperf_RESULTS.tar.gz
|-- netstat.out
|-- node
|   |-- info
|   |   |-- cgroups.txt
|   |   |-- cpuinfo.txt
|   |   |-- date.txt
|   |   |-- df.txt
|   |   |-- hostname.txt
|   |   |-- journalctl_errwarn.txt
|   |   |-- journalctl_head.txt
|   |   |-- journalctl_tail.txt
|   |   |-- lscpu.txt
|   |   |-- meminfo.txt
|   |   |-- release.txt
|   |   |-- sysctl.txt
|   |   |-- systemctlunits.txt
|   |   |-- ulimit.txt
|   |   |-- uname.txt
|   |   |-- uptime.txt
|   |   `-- version.txt
|   |-- stats_iteration1_20220707_062201
|   |   |-- cgtop.txt
|   |   |-- iostat.txt
|   |   |-- ipaddr.txt
|   |   |-- iplink.txt
|   |   |-- loadavg.txt
|   |   |-- netstati.txt
|   |   |-- netstats.txt
|   |   |-- netstat.txt
|   |   |-- nstat.txt
|   |   |-- ps.txt
|   |   |-- ssdetails.txt
|   |   |-- sssummary.txt
|   |   |-- topthreads.txt
|   |   `-- top.txt
|   `-- stats_iteration2_20220707_062640
|       |-- cgtop.txt
|       |-- iostat.txt
|       |-- ipaddr.txt
|       |-- iplink.txt
|       |-- loadavg.txt
|       |-- netstati.txt
|       |-- netstats.txt
|       |-- netstat.txt
|       |-- nstat.txt
|       |-- ps.txt
|       |-- ssdetails.txt
|       |-- sssummary.txt
|       |-- topthreads.txt
|       `-- top.txt
|-- pods
|   `-- simplehighcpu-6d79ccfbbd-6fqfm
|       |-- cgroup
|       |   `-- cpuset
|       `-- pid.txt
|-- ps.out
|-- run_stdouterr.log
|-- screen.out
|-- topdashH.260292.out
|-- topdashH.260388.out
|-- top.out
|-- vmstat.out
`-- whoami.out

8 directories, 59 files
[root@symposia1 tmp]#

@kgibm could you find the console output below?
kgibmconsole.out.txt

I see, so there are two containers in this pod: simplehighcpu and POD. Do both have java processes inside?
The containerdiag script assumed one java container per pod, so I will need to enhance it to handle multiple containers.

It seems there is only one container in the pod.
yamayoshi@yamadayoshikis-MacBook-Pro ~ % oc describe pod simplehighcpu-6d79ccfbbd-6fqfm
Name:         simplehighcpu-6d79ccfbbd-6fqfm
Namespace:    defaulte
Priority:     0
Node:         worker2.tentage.cp.fyre.ibm.com/<IP_ADDRESS>
Start Time:   Thu, 07 Jul 2022 15:15:15 +0900
Labels:       deployment=simplehighcpu
              pod-template-hash=6d79ccfbbd
Annotations:  k8s.v1.cni.cncf.io/network-status:
                [{
                    "name": "openshift-sdn",
                    "interface": "eth0",
                    "ips": [
                        "<IP_ADDRESS>"
                    ],
                    "default": true,
                    "dns": {}
                }]
              k8s.v1.cni.cncf.io/networks-status:
                [{
                    "name": "openshift-sdn",
                    "interface": "eth0",
                    "ips": [
                        "<IP_ADDRESS>"
                    ],
                    "default": true,
                    "dns": {}
                }]
              openshift.io/generated-by: OpenShiftNewApp
              openshift.io/scc: restricted
Status:       Running
IP:           <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/simplehighcpu-6d79ccfbbd
Containers:
  simplehighcpu:
    Container ID:   cri-o://b00806115a2317ff24764d0a368bc671033563284feffe959e31743408b224b1
    Image:          image-registry.openshift-image-registry.svc:5000/defaulte/simplehighcpu@sha256:2ced1725d4a00b6351ffbb9b072e3e1ace6c3f36240b871bcf27d86168f3183b
    Image ID:       image-registry.openshift-image-registry.svc:5000/defaulte/simplehighcpu@sha256:2ced1725d4a00b6351ffbb9b072e3e1ace6c3f36240b871bcf27d86168f3183b
    Ports:          9080/TCP, 9443/TCP
    Host Ports:     0/TCP, 0/TCP
    State:          Running
      Started:      Thu, 07 Jul 2022 15:15:17 +0900
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-f5xrz (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  kube-api-access-f5xrz:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
    ConfigMapName:           openshift-service-ca.crt
    ConfigMapOptional:       <nil>
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>
yamayoshi@yamadayoshikis-MacBook-Pro ~ %

yamayoshi@yamadayoshikis-MacBook-Pro ~ % oc debug node/worker2.tentage.cp.fyre.ibm.com
Starting pod/worker2tentagecpfyreibmcom-debug ...
To use host binaries, run `chroot /host`
Pod IP: <IP_ADDRESS>
If you don't see a command prompt, try pressing enter.
sh-4.4# ps -ef | grep java
1000630+  260388  260376  0 Jul07 ?        00:07:57 /opt/ibm/java/jre/bin/java -javaagent:/opt/ibm/wlp/bin/tools/ws-javaagent.jar -Djava.awt.headless=true -Djdk.attach.allowAttachSelf=true -jar /opt/ibm/wlp/bin/tools/ws-server.jar defaultServer
root     1177873 1177738  0 03:27 pts/0    00:00:00 grep java
sh-4.4# ps -ef | grep 260292
root      260292  260281  0 Jul07 ?        00:00:00 /usr/bin/pod
root     1178474 1177738  0 03:28 pts/0    00:00:00 grep 260292
sh-4.4#

On the node, 260388 is the actual libery process, but 260292 is "usr/bin/pod".

Hmm, Interesting. From the runc state, it shows that pod has two containers:
[2022-07-08 00:28:30.424774376 UTC] podinfo.sh: unshare -rR /host runc state b00806115a2317ff24764d0a368bc671033563284feffe959e31743408b224b1
[2022-07-08 00:28:30.436632431 UTC] podinfo.sh: {
  "ociVersion": "1.0.2-dev",
  "id": "b00806115a2317ff24764d0a368bc671033563284feffe959e31743408b224b1",
  "pid": 260388,
  "status": "running",
[...]
    "io.kubernetes.container.name": "simplehighcpu",
[...]
    "io.kubernetes.pod.name": "simplehighcpu-6d79ccfbbd-6fqfm",
[...]
[2022-07-08 00:28:30.589115168 UTC] podinfo.sh: unshare -rR /host runc state cea4d3b529ab7df53826e3bdfbbd02a445e8f1eb6ae9bae4c415775140ba9cb3
[2022-07-08 00:28:30.603240422 UTC] podinfo.sh: {
  "ociVersion": "1.0.2-dev",
  "id": "cea4d3b529ab7df53826e3bdfbbd02a445e8f1eb6ae9bae4c415775140ba9cb3",
  "pid": 260292,
  "status": "running",
[...]
    "io.kubernetes.container.name": "POD",
[...]
    "io.kubernetes.pod.name": "simplehighcpu-6d79ccfbbd-6fqfm",
[...]

In any case, containerdiag.sh should handle multiple pods, and also it should check to only handle java processes, because sending kill -3 to non-java processes may kill them. I will work on this soon and let you know when I have a new version to test. Thanks!

@e30532 Can you please try again with the following test fix image?
./containerdiag.sh -i quay.io/ibm/containerdiag:test20220714k -d simplehighcpu libertyperf.sh

@kgibm The new code detected the liberty process id correctly.
[root@symposia1 ~]# oc debug node/worker0.tracked.cp.fyre.ibm.com
Starting pod/worker0trackedcpfyreibmcom-debug ...
To use host binaries, run `chroot /host`
Pod IP: <IP_ADDRESS>
If you don't see a command prompt, try pressing enter.
sh-4.4# ps -ef  | grep java
1000630+  142495  142483 28 05:03 ?        00:01:31 /opt/ibm/java/jre/bin/java -javaagent:/opt/ibm/wlp/bin/tools/ws-javaagent.jar -Djava.awt.headless=true -Djdk.attach.allowAttachSelf=true -jar /opt/ibm/wlp/bin/tools/ws-server.jar defaultServer

Here is the console output.
[root@symposia1 cp4a]# ./containerdiag.sh -i quay.io/ibm/containerdiag:test20220714k -d simplehighcpu libertyperf.sh
[2022-07-14 22:06:33 PDT] containerdiag.sh: Script started with oc and quay.io/ibm/containerdiag:test20220714k
[2022-07-14 22:06:33 PDT] containerdiag.sh: Querying available replicas for deployment simplehighcpu in namespace defaulte
[2022-07-14 22:06:33 PDT] containerdiag.sh: There are 1 available replicas
[2022-07-14 22:06:33 PDT] containerdiag.sh: Querying deployment selector label
[2022-07-14 22:06:34 PDT] containerdiag.sh: Selector labels are deployment=simplehighcpu
[2022-07-14 22:06:34 PDT] containerdiag.sh: Getting pods by selector
[2022-07-14 22:06:34 PDT] containerdiag.sh: Found the following pods:\nsimplehighcpu-74957b76f6-jwz2l worker0.tracked.cp.fyre.ibm.com
[2022-07-14 22:06:34 PDT] containerdiag.sh: Processing pod simplehighcpu-74957b76f6-jwz2l on worker node worker0.tracked.cp.fyre.ibm.com with libertyperf.sh simplehighcpu-74957b76f6-jwz2l
Starting pod/worker0trackedcpfyreibmcom-debug ...
To use host binaries, run `chroot /host`
Pod IP: <IP_ADDRESS>
If you don't see a command prompt, try pressing enter.
Writing to /tmp/containerdiag.rWX2R98mMc/
/tmp/containerdiag.rWX2R98mMc /
[2022-07-15 05:06:59.396080377 UTC] run.sh: started on worker0.tracked.cp.fyre.ibm.com version 0.1.20220714
[2022-07-15 05:06:59.470373747 UTC] run.sh: gathering first set of system info.
[2022-07-15 05:07:04.018909964 UTC] run.sh: executing command: sh -c linperf.sh -q       142495  && DUMPS="$(libertydump.sh   -p simplehighcpu-74957b76f6-jwz2l)"; podfscp.sh  -s  -p simplehighcpu-74957b76f6-jwz2l /logs /config /output/javacore* ${DUMPS} ; podfsrm.sh   -p simplehighcpu-74957b76f6-jwz2l /output/javacore* ${DUMPS}
[2022-07-15 05:07:04.021335953 UTC] run.sh: waiting for background commands (PID 146418) to finish...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> linperf.sh script starting...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Script version:  2022.05.03.
Fri Jul 15 05:07:04 UTC 2022 MustGather>> PROBLEMATIC_PID is:  142495
Fri Jul 15 05:07:04 UTC 2022 MustGather>> SCRIPT_SPAN = 240
Fri Jul 15 05:07:04 UTC 2022 MustGather>> JAVACORE_INTERVAL = 30
Fri Jul 15 05:07:04 UTC 2022 MustGather>> TOP_INTERVAL = 60
Fri Jul 15 05:07:04 UTC 2022 MustGather>> TOP_DASH_H_INTERVAL = 5
Fri Jul 15 05:07:04 UTC 2022 MustGather>> VMSTAT_INTERVAL = 5
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collecting user authority data...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collection of user authority data complete.
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Creating output files...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Output files created:
Fri Jul 15 05:07:04 UTC 2022 MustGather>>      vmstat.out
Fri Jul 15 05:07:04 UTC 2022 MustGather>>      ps.out
Fri Jul 15 05:07:04 UTC 2022 MustGather>>      top.out
Fri Jul 15 05:07:04 UTC 2022 MustGather>>      topdashH.142495.out
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collecting the first netstat snapshot...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> First netstat snapshot complete.
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Starting collection of top data...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collection of top data started.
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Starting collection of top dash H data...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collection of top dash H data started for PID 142495.
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Starting collection of vmstat data...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collection of vmstat data started.
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collecting a ps snapshot...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collected a ps snapshot.
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collecting a javacore...
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Collected a javacore for PID 142495.
Fri Jul 15 05:07:04 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-15 05:07:09.024665461 UTC] run.sh: waiting for script to complete
Fri Jul 15 05:07:34 UTC 2022 MustGather>> Collecting a ps snapshot...
Fri Jul 15 05:07:34 UTC 2022 MustGather>> Collected a ps snapshot.
Fri Jul 15 05:07:34 UTC 2022 MustGather>> Collecting a javacore...
Fri Jul 15 05:07:34 UTC 2022 MustGather>> Collected a javacore for PID 142495.
Fri Jul 15 05:07:34 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-15 05:07:39.028055501 UTC] run.sh: waiting for script to complete
Fri Jul 15 05:08:04 UTC 2022 MustGather>> Collecting a ps snapshot...
Fri Jul 15 05:08:04 UTC 2022 MustGather>> Collected a ps snapshot.
Fri Jul 15 05:08:04 UTC 2022 MustGather>> Collecting a javacore...
Fri Jul 15 05:08:04 UTC 2022 MustGather>> Collected a javacore for PID 142495.
Fri Jul 15 05:08:04 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-15 05:08:09.030870589 UTC] run.sh: waiting for script to complete

Removing debug pod ...
[2022-07-14 22:08:10 PDT] containerdiag.sh: Finished
[root@symposia1 cp4a]#

Thanks, I've updated the latest tag. Please try again and see if it produces the expected files including javacores, etc.
./containerdiag.sh -d simplehighcpu libertyperf.sh

@kgibm it didn't give me a chance to download the diagnostic data (containerdiag.******.tar.gz).
[root@symposia1 cp4a]# ./containerdiag.sh -d simplehighcpu libertyperf.sh
[2022-07-18 21:02:38 PDT] containerdiag.sh: Script started with oc and quay.io/ibm/containerdiag:latest
[2022-07-18 21:02:38 PDT] containerdiag.sh: Querying available replicas for deployment simplehighcpu in namespace defaulte
[2022-07-18 21:02:39 PDT] containerdiag.sh: There are 1 available replicas
[2022-07-18 21:02:39 PDT] containerdiag.sh: Querying deployment selector label
[2022-07-18 21:02:39 PDT] containerdiag.sh: Selector labels are deployment=simplehighcpu
[2022-07-18 21:02:39 PDT] containerdiag.sh: Getting pods by selector
[2022-07-18 21:02:39 PDT] containerdiag.sh: Found the following pods:\nsimplehighcpu-576d7ddf66-zq5gh worker0.xiphoid.cp.fyre.ibm.com
[2022-07-18 21:02:39 PDT] containerdiag.sh: Processing pod simplehighcpu-576d7ddf66-zq5gh on worker node worker0.xiphoid.cp.fyre.ibm.com with libertyperf.sh simplehighcpu-576d7ddf66-zq5gh
Starting pod/worker0xiphoidcpfyreibmcom-debug ...
To use host binaries, run `chroot /host`
Pod IP: <IP_ADDRESS>
If you don't see a command prompt, try pressing enter.
Writing to /tmp/containerdiag.MJRxBDwxrp/
/tmp/containerdiag.MJRxBDwxrp /
[2022-07-19 04:03:06.487028368 UTC] run.sh: started on worker0.xiphoid.cp.fyre.ibm.com version 0.1.20220714
[2022-07-19 04:03:06.557464606 UTC] run.sh: gathering first set of system info.
[2022-07-19 04:03:11.091801435 UTC] run.sh: executing command: sh -c linperf.sh -q       82972  && DUMPS="$(libertydump.sh   -p simplehighcpu-576d7ddf66-zq5gh)"; podfscp.sh  -s  -p simplehighcpu-576d7ddf66-zq5gh /logs /config /output/javacore* ${DUMPS} ; podfsrm.sh   -p simplehighcpu-576d7ddf66-zq5gh /output/javacore* ${DUMPS}
[2022-07-19 04:03:11.094356026 UTC] run.sh: waiting for background commands (PID 85286) to finish...
Tue Jul 19 04:03:11 UTC 2022 MustGather>> linperf.sh script starting...
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Script version:  2022.05.03.
Tue Jul 19 04:03:11 UTC 2022 MustGather>> PROBLEMATIC_PID is:  82972
Tue Jul 19 04:03:11 UTC 2022 MustGather>> SCRIPT_SPAN = 240
Tue Jul 19 04:03:11 UTC 2022 MustGather>> JAVACORE_INTERVAL = 30
Tue Jul 19 04:03:11 UTC 2022 MustGather>> TOP_INTERVAL = 60
Tue Jul 19 04:03:11 UTC 2022 MustGather>> TOP_DASH_H_INTERVAL = 5
Tue Jul 19 04:03:11 UTC 2022 MustGather>> VMSTAT_INTERVAL = 5
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Collecting user authority data...
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Collection of user authority data complete.
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Creating output files...

Tue Jul 19 04:03:11 UTC 2022 MustGather>> First netstat snapshot complete.
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Starting collection of top data...
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Collection of top data started.
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Starting collection of top dash H data...
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Collection of top dash H data started for PID 82972.
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Starting collection of vmstat data...
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Collection of vmstat data started.
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 04:03:11 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 04:03:16.099177721 UTC] run.sh: waiting for script to complete
Tue Jul 19 04:03:41 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 04:03:41 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 04:03:41 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 04:03:41 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 04:03:41 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 04:03:46.103635351 UTC] run.sh: waiting for script to complete
Tue Jul 19 04:04:11 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 04:04:11 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 04:04:11 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 04:04:11 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 04:04:11 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 04:04:16.107652188 UTC] run.sh: waiting for script to complete
Tue Jul 19 04:04:41 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 04:04:41 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 04:04:41 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 04:04:41 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 04:04:41 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 04:04:46.111172766 UTC] run.sh: waiting for script to complete

Removing debug pod ...
[2022-07-18 21:04:51 PDT] containerdiag.sh: Finished
[root@symposia1 cp4a]#

Hmm, interesting. It looks like your debug pod timeout is even more aggressive than the default. Can you please try this?
./containerdiag.sh -d simplehighcpu libertyperf.sh -d 10

@kgibm it worked!
[root@symposia1 cp4a]# ./containerdiag.sh -d simplehighcpu libertyperf.sh -d 10
[2022-07-19 01:05:28 PDT] containerdiag.sh: Script started with oc and quay.io/ibm/containerdiag:latest
[2022-07-19 01:05:28 PDT] containerdiag.sh: Querying available replicas for deployment simplehighcpu in namespace defaulte
[2022-07-19 01:05:30 PDT] containerdiag.sh: There are 1 available replicas
[2022-07-19 01:05:30 PDT] containerdiag.sh: Querying deployment selector label
[2022-07-19 01:05:30 PDT] containerdiag.sh: Selector labels are deployment=simplehighcpu
[2022-07-19 01:05:30 PDT] containerdiag.sh: Getting pods by selector
[2022-07-19 01:05:30 PDT] containerdiag.sh: Found the following pods:\nsimplehighcpu-576d7ddf66-zq5gh worker0.xiphoid.cp.fyre.ibm.com
[2022-07-19 01:05:30 PDT] containerdiag.sh: Processing pod simplehighcpu-576d7ddf66-zq5gh on worker node worker0.xiphoid.cp.fyre.ibm.com with libertyperf.sh -d 10 simplehighcpu-576d7ddf66-zq5gh
Starting pod/worker0xiphoidcpfyreibmcom-debug ...
To use host binaries, run `chroot /host`
Pod IP: <IP_ADDRESS>
If you don't see a command prompt, try pressing enter.
Writing to /tmp/containerdiag.ey7pWCcrlu/
/tmp/containerdiag.ey7pWCcrlu /
[2022-07-19 08:05:34.912617270 UTC] run.sh: started on worker0.xiphoid.cp.fyre.ibm.com version 0.1.20220714
[2022-07-19 08:05:34.997037900 UTC] run.sh: gathering first set of system info.
[2022-07-19 08:05:39.509687394 UTC] run.sh: executing command: sh -c linperf.sh -q       82972  && DUMPS="$(libertydump.sh   -p simplehighcpu-576d7ddf66-zq5gh)"; podfscp.sh  -s  -p simplehighcpu-576d7ddf66-zq5gh /logs /config /output/javacore* ${DUMPS} ; podfsrm.sh   -p simplehighcpu-576d7ddf66-zq5gh /output/javacore* ${DUMPS}
[2022-07-19 08:05:39.512947127 UTC] run.sh: waiting for background commands (PID 256603) to finish...
Tue Jul 19 08:05:39 UTC 2022 MustGather>> linperf.sh script starting...
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Script version:  2022.05.03.
Tue Jul 19 08:05:39 UTC 2022 MustGather>> PROBLEMATIC_PID is:  82972
Tue Jul 19 08:05:39 UTC 2022 MustGather>> SCRIPT_SPAN = 240
Tue Jul 19 08:05:39 UTC 2022 MustGather>> JAVACORE_INTERVAL = 30
Tue Jul 19 08:05:39 UTC 2022 MustGather>> TOP_INTERVAL = 60
Tue Jul 19 08:05:39 UTC 2022 MustGather>> TOP_DASH_H_INTERVAL = 5
Tue Jul 19 08:05:39 UTC 2022 MustGather>> VMSTAT_INTERVAL = 5
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Collecting user authority data...
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Collection of user authority data complete.
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Creating output files...

Tue Jul 19 08:05:39 UTC 2022 MustGather>> First netstat snapshot complete.
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Starting collection of top data...
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Collection of top data started.
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Starting collection of top dash H data...
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Collection of top dash H data started for PID 82972.
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Starting collection of vmstat data...
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Collection of vmstat data started.
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 08:05:39 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 08:05:44.516947576 UTC] run.sh: waiting for script to complete
[2022-07-19 08:05:54.519796535 UTC] run.sh: waiting for script to complete
[2022-07-19 08:06:04.523665855 UTC] run.sh: waiting for script to complete
Tue Jul 19 08:06:09 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 08:06:09 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 08:06:09 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 08:06:09 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 08:06:09 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 08:06:14.527125172 UTC] run.sh: waiting for script to complete
[2022-07-19 08:06:24.530986055 UTC] run.sh: waiting for script to complete
[2022-07-19 08:06:34.534693775 UTC] run.sh: waiting for script to complete
Tue Jul 19 08:06:39 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 08:06:39 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 08:06:39 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 08:06:39 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 08:06:39 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 08:06:44.539035723 UTC] run.sh: waiting for script to complete
[2022-07-19 08:06:54.543917733 UTC] run.sh: waiting for script to complete
[2022-07-19 08:07:04.547655164 UTC] run.sh: waiting for script to complete
Tue Jul 19 08:07:09 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 08:07:09 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 08:07:09 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 08:07:09 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 08:07:09 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 08:07:14.551135039 UTC] run.sh: waiting for script to complete
[2022-07-19 08:07:24.555148901 UTC] run.sh: waiting for script to complete
[2022-07-19 08:07:34.558604977 UTC] run.sh: waiting for script to complete
Tue Jul 19 08:07:39 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 08:07:39 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 08:07:39 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 08:07:39 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 08:07:39 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 08:07:44.562350945 UTC] run.sh: waiting for script to complete
[2022-07-19 08:07:54.566240709 UTC] run.sh: waiting for script to complete
[2022-07-19 08:08:04.570140319 UTC] run.sh: waiting for script to complete
Tue Jul 19 08:08:09 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 08:08:09 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 08:08:09 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 08:08:09 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 08:08:09 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 08:08:14.573724626 UTC] run.sh: waiting for script to complete
[2022-07-19 08:08:24.577413725 UTC] run.sh: waiting for script to complete
[2022-07-19 08:08:34.580928002 UTC] run.sh: waiting for script to complete
Tue Jul 19 08:08:39 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 08:08:39 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 08:08:39 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 08:08:39 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 08:08:39 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 08:08:44.584684722 UTC] run.sh: waiting for script to complete
[2022-07-19 08:08:54.587513782 UTC] run.sh: waiting for script to complete
[2022-07-19 08:09:04.590810025 UTC] run.sh: waiting for script to complete
Tue Jul 19 08:09:09 UTC 2022 MustGather>> Collecting a ps snapshot...
Tue Jul 19 08:09:09 UTC 2022 MustGather>> Collected a ps snapshot.
Tue Jul 19 08:09:09 UTC 2022 MustGather>> Collecting a javacore...
Tue Jul 19 08:09:09 UTC 2022 MustGather>> Collected a javacore for PID 82972.
Tue Jul 19 08:09:09 UTC 2022 MustGather>> Continuing to collect data for 30 seconds...
[2022-07-19 08:09:14.594915979 UTC] run.sh: waiting for script to complete
[2022-07-19 08:09:24.599104023 UTC] run.sh: waiting for script to complete
[2022-07-19 08:09:34.611286671 UTC] run.sh: waiting for script to complete
Tue Jul 19 08:09:39 UTC 2022 MustGather>> Collecting the final ps snapshot...
Tue Jul 19 08:09:39 UTC 2022 MustGather>> Collected the final ps snapshot.
Tue Jul 19 08:09:40 UTC 2022 MustGather>> Collecting the final javacore...
Tue Jul 19 08:09:40 UTC 2022 MustGather>> Collected the final javacore for PID 82972.
Tue Jul 19 08:09:40 UTC 2022 MustGather>> Collecting the final netstat snapshot...
Tue Jul 19 08:09:40 UTC 2022 MustGather>> Final netstat snapshot complete.
Tue Jul 19 08:09:40 UTC 2022 MustGather>> Collecting other data.  This may take a few moments...
Tue Jul 19 08:09:40 UTC 2022 MustGather>> Collected other data.
Tue Jul 19 08:09:40 UTC 2022 MustGather>> Preparing for packaging and cleanup...
[2022-07-19 08:09:44.615477936 UTC] run.sh: waiting for script to complete
Tue Jul 19 08:09:45 UTC 2022 MustGather>> Compressing output files into linperf_RESULTS.tar.gz
netstat.out
vmstat.out
ps.out
top.out
screen.out
dmesg.out
whoami.out
df-hk.out
topdashH.82972.out
Tue Jul 19 08:09:45 UTC 2022 MustGather>> Cleaning up...
Tue Jul 19 08:09:45 UTC 2022 MustGather>> Clean up complete.
Tue Jul 19 08:09:45 UTC 2022 MustGather>> linperf.sh script complete.
[2022-07-19 08:09:45.093376999 UTC] libertydump.sh: started with  simplehighcpu-576d7ddf66-zq5gh
[2022-07-19 08:09:46.880144633 UTC] libertydump.sh: processing pod simplehighcpu-576d7ddf66-zq5gh, container POD, PID 82552
[2022-07-19 08:09:46.883207346 UTC] libertydump.sh: processing pod simplehighcpu-576d7ddf66-zq5gh, container simplehighcpu, PID 82972
[2022-07-19 08:09:50.816797789 UTC] libertydump.sh: succeeded for simplehighcpu-576d7ddf66-zq5gh with dump in /opt/ibm/wlp/output/defaultServer/defaultServer.dump-22.07.19_08.09.47.zip
[2022-07-19 08:09:50.818703989 UTC] libertydump.sh: script returning
[2022-07-19 08:09:50.822606209 UTC] podfscp.sh: started with /logs /config /output/javacore* /opt/ibm/wlp/output/defaultServer/defaultServer.dump-22.07.19_08.09.47.zip for  simplehighcpu-576d7ddf66-zq5gh
[2022-07-19 08:09:52.623411670 UTC] podfscp.sh: processing pod simplehighcpu-576d7ddf66-zq5gh, container POD
cp: cannot stat '/host//var/lib/containers/storage/overlay/e9efcecc98fe6387c44c3e9427a080d1a21267b70512c3155c8025a4ad1b0e69/merged///logs': No such file or directory
cp: cannot stat '/host//var/lib/containers/storage/overlay/e9efcecc98fe6387c44c3e9427a080d1a21267b70512c3155c8025a4ad1b0e69/merged///config': No such file or directory
sh: line 0: cd: /output: No such file or directory
[2022-07-19 08:09:52.646042556 UTC] podfscp.sh: Path /output/javacore* for pod simplehighcpu-576d7ddf66-zq5gh, container POD does not evaluate to a real path within /var/lib/containers/storage/overlay/e9efcecc98fe6387c44c3e9427a080d1a21267b70512c3155c8025a4ad1b0e69/merged
sh: line 0: cd: /opt/ibm/wlp/output/defaultServer: No such file or directory
[2022-07-19 08:09:52.652921778 UTC] podfscp.sh: Path /opt/ibm/wlp/output/defaultServer/defaultServer.dump-22.07.19_08.09.47.zip for pod simplehighcpu-576d7ddf66-zq5gh, container POD does not evaluate to a real path within /var/lib/containers/storage/overlay/e9efcecc98fe6387c44c3e9427a080d1a21267b70512c3155c8025a4ad1b0e69/merged
[2022-07-19 08:09:54.619734049 UTC] run.sh: waiting for script to complete
[2022-07-19 08:09:56.309892667 UTC] podfscp.sh: processing pod simplehighcpu-576d7ddf66-zq5gh, container simplehighcpu
[2022-07-19 08:10:00.153914675 UTC] podfscp.sh: script returning
[2022-07-19 08:10:00.156925137 UTC] podfsrm.sh: started with /output/javacore* /opt/ibm/wlp/output/defaultServer/defaultServer.dump-22.07.19_08.09.47.zip for  simplehighcpu-576d7ddf66-zq5gh
[2022-07-19 08:10:01.989042054 UTC] podfsrm.sh: processing pod simplehighcpu-576d7ddf66-zq5gh, container POD
sh: line 0: cd: /output: No such file or directory
[2022-07-19 08:10:01.994752564 UTC] podfsrm.sh: Path /output/javacore* for pod simplehighcpu-576d7ddf66-zq5gh, container POD does not evaluate to a real path within /var/lib/containers/storage/overlay/e9efcecc98fe6387c44c3e9427a080d1a21267b70512c3155c8025a4ad1b0e69/merged
sh: line 0: cd: /opt/ibm/wlp/output/defaultServer: No such file or directory
[2022-07-19 08:10:02.001437604 UTC] podfsrm.sh: Path /opt/ibm/wlp/output/defaultServer/defaultServer.dump-22.07.19_08.09.47.zip for pod simplehighcpu-576d7ddf66-zq5gh, container POD does not evaluate to a real path within /var/lib/containers/storage/overlay/e9efcecc98fe6387c44c3e9427a080d1a21267b70512c3155c8025a4ad1b0e69/merged
[2022-07-19 08:10:02.002957169 UTC] podfsrm.sh: processing pod simplehighcpu-576d7ddf66-zq5gh, container simplehighcpu
[2022-07-19 08:10:02.008267245 UTC] podfsrm.sh: Removing /host//var/lib/containers/storage/overlay/96271cd437b8f8efb413fae817e21ee0d6d9db14f3efbfbf81f935ff493fc2ab/merged//opt/ibm/wlp/output/defaultServer/javacore* for pod simplehighcpu-576d7ddf66-zq5gh
[2022-07-19 08:10:02.016665282 UTC] podfsrm.sh: Removing /host//var/lib/containers/storage/overlay/96271cd437b8f8efb413fae817e21ee0d6d9db14f3efbfbf81f935ff493fc2ab/merged//opt/ibm/wlp/output/defaultServer/defaultServer.dump-22.07.19_08.09.47.zip for pod simplehighcpu-576d7ddf66-zq5gh
[2022-07-19 08:10:02.018699213 UTC] podfsrm.sh: script returning
[2022-07-19 08:10:04.623130305 UTC] run.sh: command completed.
[2022-07-19 08:10:04.625138126 UTC] run.sh: gathering second set of system info.
[2022-07-19 08:10:09.317020769 UTC] run.sh: All data gathering complete.
[2022-07-19 08:10:09.319403714 UTC] run.sh: Packaging for download.
[2022-07-19 08:10:10.023396376 UTC] run.sh: Finished with output in /tmp/containerdiag.ey7pWCcrlu.tar.gz
[2022-07-19 08:10:10.025425607 UTC] run.sh: Debug pod is worker0xiphoidcpfyreibmcom-debug in namespace defaulte
-rw-r--r--. 1 root root 4.7M Jul 19 08:10 /tmp/containerdiag.ey7pWCcrlu.tar.gz
[2022-07-19 08:10:10.029983624 UTC] run.sh: Files are ready for download. Download with the following command in another window:

  oc cp worker0xiphoidcpfyreibmcom-debug:/tmp/containerdiag.ey7pWCcrlu.tar.gz containerdiag.ey7pWCcrlu.tar.gz --namespace=defaulte

After the download is complete, type OK and press ENTER: OK
[2022-07-19 08:11:47.373293225 UTC] run.sh: Processing finished. Deleting /tmp/containerdiag.ey7pWCcrlu.tar.gz
[2022-07-19 08:11:47.376852752 UTC] run.sh: finished.

 It seems like your debug pod idle timeout is 10 seconds. Do you know if you customized that as part of security hardening or something? I'm wondering if I should change the default output delay to less than 10 seconds instead of the current 30 seconds to avoid the issue you saw. The output delay must be less than the idle timeout.

@kgibm I just deployed the OCP cluster and haven't changed the setting purposefully. Actually I'm not sure what "debug pod idle timeout" is..

Interesting, ok. Here's backgroun don the debug node pod idle timeout:
You may see some output repeated such as the "run.sh: waiting for script to complete" and "Files are ready for download" lines. This is expected. The reason is that oc debug may time out after 1 minute of no input or output and if you haven't downloaded the files by then, the pod would have been deleted and the files would be gone; therefore, we periodically output some content so that the pod is not destroyed until you've completed the download. Newer versions of oc debug have a longer timeout.
Although this will make the output much more chatty, I think I will change the default to 8 seconds to avoid this problem.

@e30532 I've updated the latest tag to use an 8 second timeout. Please try again with the default options to see if it works:
./containerdiag.sh -d simplehighcpu libertyperf.sh

@kgibm it also worked!