We have also had the same problem @hyksos describes, in production.

Support for --pids-limit would be appreciated.

Currently, we approximate --pids-limit by using a scheduled job to set per-task limits, i.e. something like:

1. Mount pids cgroup in /etc/cgconfig.conf
2. yum install libcgroup-tools && systemctl cgconfig enable # amzlinux2
3. Schedule:

LIMIT=8192
# amzlinux1
if [ -d /cgroup/pids/ecs ]; then find /cgroup/pids/ecs -mindepth 3 -maxdepth 3 -type f -name pids.max -exec sh -c "echo ${LIMIT} > {}" \; ; fi
# amzlinux2
if [ -d /sys/fs/cgroup/pids/ecs ]; then find /sys/fs/cgroup/pids/ecs -mindepth 3 -maxdepth 3 -type f -name pids.max -exec sh -c "echo ${LIMIT} > {}" \; ; fi

No special use case required to be needing this except a mixed ECS cluster. One container can fork bomb the entire host, I'm looking at you JAVA containers... At which point everything is degraded and with, most of the time, very tangential or seemingly unrelated error messages because the kernel being at max_pids is not something that leads to very clear error messages at the top of the stack.

We have hit this multiple time in production and the only work around we have so far is to set the host max_pids at 4M and hope we don't run out of something else during a fork bomb. That's when system's guys start to miss the isolation of a VM/hypervisor :) Jokes aside, it would be useful to surface this in the task definition.

The csi driver worked fine for me on EKS, which is better than flexvolume imo. At least the csi-smb driver worked, which solved my issue.

David Berkman

From: JiaDe WU [email protected] Sent: Monday, January 18, 2021 11:44:27 PM To: aws/containers-roadmap [email protected] Cc: David Berkman [email protected]; Comment [email protected] Subject: Re: [aws/containers-roadmap] Is there a way to support FlexVolume plugin in EKS? (#925)

Is there any update on this issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/aws/containers-roadmap/issues/925#issuecomment-762662707, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AACMYJF6M7CJOJNKKMAOYYDS2UZ5XANCNFSM4NOSW2TA.

Codecov Report

Merging #3424 (d5dc4b8) into master (be94581) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3424   +/-   ##
=======================================
  Coverage   90.84%   90.84%           
=======================================
  Files         258      258           
  Lines       18287    18287           
=======================================
  Hits        16612    16612           
  Misses       1675     1675           

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 be94581...d5dc4b8. Read the comment docs.

…8-2004-sdk as well as at runtime

• [ ] Have you followed the guidelines for contributing?
• [ ] Have you signed the CLA?
• [ ] Have you successfully run ./runtests.sh static?
• [ ] Have you successfully run ./runtests.sh tests/unit?

this is done now

• [ ] Have you followed the guidelines for contributing?
• [ ] Have you signed the CLA?
• [ ] Have you successfully run ./runtests.sh static?
• [ ] Have you successfully run ./runtests.sh tests/unit?

Given CI keeps randomly failing, so this couldn't be merged, I've now added the URL, too.

This reverts commit 847cd3cd4fa9c7e67231816a84c45bf3070fbef2.

• [ ] Have you followed the guidelines for contributing?
• [ ] Have you signed the CLA?
• [ ] Have you successfully run ./runtests.sh static?
• [ ] Have you successfully run ./runtests.sh tests/unit?

+1

Codecov Report

Merging #3422 (b5498e2) into master (e8e5d28) will decrease coverage by 0.00%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #3422      +/-   ##
==========================================
- Coverage   90.84%   90.84%   -0.01%     
==========================================
  Files         258      258              
  Lines       18288    18287       -1     
==========================================
- Hits        16614    16612       -2     
- Misses       1674     1675       +1     

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 e8e5d28...b5498e2. Read the comment docs.

Update go-udev package with upstream; the project isn't very active and in fact there are just 3 commits since we imported it into osutil, but they just fixed https://github.com/pilebones/go-udev/issues/3 which is good too have.

Updated with:

git subtree pull --prefix=osutil/udev http://github.com/pilebones/go-udev master

This reverts commit 847cd3cd4fa9c7e67231816a84c45bf3070fbef2.

• [ ] Have you followed the guidelines for contributing?
• [ ] Have you signed the CLA?
• [ ] Have you successfully run ./runtests.sh static?
• [ ] Have you successfully run ./runtests.sh tests/unit?

Ensure pulse libs can be found during linking and set ACLOCAL_PATH to include build snap paths

• [x] Have you followed the guidelines for contributing?
• [x] Have you signed the CLA?
• [x] Have you successfully run ./runtests.sh static?
• [x] Have you successfully run ./runtests.sh tests/unit?

They intermittently fail and these failures do not appear to be Snapcraft-specific. Until the issue is resolved, set the tasks to manual.

Failure log:

python3 manage.py validate
error: ???: Cannot load '/snapcraft/tests/spread/plugins/v1/plainbox/snaps/provider-with-deps/parts/parent-plainbox-provider/build/units/parent.pxu': (chardet 4.0.0 (/snapcraft/tests/spread/plugins/v1/plainbox/snaps/provider-with-deps/stage/lib/python3.6/site-packages), Requirement.parse('chardet<3.1.0,>=3.0.2'), {'requests'})
NOTE: subsequent units from problematic files are ignored
Validation of provider plainbox-provider-parent has failed

Signed-off-by: Chris Patterson [email protected]

• [ ] Have you followed the guidelines for contributing?
• [ ] Have you signed the CLA?
• [ ] Have you successfully run ./runtests.sh static?
• [ ] Have you successfully run ./runtests.sh tests/unit?

Ah, ok, thanks for pointing this out.

@forsaken628 use bbolt 1.3.5.

my naive thinking was to just have:

if len(modes) != 0 {
    return false
}

on this path where Device.Mode == ""

how do we handle the implication of core20+ here? do we want to hard-code a block list of core and core18, and assume all other base snaps are core20+ like we did previously?

This includes a log analyzer and the new step in the actions to read the log. Then the idea would be to re-execute the failed tests.

This is addressed in #9851 , I'll update this PR when 9851 lands.

The detection and handling of duplicated snapshot and returning the id of the original snapshot has a subtle bug, it doesn't return affected snap names correctly. This wasn't noticed because unit test wasn't good enough, and on the outside (snapshotstate.go line 341) it looked like it did return snap names. This PR fixes this.

Just a possibility to copy a file from s3 to the container, like with COPY command in Dockerfile.

That would change the hash of the container image which is perhaps not desirable ... I believe mounting would be ideal in this context.

sorry yes this was confusing, let me adjust and force-push a better commit message

AFAICT you do not need to update anything in the profile at this point.

Cool. So that means my PR is "ready", unless someone else have any input to provide ?