port 80

Alice start a http server in port 80, Bob want to do same... What happens?

Reverse proxy should

[ ] redirect to users servers based on request username or path
[ ] register domains requested by that users to be redirected (vhost)
[ ] maybe overwrite http module so redirection of ports can be transparent (.listen() method)

Reverse proxy could use http auth with credentials from logon, and only accept https and secure websockets (wss) since it doesn't makes sense to request some credentials and later transfer the data in raw...

wasnt the reverse proxy created? Closing, but re-open if I'm in error

@piranna is that automated or are you just watching to see every time I close a thread? :P

Reverse proxy is working correctly and integrated, but it's only focused for HTTP and WebSockets. This issue is more related to discuss what to do with other incoming ports. One solution would be to don't accept them and only allow incomming petitions for HTTP and WebSockets since they can be easily identified, and maybe allow any other protocol that has an easy support for a reverse proxy in some way that don't involve NAT or similar techniques, but this would restrict us to only allow high-level protocols...

@piranna I suggest we leave the other ports as "fend for yourself" ports. We enable a reverse proxy for as many protocols as we can, but for those that we can't we leave the default functionality. Whoever gets there first, gets the port. As stated above:

Alice start a http server in port 80, Bob want to do same... What happens?

bob can't?

If it isn't on a reverse proxy, bob can't. Everyone with a reverse proxy deals with this issue already so we can see it more as adding a bonus in creating the reverse proxy, than it is losing out not passing the other ports through a proxy.

Here I find three situations:

priviledged ports (< 1024), only root user (UID 0) can open them, reverse proxy should manage them someway if it makes sense (telnet, ssh...), but how? Just ignore them and suggest/force people to use other alternatives (mainly HTTP and WebSockets)?
regular ports (>= 1024), i find ok the first come first serve approach here
regular ports with easy support for reverse proxy, this ones could/should be managed as it's currently done with HTTP/WebSockets, but don't know of any other protocol that has this functionality

We should take in account the fact that I had in mind the reverse proxy to be able to register some servers for some particular domains that's currently not implemented (don't know if to use a UNIX socket or something similar so clients can send the register requests), maybe something similar would be done with the priviledged ports, but in this case it would more transparent if it would be automatically done by piggybacking the net buildin module... I think external node_modules have priority over the build-in ones, so we could add it in the initramfs, but I don't like to add too much things there... Or could it be just enought to request devs to explicitly use a custom version of it?

priviledged ports (< 1024), only root user (UID 0) can open them, reverse proxy should manage them someway if it makes sense (telnet, ssh...), but how? Just ignore them and suggest/force people to use other alternatives (mainly HTTP and WebSockets)?

If you create a manager they could simply be ignored, yes.

I think external node_modules have priority over the build-in ones, so we could add it in the initramfs

We're officially exiting my realm of knowledge :P

Or could it be just enought to request devs to explicitly use a custom version of it?

What do you mean by this? How would this work?

priviledged ports (< 1024), only root user (UID 0) can open them,
reverse proxy should manage them someway if it makes sense (telnet,
ssh...), but how? Just ignore them and suggest/force people to use other
alternatives (mainly HTTP and WebSockets)?

If you create a manager they could simply be ignored, yes.

Working on ;-)

I think external node_modules have priority over the build-in ones, so
we could add it in the initramfs

We're officially exiting my realm of knowledge :P

Or could it be just enought to request devs to explicitly use a custom
version of it?

What do you mean by this? How would this work?

I have check the docs and build-ins have the highest priority, so only
solution is devs will need to explicitly require a module to use
priviledged ports :-(

I have upgraded nodeos-reverse-proxy to accept registration of domains for HTTP and WebSocket connections and to proxy registered ports. This needs on the client the usage of the module nodeos-reverse-proxy-register, that transparently piggy-back on top of the Node.js build-in dgram and net modules to register ports listening, and export a register() and unregister() functions to allow registration of domains. Communications with nodeos-reverse-proxy are done using POST requests to the urls http://<IP_ADDRESS>/_register and http://<IP_ADDRESS>/_unregister respectively, that later are filtered by nodeos-reverse-proxy to only allow requests from the local own machine. Clossing.


Split dracut default config to a separate package

So users doesn't have to create a default dracut configuration file
unless they really need to.
Blocked by #489
Signed-off-by: Ettore Di Giacinto<EMAIL_ADDRESS>

Superseded by #495


Added Github Actions build workflow

Is blocked by #12 (this PR is based on the main() branch)
Added a Github Action which builds the project on Ubuntus of different versions with GCC and Cuda of different versions

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 4

See the complete overview on Codacy


Used to open PHP files but shows source code now

Hi,
View in browser (my favorite plugin!)  used to open my PHP web pages without a problem (in Chrome) but instead it shows the source code of the page. Changing the extension name in HTML solves the problem, but is a bit annoying.
Regards,
David

php code cannot be run directly


commands: Reduce memory allocations in ZAdd

When adding lots of data in Redis, the allocations in ZAdd can put quite some pressure on the GC... Using the benchmark in https://gist.github.com/abustany/8f2cf2ee3b968020b75e , I get the following results:
benchmark              old ns/op     new ns/op     delta
BenchmarkRedisZAdd     22371         21779         -2.65%

benchmark              old allocs     new allocs     delta
BenchmarkRedisZAdd     10             9              -10.00%

benchmark              old bytes     new bytes     delta
BenchmarkRedisZAdd     373           343           -8.04%

There are probably a couple of places in the library where we could use a sync.Pool, for example for the commands, to reduce GC pressure, but that'd be the subject of another pull request...

Looks good, but please add benchmark from https://gist.github.com/abustany/8f2cf2ee3b968020b75e to the redis_test.go file.

Thanks. I rebased your changes and created new PR https://github.com/go-redis/redis/pull/108. Closing this one.


[Bug]: Alpine ProtocolError after Chrome 123.0.6312.86 Update

Minimal, reproducible example
const options = [
    '--disable-background-networking',
    '--disable-background-timer-throttling',
    '--disable-backgrounding-occluded-windows',
    '--disable-breakpad',
    '--disable-client-side-phishing-detection',
    '--disable-component-update',
    '--disable-default-apps',
    '--disable-dev-shm-usage',
    '--disable-domain-reliability',
    '--disable-extensions',
    '--disable-features=AudioServiceOutOfProcess',
    '--disable-hang-monitor',
    '--disable-ipc-flooding-protection',
    '--disable-notifications',
    '--disable-offer-store-unmasked-wallet-cards',
    '--disable-popup-blocking',
    '--disable-print-preview',
    '--disable-prompt-on-repost',
    '--disable-renderer-backgrounding',
    '--disable-setuid-sandbox',
    '--disable-speech-api',
    '--disable-sync',
    '--disk-cache-size=33554432',
    // '--hide-scrollbars',
    // '--ignore-gpu-blacklist',
    // '--metrics-recording-only',
    '--mute-audio',
    '--no-default-browser-check',
    '--no-first-run',
    '--no-pings',
    '--no-sandbox',
    '--no-zygote',
    '--password-store=basic',
    '--use-gl=swiftshader',
    '--use-mock-keychain',
    '--single-process',
    '--autoplay-policy=no-user-gesture-required',
    // '--enable-logging=stderr',
    // '--v=1',
    // '--disable-gpu',
    //   '--window-size=400,800',
];
const pup = await  puppeteer.launch({
        executablePath: globalEnv.puppeteerExecutablePath,
        userDataDir: "/tmp",
        args: options,
        ignoreHTTPSErrors: true,
        ignoreDefaultArgs: ["--mute-audio"],
        timeout: 5000,
   });

const page = await pup.newPage(...

Error string
ProtocolError: Network.enable timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.
Bug behavior

[ ] Flaky
[ ] PDF

Background
I have simple container that downloads and builds puppeteer on Alpine and following is the container source.
RUN apk add --no-cache \
      chromium \
      nss \
      freetype \
      harfbuzz \
      ca-certificates \
      ttf-freefont

ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser

RUN addgroup -S pptruser && adduser -S -G pptruser pptruser \
    && mkdir -p /home/pptruser/Downloads /app \
    && chown -R pptruser:pptruser /home/pptruser \
    && chown -R pptruser:pptruser /app

RUN npm install puppeteer

This was working file till 20th March 2024, this is as far as I could go back, what it means that prior to 20th March 2024, the chromium version on alpine was running correctly.
Expectation
Puppeteer should work with Chromium 123.0.6312.86-r0 on Alpine, https://pkgs.alpinelinux.org/package/edge/community/x86_64/chromium ,
Container image prior to this version was working correctly, I don't know how to manually install previous chromium version on alpine to backtrack, if someone can help, I can backtrack old chromium version and get working version.
Reality
The last build of latest chromium was published on 27th March. And puppeteer does not connect to launched instance.
I can confirm that the instance launches process correctly, chromium process starts in headless mode but the node script hungs up till 180 seconds and throws following error.
ProtocolError: Network.enable timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.
2024-04-02 11:37:24     at Callback.<instance_members_initializer> (/app/node_modules/puppeteer-core/src/common/CallbackRegistry.ts:114:12)
2024-04-02 11:37:24     at Callback (/app/node_modules/puppeteer-core/src/common/CallbackRegistry.ts:119:3)
2024-04-02 11:37:24     at CallbackRegistry.create (/app/node_modules/puppeteer-core/src/common/CallbackRegistry.ts:27:22)
2024-04-02 11:37:24     at Connection._rawSend (/app/node_modules/puppeteer-core/src/cdp/Connection.ts:120:22)
2024-04-02 11:37:24     at CdpCDPSession.send (/app/node_modules/puppeteer-core/src/cdp/CDPSession.ts:95:29)
2024-04-02 11:37:24     at NetworkManager.addClient (/app/node_modules/puppeteer-core/src/cdp/NetworkManager.ts:124:14)
2024-04-02 11:37:24     at FrameManager.initialize (/app/node_modules/puppeteer-core/src/cdp/FrameManager.ts:217:30)
2024-04-02 11:37:24     at CdpPage.#initialize (/app/node_modules/puppeteer-core/src/cdp/Page.ts:375:28)
2024-04-02 11:37:24     at Function._create (/app/node_modules/puppeteer-core/src/cdp/Page.ts:106:27)
2024-04-02 11:37:24     at <anonymous> (/app/node_modules/puppeteer-core/src/cdp/Target.ts:249:24)

Puppeteer configuration file (if used)
No response
Puppeteer version
22.6.1
Node version
20
Package manager
npm
Package manager version
Latest
Operating system
Linux

Consider using the official Docker image we provide (it is not based on Alpine though and uses Chrome for Testing) https://github.com/puppeteer/puppeteer/pkgs/container/puppeteer Note that Alpine Chromium builds are not maintained by us, so please consider reaching out to the build maintainer or filing an issue for Chromium at crbug.com.

Same issue with

<EMAIL_ADDRESS>(available in docker image node:lts-alpine3.19)
<EMAIL_ADDRESS>

Try using dumpio: true to see logs from chromium. Perhaps something is missing in the Alpine image for this version.

Recurring log messages are:
[488:614:0402/093043.145357:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
[488:614:0402/093043.145370:ERROR:gpu_channel_manager.cc(957)] Failed to create GLES3 context, fallback to GLES2.
[488:614:0402/093043.145378:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
[488:614:0402/093043.145391:ERROR:gpu_channel_manager.cc(968)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
[488:614:0402/093043.145397:ERROR:shared_image_stub.cc(728)] SharedImageStub: unable to create context
[488:614:0402/093043.145405:ERROR:gpu_channel.cc(767)] GpuChannel: Failed to create SharedImageStub
[488:614:0402/093043.145573:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!

@ackava you should not use the channel as it will pick-up with wrong binary: instead you shoud let Puppeteer to launch the bundled instance.

@OrKoN I changed index.js to use bundled google-chrome-stable.
Here is the error..
2024-04-02 15:15:15 [45:144:0402/094515.283495:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
2024-04-02 15:15:15 [45:144:0402/094515.283711:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
2024-04-02 15:15:15 [45:144:0402/094515.283751:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
2024-04-02 15:15:15 [45:144:0402/094515.283770:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory

the stable is not the bundled version (Puppeteer bundles Chrome for Testing version as per https://pptr.dev/chromium-support), it is installed there to make sure all chrome dependencies are installed as well.
The following works for me:
FROM ghcr.io/puppeteer/puppeteer:22.6.2

COPY index.mjs .

ENTRYPOINT [ "node", "index.mjs" ]

import puppeteer from "puppeteer";

const p = await puppeteer.launch();

const page = await p.newPage();
console.log(await p.version())
await page.setContent(`<div><span>A</span></div>`);
await page.screenshot({
    path: "a.png"
});
await p.close();

Outputs Chrome/123.0.6312.86.

The command docker run --init --rm -it localhost/pptr:latest (note the --init flag, it might be important). Could you please try this out and let me know if it works for you?

@OrKoN Yes I was able to get working with your example, but same on alpine doesn't work.
Does Following log indicate that sbus is now mandetory for puppeteer? Because the official puppeteer troubleshooting for alpine doesn't mention this.
2024-04-02 15:44:54 [31:46:0402/101454.945658:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 15:44:54 [31:49:0402/101454.947206:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 15:44:54 [31:49:0402/101454.947294:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 15:44:54 [31:46:0402/101454.950821:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
2024-04-02 15:44:54 [31:46:0402/101454.950900:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
2024-04-02 15:44:54 [31:46:0402/101454.950915:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
2024-04-02 15:44:54 [31:46:0402/101454.950925:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")

@OrKoN
dbus error also shows up in your example, so dbus isn't the issue.
The real issue is DevTools not opening. In your example, I can clearly see DevTools listening on ws://<IP_ADDRESS>:38959/devtools/browser/ea80ae08-434d-4686-a471-3311eae1e26d in dump io.
But this one isn't starting on alpine, which means that parameters sent to chromium executable are not configured correctly.
Is there anyway I can see what parameters are passed to executable?

@OrKoN dbus errors show up even in your example so I believe dbus isn't the issue. I have collected following log and can you identify if anything is missing in configuration?
2024-04-02 22:24:01 [30:46:0402/165401.028711:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 22:24:01 [30:49:0402/165401.034760:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 22:24:01 [30:49:0402/165401.034955:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 22:24:01 [30:46:0402/165401.043442:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
2024-04-02 22:24:01 [30:46:0402/165401.043828:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
2024-04-02 22:24:01 [30:46:0402/165401.043881:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
2024-04-02 22:24:01 [30:46:0402/165401.044058:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
2024-04-02 22:24:01 [30:30:0402/165401.086290:ERROR:system_network_context_manager.cc(883)] Cannot use V8 Proxy resolver in single process mode.
2024-04-02 22:24:01 [30:30:0402/165401.087874:ERROR:policy_logger.cc(157)] :components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc(161) Cloud management controller initialization aborted as CBCM is not enabled. Please use the `--enable-chrome-browser-cloud-management` command line flag to enable it if you are not using the official Google Chrome build.
2024-04-02 22:24:01 [30:53:0402/165401.087909:ERROR:angle_platform_impl.cc(44)] RendererVk.cpp:203 (VerifyExtensionsPresent): Extension not supported: VK_KHR_surface
2024-04-02 22:24:01 ERR: RendererVk.cpp:203 (VerifyExtensionsPresent): Extension not supported: VK_KHR_surface
2024-04-02 22:24:01 [30:53:0402/165401.087972:ERROR:angle_platform_impl.cc(44)] RendererVk.cpp:203 (VerifyExtensionsPresent): Extension not supported: VK_KHR_xcb_surface
2024-04-02 22:24:01 ERR: RendererVk.cpp:203 (VerifyExtensionsPresent): Extension not supported: VK_KHR_xcb_surface
2024-04-02 22:24:01 [30:53:0402/165401.088310:ERROR:angle_platform_impl.cc(44)] Display.cpp:1070 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-7): A requested extension is not supported, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, enableInstanceExtensions:1715.
2024-04-02 22:24:01 ERR: Display.cpp:1070 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-7): A requested extension is not supported, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, enableInstanceExtensions:1715.
2024-04-02 22:24:01 [30:53:0402/165401.088487:ERROR:gl_display.cc(515)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-7): A requested extension is not supported, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, enableInstanceExtensions:1715.
2024-04-02 22:24:01 [30:53:0402/165401.088521:ERROR:gl_display.cc(786)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED
2024-04-02 22:24:01 [30:53:0402/165401.088554:ERROR:gl_display.cc(820)] Initialization of all EGL display types failed.
2024-04-02 22:24:01 [30:53:0402/165401.088585:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
2024-04-02 22:24:01 [30:53:0402/165401.092645:ERROR:angle_platform_impl.cc(44)] RendererVk.cpp:203 (VerifyExtensionsPresent): Extension not supported: VK_KHR_surface
2024-04-02 22:24:01 ERR: RendererVk.cpp:203 (VerifyExtensionsPresent): Extension not supported: VK_KHR_surface
2024-04-02 22:24:01 [30:53:0402/165401.092759:ERROR:angle_platform_impl.cc(44)] RendererVk.cpp:203 (VerifyExtensionsPresent): Extension not supported: VK_KHR_xcb_surface
2024-04-02 22:24:01 ERR: RendererVk.cpp:203 (VerifyExtensionsPresent): Extension not supported: VK_KHR_xcb_surface
2024-04-02 22:24:01 [30:53:0402/165401.092822:ERROR:angle_platform_impl.cc(44)] Display.cpp:1070 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-7): A requested extension is not supported, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, enableInstanceExtensions:1715.
2024-04-02 22:24:01 ERR: Display.cpp:1070 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-7): A requested extension is not supported, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, enableInstanceExtensions:1715.
2024-04-02 22:24:01 [30:53:0402/165401.092871:ERROR:gl_display.cc(515)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-7): A requested extension is not supported, in ../../third_party/angle/src/libANGLE/renderer/vulkan/RendererVk.cpp, enableInstanceExtensions:1715.
2024-04-02 22:24:01 [30:53:0402/165401.092950:ERROR:gl_display.cc(786)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED
2024-04-02 22:24:01 [30:53:0402/165401.093013:ERROR:gl_display.cc(820)] Initialization of all EGL display types failed.
2024-04-02 22:24:01 [30:53:0402/165401.093041:ERROR:gl_ozone_egl.cc(26)] GLDisplayEGL::Initialize failed.
2024-04-02 22:24:01 [30:46:0402/165401.133192:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
2024-04-02 22:24:01 [30:46:0402/165401.133296:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
2024-04-02 22:24:01 [30:30:0402/165401.135881:ERROR:system_network_context_manager.cc(883)] Cannot use V8 Proxy resolver in single process mode.
2024-04-02 22:24:01 [30:30:0402/165401.160246:ERROR:system_network_context_manager.cc(883)] Cannot use V8 Proxy resolver in single process mode.
2024-04-02 22:24:01
2024-04-02 22:24:01 DevTools listening on ws://<IP_ADDRESS>:44063/devtools/browser/cff6671d-df71-4fdf-88be-07c8dd9533a4
2024-04-02 22:24:01 [30:73:0402/165401.952807:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 22:24:01 [30:73:0402/165401.952967:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 22:24:01 [30:73:0402/165401.953459:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 22:24:01 [30:73:0402/165401.953591:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 22:24:01 [30:73:0402/165401.953699:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
2024-04-02 22:24:02 [0402/165402.077263:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.077964:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.078376:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.078896:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.090985:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.091392:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.092000:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.092518:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.092763:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.093094:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.093522:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.093838:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.094307:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.098551:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.109946:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.110302:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.110570:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.110915:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.111254:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.111494:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.111723:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.111984:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.112211:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.112491:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.122055:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.122539:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.122827:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.123081:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.141891:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.142318:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.142650:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.147506:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.147840:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.148523:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.148899:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.149171:WARNING:process_reader_linux.cc(95)] sched_getscheduler: Function not implemented (38)
2024-04-02 22:24:02 [0402/165402.155827:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
2024-04-02 22:24:02 [0402/165402.155909:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
2024-04-02 22:24:02 [30:53:0402/165402.024118:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.204246:ERROR:gpu_channel_manager.cc(957)] Failed to create GLES3 context, fallback to GLES2.
2024-04-02 22:24:02 [30:53:0402/165402.204282:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.204319:ERROR:gpu_channel_manager.cc(968)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
2024-04-02 22:24:02 [30:53:0402/165402.204344:ERROR:shared_image_stub.cc(728)] SharedImageStub: unable to create context
2024-04-02 22:24:02 [30:53:0402/165402.204440:ERROR:gpu_channel.cc(767)] GpuChannel: Failed to create SharedImageStub
2024-04-02 22:24:02 [30:53:0402/165402.204631:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.204670:ERROR:gpu_channel_manager.cc(957)] Failed to create GLES3 context, fallback to GLES2.
2024-04-02 22:24:02 [30:53:0402/165402.204691:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.204720:ERROR:gpu_channel_manager.cc(968)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
2024-04-02 22:24:02 [30:53:0402/165402.204740:ERROR:shared_image_stub.cc(728)] SharedImageStub: unable to create context
2024-04-02 22:24:02 [30:53:0402/165402.204766:ERROR:gpu_channel.cc(767)] GpuChannel: Failed to create SharedImageStub
2024-04-02 22:24:02 [30:53:0402/165402.221064:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.221123:ERROR:gpu_channel_manager.cc(957)] Failed to create GLES3 context, fallback to GLES2.
2024-04-02 22:24:02 [30:53:0402/165402.221148:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.221189:ERROR:gpu_channel_manager.cc(968)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
2024-04-02 22:24:02 [30:53:0402/165402.221214:ERROR:shared_image_stub.cc(728)] SharedImageStub: unable to create context
2024-04-02 22:24:02 [30:53:0402/165402.221247:ERROR:gpu_channel.cc(767)] GpuChannel: Failed to create SharedImageStub
2024-04-02 22:24:02 [30:53:0402/165402.221391:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.221706:ERROR:gpu_channel_manager.cc(957)] Failed to create GLES3 context, fallback to GLES2.
2024-04-02 22:24:02 [30:53:0402/165402.221735:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.221776:ERROR:gpu_channel_manager.cc(968)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
2024-04-02 22:24:02 [30:53:0402/165402.221789:ERROR:shared_image_stub.cc(728)] SharedImageStub: unable to create context
2024-04-02 22:24:02 [30:53:0402/165402.221805:ERROR:gpu_channel.cc(767)] GpuChannel: Failed to create SharedImageStub
2024-04-02 22:24:02 [30:53:0402/165402.222063:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.222106:ERROR:gpu_channel_manager.cc(957)] Failed to create GLES3 context, fallback to GLES2.
2024-04-02 22:24:02 [30:53:0402/165402.222130:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.222168:ERROR:gpu_channel_manager.cc(968)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.
2024-04-02 22:24:02 [30:53:0402/165402.222195:ERROR:shared_image_stub.cc(728)] SharedImageStub: unable to create context
2024-04-02 22:24:02 [30:53:0402/165402.222219:ERROR:gpu_channel.cc(767)] GpuChannel: Failed to create SharedImageStub
2024-04-02 22:24:02 [30:53:0402/165402.240529:ERROR:check.cc(365)] Check failed: false. NOTREACHED log messages are omitted in official builds. Sorry!
2024-04-02 22:24:02 [30:53:0402/165402.240593:ERROR:gpu_channel_manager.cc(957)] Failed to create GLES3 context, fallback to GLES2.

Hm, not sure, nothing particularly stands out, but perhaps do not run in the --single-process mode and try with --disable-gpu? maybe some graphics dependencies are required now?

@OrKoN
Thank you for your help, the culprit was --single-process, as far as I know, --single-process was mandatory on AWS Lambda Images.
I haven't tested this on other distro but if single process is an issue on the recent chrome build then where shall I post this information? It would be useful for lot of people.

@ackava do you know where the --single-process flag was recommended? I don't think we recommend it in Puppeteer docs. If you could open a PR to update https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#running-on-alpine with a note about it it, it would be great.

We have seen success in preventing this on alpine 3.20 by adding a --disable-gpu flag into the launch args, e.g.

(async () => {
  const puppeteer = require("puppeteer");
  // Launch the browser and open a new blank page
  const browser = await puppeteer.launch({args:['--no-sandbox']});
  const page = await browser.newPage();
  const version = await page.browser().version();
  console.log("page browser version: " + version);
  await page.goto('https://bbc.co.uk/news');

  console.log("Page title: " + await page.title());

  await browser.close();
})();

Will time out and fail with ProtocolError: Network.enable timed out
Whereas, adding the flag, e.g.

(async () => {
  const puppeteer = require("puppeteer");
  // Launch the browser and open a new blank page
  const browser = await puppeteer.launch({args:['--no-sandbox --disable-gpu']});
  const page = await browser.newPage();
  const version = await page.browser().version();
  console.log("page browser version: " + version);
  await page.goto('https://bbc.co.uk/news');

  console.log("Page title: " + await page.title());

  const element = await page.waitForSelector('h1')
  let value = await element.evaluate(el => el.textContent)
  console.log('h1 = ' + value);

  await browser.close();
})();

Outputs the expected results, we are currently assuming that chromium updated something GPU related in 127+ but are too busy trying test the fix!

We have seen success in preventing this on alpine 3.20 by adding a --disable-gpu flag into the launch args, e.g.
(async () => {
  const puppeteer = require("puppeteer");
  // Launch the browser and open a new blank page
  const browser = await puppeteer.launch({args:['--no-sandbox']});
  const page = await browser.newPage();
  const version = await page.browser().version();
  console.log("page browser version: " + version);
  await page.goto('https://bbc.co.uk/news');

  console.log("Page title: " + await page.title());

  await browser.close();
})();

Will time out and fail with ProtocolError: Network.enable timed out
Whereas, adding the flag, e.g.
(async () => {
  const puppeteer = require("puppeteer");
  // Launch the browser and open a new blank page
  const browser = await puppeteer.launch({args:['--no-sandbox --disable-gpu']});
  const page = await browser.newPage();
  const version = await page.browser().version();
  console.log("page browser version: " + version);
  await page.goto('https://bbc.co.uk/news');

  console.log("Page title: " + await page.title());

  const element = await page.waitForSelector('h1')
  let value = await element.evaluate(el => el.textContent)
  console.log('h1 = ' + value);

  await browser.close();
})();

Outputs the expected results, we are currently assuming that chromium updated something GPU related in 127+ but are too busy trying test the fix!

Yup this works for me. thanks!

I can confirm that --disable-gpu seems to do the trick on Alpine Linux. Without it, the chromium will simply stay there, looking at your face, but will never navigate to an URL. You will see a message saying it is being controlled by automated test software, but the tab will stay on about:blank forever.


[8.x] Update Container.php

Just DRY!

Unfortunately these are breaking changes. Please send to master.


Memory issue with code base of Feb24

Hi,
I just ran Nginx+ with the code base of Feb24 on my backup machine. It just listen on port 80 for one IP and not in production. Now my monitoring system told me about full memory and indeed, all my 64GB RAM were gone and nginx restarted itself:
2017/03/02 14:29:49 [notice] 738#738: signal 17 (SIGCHLD) received
2017/03/02 14:29:49 [alert] 738#738: worker process 22623 exited on signal 9
2017/03/02 14:29:49 [notice] 738#738: start worker process 26684
2017/03/02 14:29:49 [notice] 738#738: signal 29 (SIGIO) received
2017/03/02 14:29:49 [notice] 738#738: signal 17 (SIGCHLD) received
2017/03/02 14:29:49 [alert] 738#738: worker process 22624 exited on signal 9
2017/03/02 14:29:49 [alert] 738#738: worker process 22625 exited on signal 9
2017/03/02 14:29:49 [alert] 738#738: worker process 22627 exited on signal 9
2017/03/02 14:29:49 [notice] 738#738: start worker process 26685
2017/03/02 14:29:49 [notice] 738#738: start worker process 26686
2017/03/02 14:29:49 [notice] 738#738: start worker process 26687
2017/03/02 14:29:49 [notice] 738#738: signal 29 (SIGIO) received
2017/03/02 14:29:51 [notice] 738#738: signal 17 (SIGCHLD) received
2017/03/02 14:29:51 [alert] 738#738: worker process 22643 exited on signal 9
2017/03/02 14:29:51 [notice] 738#738: start worker process 26688
2017/03/02 14:29:51 [notice] 738#738: signal 29 (SIGIO) received
I grabbed the logs of nginx but the last connect was at 11:39:02.
I had the same issue two days ago after benchmarking with "ab". I thought this was the cause so I restarted nginx, did a benchmark again and waited. Now after two days I have the same memory error again.
Sadly I cannot reproduce it.
Someone running the same code base and seeing this issue?

@defanator do you have a test machine where you can run nginx over some days and monitor the memory? Recently the memory of my standby machine filled up again and nginx restarted itself

@mimugmail, first, nginx never "restarts itself" (perhaps it was OOM killer?)
Second - sure, I can set up an instance and leave it running for a few days, but it would be good to have more precise instructions on steps how to reproduce the scenario (system configuration, nginx configuration, any load patterns).
Finally, what makes you think that the reason is is nginx?

Hm, you're right. I started a second machine with a mostly empty config and just CRS3 rules.
When it occurs there too I'll disable MS3 and wait again.
Will keep you updated ..

Ok, first results:
With code base of 24th, nginx 1.11.9 and a really basic nginx configuration there's no issue.
On the other side is a the same system (OS Debian 8) but with N+, so module is compiled against 1.11.5 and the configuration is quite huge (multile balancers with plenty of stages and around 30 virtual hosts). Last day I just killed the nginx process and didn't start it again. Now the memory blowouts are gone. Next step is to just disable modsecurity on the virtual hosts, but since the config is synced regulary from the master I have to check with my colleagues ..

Hi @mimugmail,
Any news yet?

Yesterday at 14:00 I started N+ with 33 virtual hosts, MS3 disabled, but module loaded via global config. No memissue yet.
Next test is to enable MS3 again and drop external connections to be sure that there's no external process causing the issue.

@zimmerle Sorry for the delay, I know started nginx with the live config bug it only listens to IP addresses which are bound to the current master, so it's just running and no connecting client can be responsible for any mem issues

Till now there was no memory issue running N+ with MS3 but not listening to any running IP.
I edited a virutal host with the current IP address of the backup system and did a reopen.
Issue shoul be back within the next few hours ...

@zimmerle
It took zwo hours:
2017/03/18 09:48:47 [notice] 15175#15175: reopening logs
2017/03/18 09:48:47 [notice] 15176#15176: reopening logs
2017/03/18 09:48:47 [notice] 15188#15188: reopening logs
2017/03/18 09:48:47 [notice] 15184#15184: reopening logs
2017/03/18 09:48:47 [notice] 15186#15186: reopening logs
2017/03/18 09:48:47 [notice] 15187#15187: reopening logs
2017/03/18 11:32:46 [notice] 29425#29425: signal 17 (SIGCHLD) received
2017/03/18 11:32:46 [alert] 29425#29425: worker process 15186 exited on signal 9
2017/03/18 11:32:46 [notice] 29425#29425: start worker process 16863
2017/03/18 11:32:46 [notice] 29425#29425: signal 29 (SIGIO) received
2017/03/18 12:49:43 [notice] 29425#29425: signal 17 (SIGCHLD) received
2017/03/18 12:49:43 [alert] 29425#29425: worker process 16863 exited on signal 9
2017/03/18 12:49:43 [notice] 29425#29425: start worker process 18001
2017/03/18 12:49:44 [notice] 29425#29425: signal 29 (SIGIO) received
2017/03/18 13:05:05 [notice] 29425#29425: signal 17 (SIGCHLD) received
2017/03/18 13:05:05 [alert] 29425#29425: worker process 15188 exited on signal 9
2017/03/18 13:05:05 [notice] 29425#29425: start worker process 18233
2017/03/18 13:05:06 [notice] 29425#29425: signal 29 (SIGIO) received
2017/03/18 15:40:15 [notice] 29425#29425: signal 17 (SIGCHLD) received
2017/03/18 15:40:15 [alert] 29425#29425: worker process 15184 exited on signal 9
2017/03/18 15:40:15 [notice] 29425#29425: start worker process 20583
In this time there were only 4 accesses (first three my tests and one "client"/bot/whatever)
81.24.x - - [18/Mar/2017:09:48:49 +0100] "GET / HTTP/1.1" 403 564 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"
81.24.x - - [18/Mar/2017:09:49:13 +0100] "GET / HTTP/1.1" 403 564 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"
81.24.x - - [18/Mar/2017:09:49:20 +0100] "GET / HTTP/1.1" 403 564 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36"
157.52.x - - [18/Mar/2017:10:55:40 +0100] "GET / HTTP/1.1" 403 564 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"

@mimugmail, could you please share system logs? Were there any messages from OOM killer?
Do you have any ps or top output showing how much memory nginx workers were consuming?
Could you please also share the entire nginx (nginx -T) and modsecurity configuration?

@defanator  Yep, here's the output
[3619581.644080] nginx invoked oom-killer: gfp_mask=0x24280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=0-1, order=0, oom_score_adj=0
[3619581.644082] nginx cpuset=/ mems_allowed=0-1
[3619581.644087] CPU: 2 PID: 13918 Comm: nginx Not tainted 4.9.0-0.bpo.1-amd64 #1 Debian 4.9.2-2~bpo8+1
[3619581.644088] Hardware name: FUJITSU PRIMERGY RX2530 M2/D3279-B1, BIOS V<IP_ADDRESS> R1.7.0 for D3279-B1x                     04/21/2016
[3619581.644089]<PHONE_NUMBER>000000 ffffffff8c72a1f5 ffffb820aba67ce0 ffff8bdd18557000
[3619581.644092]  ffffffff8c5fef45<PHONE_NUMBER>000000<PHONE_NUMBER>000000 ffff8bd51fc987c0
[3619581.644094]  ffff8bdd18557080 ffffffff8c42476b ffff8bd53fffccf0 ffffffff8c586a23
[3619581.644097] Call Trace:
[3619581.644105]  [] ? dump_stack+0x5c/0x77
[3619581.644109]  [] ? dump_header+0x85/0x212
[3619581.644113]  [] ? __switch_to+0x2bb/0x700
[3619581.644117]  [] ? get_page_from_freelist+0x113/0xad0
[3619581.644118]  [] ? oom_kill_process+0x228/0x3e0
[3619581.644123]  [] ? has_capability_noaudit+0x1a/0x20
[3619581.644125]  [] ? oom_badness+0xee/0x160
[3619581.644126]  [] ? out_of_memory+0x10c/0x4b0
[3619581.644128]  [] ? __alloc_pages_slowpath+0xa7e/0xaa0
[3619581.644130]  [] ? __alloc_pages_nodemask+0x29b/0x2e0
[3619581.644133]  [] ? alloc_pages_vma+0xc1/0x240
[3619581.644135]  [] ? handle_mm_fault+0x1417/0x1650
[3619581.644138]  [] ? mprotect_fixup+0x142/0x270
[3619581.644141]  [] ? __do_page_fault+0x253/0x510
[3619581.644145]  [] ? page_fault+0x28/0x30
[3619581.644146] Mem-Info:
[3619581.644154] active_anon:15275784 inactive_anon:898573 isolated_anon:0
active_file:247 inactive_file:840 isolated_file:0
unevictable:0 dirty:0 writeback:248 unstable:0
slab_reclaimable:4687 slab_unreclaimable:16862
mapped:2144 shmem:1621 pagetables:60342 bounce:0
free:56615 free_pcp:6120 free_cma:0
[3619581.644159] Node 0 active_anon:30138772kB inactive_anon:1772964kB active_file:580kB inactive_file:656kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:4676kB dirty:0kB writeback:0kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 4672kB writeback_tmp:0kB unstable:0kB pages_scanned:182750 all_unreclaimable? yes
[3619581.644163] Node 1 active_anon:30964364kB inactive_anon:1821328kB active_file:408kB inactive_file:2704kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:3900kB dirty:0kB writeback:992kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 1812kB writeback_tmp:0kB unstable:0kB pages_scanned:54592 all_unreclaimable? yes
[3619581.644165] Node 0 DMA free:15888kB min:20kB low:32kB high:44kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15980kB managed:15896kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[3619581.644169] lowmem_reserve[]: 0 1632 31826 31826 31826
[3619581.644172] Node 0 DMA32 free:123020kB min:2292kB low:3960kB high:5628kB active_anon:1558940kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:1753836kB managed:1688268kB mlocked:0kB slab_reclaimable:56kB slab_unreclaimable:4kB kernel_stack:0kB pagetables:3052kB bounce:0kB free_pcp:164kB local_pcp:44kB free_cma:0kB
[3619581.644176] lowmem_reserve[]: 0 0 30193 30193 30193
[3619581.644179] Node 0 Normal free:42292kB min:42448kB low:73364kB high:104280kB active_anon:28579832kB inactive_anon:1772964kB active_file:580kB inactive_file:656kB unevictable:0kB writepending:0kB present:31457280kB managed:30923148kB mlocked:0kB slab_reclaimable:12712kB slab_unreclaimable:43556kB kernel_stack:5096kB pagetables:159364kB bounce:0kB free_pcp:10152kB local_pcp:708kB free_cma:0kB
[3619581.644182] lowmem_reserve[]: 0 0 0 0 0
[3619581.644185] Node 1 Normal free:45260kB min:45344kB low:78368kB high:111392kB active_anon:30964364kB inactive_anon:1821328kB active_file:408kB inactive_file:2704kB unevictable:0kB writepending:992kB present:33554432kB managed:33026364kB mlocked:0kB slab_reclaimable:5980kB slab_unreclaimable:23880kB kernel_stack:3624kB pagetables:78952kB bounce:0kB free_pcp:14164kB local_pcp:204kB free_cma:0kB
[3619581.644189] lowmem_reserve[]: 0 0 0 0 0
[3619581.644191] Node 0 DMA: 24kB (U) 18kB (U) 016kB 032kB 264kB (U) 1128kB (U) 1256kB (U) 0512kB 11024kB (U) 12048kB (M) 34096kB (M) = 15888kB
[3619581.644200] Node 0 DMA32: 94kB (UE) 118kB (UME) 716kB (UME) 1132kB (UM) 764kB (U) 5128kB (UME) 2256kB (UE) 2512kB (UE) 11024kB (E) 22048kB (ME) 284096kB (UM) = 123020kB
[3619581.644211] Node 0 Normal: 17734kB (UME) 3758kB (UME) 23616kB (UME) 14432kB (UME) 7964kB (ME) 45128kB (E) 22256kB (ME) 11512kB (UME) 21024kB (UM) 02048kB 04096kB = 42604kB
[3619581.644221] Node 1 Normal: 2804kB (ME) 1838kB (E) 17716kB (ME) 11732kB (ME) 7964kB (ME) 36128kB (E) 19256kB (UME) 8512kB (UME) 31024kB (E) 12048kB (M) 34096kB (UM) = 45192kB
[3619581.644232] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
[3619581.644233] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[3619581.644234] Node 1 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
[3619581.644235] Node 1 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[3619581.644235] 4438 total pagecache pages
[3619581.644236] 1264 pages in swap cache
[3619581.644237] Swap cache stats: add 85459517, delete 85458253, find 21319700/24401710
[3619581.644238] Free swap  = 0kB
[3619581.644239] Total swap = 7798780kB
[3619581.644239] 16695382 pages RAM
[3619581.644240] 0 pages HighMem/MovableOnly
[3619581.644240] 281963 pages reserved
[3619581.644241] 0 pages hwpoisoned
[3619581.644241] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
[3619581.644251] [ 1113]     0  1113    10368        1      23       3      258         -1000 systemd-udevd
[3619581.644253] [ 1125]     0  1125    20526     1151      46       3       51             0 systemd-journal
[3619581.644255] [ 1841]     0  1841     6869       10      19       3       51             0 cron
[3619581.644256] [ 1842]     0  1842     4756        0      15       3       52             0 atd
[3619581.644257] [ 1845]     0  1845     4964        0      15       3       79             0 systemd-logind
[3619581.644259] [ 1860]   105  1860    10531        1      26       3      101          -900 dbus-daemon
[3619581.644260] [ 1871]   113  1871    21918        1      43       3      249             0 zabbix_agentd
[3619581.644261] [ 1880]   113  1880    21918      572      44       3      232             0 zabbix_agentd
[3619581.644263] [ 1881]   113  1881    21918       34      43       3      244             0 zabbix_agentd
[3619581.644264] [ 1882]   113  1882    21918       34      43       3      244             0 zabbix_agentd
[3619581.644265] [ 1883]   113  1883    21918       34      43       3      244             0 zabbix_agentd
[3619581.644267] [ 1884]   113  1884    21918       55      44       3      249             0 zabbix_agentd
[3619581.644268] [ 1946]   110  1946     8346       16      22       3      144             0 ntpd
[3619581.644269] [ 1949]     0  1949    64668       47      28       3      534             0 rsyslogd
[3619581.644271] [ 1950]     0  1950    12893       13      25       3      135             0 keepalived
[3619581.644272] [ 1952]     0  1952    14491       13      30       3      175             0 keepalived
[3619581.644273] [ 1953]     0  1953    14460       22      30       3      155             0 keepalived
[3619581.644275] [ 1955]     0  1955     1064        1       8       3       36             0 acpid
[3619581.644276] [ 1962]     0  1962     4926       91      15       3       65             0 irqbalance
[3619581.644277] [ 2126]     0  2126     9042        0      23       3      144             0 master
[3619581.644279] [ 2131]   108  2131     9600        1      25       3      157             0 qmgr
[3619581.644280] [ 2232]     0  2232     3604        1      12       3       36             0 agetty
[3619581.644282] [22529]     0 22529     6481        4      18       3      156             0 smartd
[3619581.644285] [22663]     0 22663    20682       57      44       3      223             0 sshd
[3619581.644286] [22665]     0 22665     5889      136      16       3      412             0 bash
[3619581.644288] [17566]     0 17566    20682       18      44       3      208             0 sshd
[3619581.644289] [17568]     0 17568     5819        1      15       3      479             0 bash
[3619581.644291] [29425]     0 29425   356683       10     663       5   293804             0 nginx
[3619581.644292] [15150]   109 15150   356686        0     657       5   293823             0 nginx
[3619581.644294] [15151]   109 15151   356686        0     657       5   293829             0 nginx
[3619581.644295] [15152]   109 15152   356686        0     657       5   293815             0 nginx
[3619581.644296] [15153]   109 15153   356686        0     657       5   293818             0 nginx
[3619581.644298] [15154]   109 15154   356686        0     657       5   293814             0 nginx
[3619581.644299] [15155]   109 15155   356686        0     657       5   293834             0 nginx
[3619581.644300] [15156]   109 15156   356686        0     657       5   293808             0 nginx
[3619581.644302] [15157]   109 15157   356686        0     657       5   293814             0 nginx
[3619581.644303] [15158]   109 15158   356686        0     657       5   293815             0 nginx
[3619581.644304] [15159]   109 15159   356686        0     657       5   293816             0 nginx
[3619581.644305] [15160]   109 15160   356686        0     657       5   293835             0 nginx
[3619581.644307] [15161]   109 15161   356686        0     657       5   293829             0 nginx
[3619581.644308] [15162]   109 15162   356686        0     657       5   293837             0 nginx
[3619581.644309] [15163]   109 15163   356686        0     657       5   293832             0 nginx
[3619581.644310] [15164]   109 15164   356686       10     657       5   293796             0 nginx
[3619581.644311] [15165]   109 15165   356686        6     657       5   293800             0 nginx
[3619581.644313] [15166]   109 15166   356686        0     657       5   293824             0 nginx
[3619581.644314] [15167]   109 15167   356686        0     657       5   293839             0 nginx
[3619581.644315] [15168]   109 15168   356686        1     659       5   293828             0 nginx
[3619581.644316] [15169]   109 15169   356686        0     657       5   293832             0 nginx
[3619581.644318] [15170]   109 15170   356686        0     657       5   293833             0 nginx
[3619581.644319] [15173]   109 15173   356686        0     657       5   293818             0 nginx
[3619581.644320] [15174]   109 15174   356686        1     659       5   293812             0 nginx
[3619581.644322] [15175]   109 15175   356686        0     657       5   293835             0 nginx
[3619581.644323] [15176]   109 15176   356686        0     657       5   293814             0 nginx
[3619581.644324] [15177]   109 15177   356686        0     657       5   293828             0 nginx
[3619581.644326] [15180]   109 15180   356686        0     657       5   293832             0 nginx
[3619581.644327] [15182]   109 15182   356686        0     657       5   293826             0 nginx
[3619581.644329] [15419]     0 15419    13796        0      32       3      173         -1000 sshd
[3619581.644330] [34128]     0 34128     4884      134      15       3       26             0 conntrackd
[3619581.644331] [34174]     0 34174    30353       12      58       3      450             0 proftpd
[3619581.644333] [38217]   109 38217   356686        0     657       5   293822             0 nginx
[3619581.644334] [38220]   109 38220   356686        0     657       5   293806             0 nginx
[3619581.644335] [40328]   109 40328   356686        1     659       5   293815             0 nginx
[3619581.644336] [  810]   109   810   356686        0     657       5   293826             0 nginx
[3619581.644338] [ 4385]   109  4385   356686        0     657       5   293812             0 nginx
[3619581.644339] [10441]   109 10441   356686       26     657       5   293782             0 nginx
[3619581.644340] [10442]   109 10442   356686       14     657       5   293794             0 nginx
[3619581.644342] [13917]   109 13917   356686      278     659       5   293651             0 nginx
[3619581.644343] [13918]   109 13918 17990351 16170643   35121      72  1768405             0 nginx
[3619581.644344] [19063]   108 19063     9558        0      24       3      140             0 pickup
[3619581.644346] Out of memory: Kill process 13918 (nginx) score 978 or sacrifice child
[3619581.645898] Killed process 13918 (nginx) total-vm:71961404kB, anon-rss:64681904kB, file-rss:640kB, shmem-rss:28kB
[3619583.731282] oom_reaper: reaped process 13918 (nginx), now anon-rss:0kB, file-rss:0kB, shmem-rss:28kB
ps aufx:
root     29425  0.0  0.0 1426732  960 ?        Ss   Mar13   0:11 nginx: master process nginx
nginx    15150  0.0  0.0 1426744  588 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15151  0.0  0.0 1426744  572 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15152  0.0  0.0 1426744  716 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15153  0.0  0.0 1426744  588 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15154  0.0  0.0 1426744  816 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15155  0.0  0.0 1426744  196 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15156  0.0  0.0 1426744  824 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15157  0.0  0.0 1426744  720 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15158  0.0  0.0 1426744  816 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15159  0.0  0.0 1426744  732 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15160  0.0  0.0 1426744  216 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15161  0.0  0.0 1426744  568 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15162  0.0  0.0 1426744  140 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15163  0.0  0.0 1426744  464 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15164  0.0  0.0 1426744   44 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15165  0.0  0.0 1426744   28 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15166  0.0  0.0 1426744  600 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15167  0.0  0.0 1426744  136 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15168  0.0  0.0 1426744  128 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15169  0.0  0.0 1426744  524 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15170  0.0  0.0 1426744  396 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15173  0.0  0.0 1426744  704 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15174  0.0  0.0 1426744  640 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15175  0.0  0.0 1426744  368 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15176  0.0  0.0 1426744  780 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15177  0.0  0.0 1426744  560 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15180  0.0  0.0 1426744  588 ?        S    Mar18   0:00  _ nginx: worker process
nginx    15182  0.0  0.0 1426744  584 ?        S    Mar18   0:00  _ nginx: worker process
nginx    38217  0.0  0.0 1426744    0 ?        S    Mar19   0:00  _ nginx: worker process
nginx    38220  0.0  0.0 1426744    4 ?        S    Mar19   0:00  _ nginx: worker process
nginx    40328  0.0  0.0 1426744  800 ?        S    Mar19   0:00  _ nginx: worker process
nginx      810  0.0  0.0 1426744  576 ?        S    Mar19   0:00  _ nginx: worker process
nginx     4385  0.0  0.0 1426744  772 ?        S    Mar19   0:00  _ nginx: worker process
nginx    10441  0.0  0.0 1426744  108 ?        S    00:44   0:00  _ nginx: worker process
nginx    10442  0.0  0.0 1426744   60 ?        S    00:44   0:00  _ nginx: worker process
nginx    13917  0.3  0.0 1426744 1116 ?        S    04:34   1:18  _ nginx: worker process
nginx    20277  0.0  0.0 1426744 4756 ?        S    11:18   0:00  _ nginx: worker process
Can I send you the nginx -T via N+ commercial support and you close the ticket again? Since I don't want to post here very sensitive data, but I also know MS3 in a scenario like this is not officially supported via N+ support.

@mimugmail, is it happening with the "code base of Feb 24"? May I ask you to try the latest nginx-plus-module-modsecurity package then, or update ModSecurity + ModSecurity-nginx to v3/master and master branches, correspondingly.
If the issue will persist, we will proceed with further investigation.

@defanator Yes, it's still 24th, so I'll update it now to latest v3/master.
Before I update the system from R11 to R12, was there really a change in the codebase of nginx-plus-module-modsecurity or was it only recompiled for compatibility with R12?

@mimugmail, it was recompiled from sources as of Mar, 10 (after v3/dev/parser was merged into v3/master).

@defanator Ooooh 👍 Wasn't informed by N+ team, great news!
I'll switch back from source to package at on my backup machine, really great news! :)

@mimugmail, sure - please share your results here.

@defanator With the package it runs very smoothly 👍
I'll try to put this machine into production for a couple of hours when my team is fully available.

@defanator Do you know if there's a new verison of the N+ documentation. I switched and had massive blocks for rules 912100, 912110 and 910130. My thought was that with the current code base I don't have to disable certain rule types.

@mimugmail, we're working on the documentation. You're correct, current codebase works with OWASP CRS v3.0.0 as is (no manual removing any of pre-configured rules is required).
Please feel free to use N+ support channel for such kind of questions, leaving this thread focused on the memory issue - thank you!

@defanator Yep, so this issue seems to be fixed now, you can close this one. Thanks for your efforts 👍


p4v: update sha256

Motivation for this change
Upstream has updated their tarball.
p4merge works.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build p4v

No attempt on x86_64-linux (full log)
The following builds were skipped because they don't evaluate on x86_64-linux: p4v
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: p4v
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.


Merge to upstream

Hey! I'm from the Replugged team, was wondering if you'd be interested in merging this flake into the main repo under a nix or flake directory. It'd help by showing we support it directly. Let me know your thoughts :)

Thoughts are definitely positive!
It definitely needs some work making it better, right now it still requires some manual work to properly install, but I've been using it on my laptop since I created the repo, so I can confidently say that it does work.
If you'd like to chat on Discord rather than here, I'm there under the same name (@lyssieth), you can ping me in the Replugged discord or DM me freely.


Clean up timeouts in the conn and add :max_concurrent_requests_per_connection

cc @harunzengin

@harunzengin and no memory leaks or anything like that, correct?

@whatyouhide No, it runs since yesterday and no memory leaks.

Yep, right after I fix https://github.com/whatyouhide/xandra/issues/359.


Feedback form Backend Email

Describe the bug
This bug can be fixed by replacing the email id with osc mail id. The bug lets the code to send the feedback message to a developer's test email rather than sending it to the club mail id.
To Reproduce
Steps to reproduce the behaviour:

Open https://osc-hub.herokuapp.com/dashboard/about/
Scroll down to the end of the page
Fill in the feedback
The feedback will be sent successfully to the test email instead of the club's official email.

Expected behavior
The feedback form in about.html will not be sending any feedbacks to the osc instead all the feedback will be sent to the already existing developer's test email.
Screenshots
Screenshot of the line that needs to be fixed.

Desktop (please complete the following information):

OS: Windows 10
Browser: Edge
Version: 91.0.864.70

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Commit b306dfd  Fixed the issue.

Unsure as to whether the issue is resolved, could you add an explanation as to why the SMTP Authentication fails?
I'm supposing that it has to do with the Google API not providing the users with access to send mails via SMTP, might wish to check this issue out?
In order to avoid necrobumping, I recommend a new issue created for it.


Use qcow2 overlay as the VM disk image instead of copying the bundle image

Using qemu-img create -b ~/.crc/cache/crc_libvirt_xxx/crc.qcow2 -F qcow2 crc-overlay.qcow2 should create an empty qcow2 file which will reference  ~/.crc/cache/crc_libvirt_xxx/crc.qcow2 and only record the changes we make to it
Probably possible to create it through libvirt virsh snapshot-create-as --domain vm1 snap1 --diskspec vda,file=/export/images/sn1.qcow2 --disk-only --atomic --no-metadata, I did not look for the corresponding libvirt.so API.
Avoiding the copy would save 10GB on the user's hard drive, and make initial crc start faster.

Side-note: CRC should respect the xdg-dirs and keep the cache in ~/.cache/crc/ instead.

we have considered this, but this makes removing crc a simple action and consistent on ALL supported platforms, regardless if they know about xdg-dirs or not

we have considered this, but this makes removing crc a simple action and consistent on ALL supported platforms, regardless if they know about xdg-dirs or not

crc should be used by users in most cases anyway. If there is a use case of users deleting the whole directory, there should be a crc subcommand to do that. Breaking away from standards for easily working around crc limitation is not good IMO.

many standards exist, but it doesn't mean they all apply to us

Uninstall/remove code is handled in https://github.com/code-ready/crc/pull/651 (https://github.com/code-ready/crc/issues/507).

Ref: #34

many standards exist, but it doesn't mean they all apply to us

Sure but this one does since we're putting things in user's home dirs.

since we're putting things in user's home dirs.

and also on Windows, etc... and in Windows we also don't use the Local Settings or Application Data folders. This has been the expected behaviour since Minishift (minikube). What bebenfit would this give us?

Probably possible to create it through libvirt virsh snapshot-create-as --domain vm1 snap1 --diskspec vda,file=/export/images/sn1.qcow2 --disk-only --atomic --no-metadata, I did not look for the corresponding libvirt.so API.

@cfergeau You mean this would achieve the same as the qemu-img command you specified before? If so, this one would require the VM and it's empty volume to be already available, right?

I'm not familiar at all with this command, I only copied it here if it's useful when someone experiments with this.


Added Project Section

#ISSUE-NO
#232
What does this PR do?
Add project section to community website
Description of Task to be completed?
Fix the following issues:

[x] #233
[ ] #234

How can this be manually tested?
Local host
Any background context you want to provide?
Not responsive on mobile view
What is the relevant issue link?
#232
Screenshots (if appropriate)
Questions:

Nice work @Evavic44
Pls check this.

I  think it can be prevented if you set the z-index of the project div

Does it make sense to use the GitHub api to get the projects with all data?

One other suggestion maybe you can use flex ox to make it responsive
I mostly use something like this:
.flex-col-2 { width: 100%; height: auto; columns: 2;}

Nice work @Evavic44
Pls check this.

I think it can be prevented if you set the z-index of the project div

Thanks for pointing that out, didn't scroll the project section past the navbar.

Does it make sense to use the GitHub API to get the projects with all data?
I`ve implemented that to my portfolio website here
https://github.com/schmelto/portfolio/blob/09c68f9677c33fa90461bb7c9e73052c38279cfe/js/scripts.js#L91
This would look something like this
let githubprojects = [
  {
    name: 'schmelto/portfolio',
    icon: 'person',
  },
  {
    name: 'chryz-hub/chryz-hub.github.io',
    icon: 'home',
  },
];

function getproject(project, icon) {
  fetch(`https://api.github.com/repos/${project}`)
    .then((response) => {
      return response.json();
    })
    .then((project) => {
      githubprojectsdomelement.innerHTML += createprojectcard(project, icon);
    });
}

function createprojectcard(project, icon) {
  // add html elements
}

some more references can be found here https://docs.github.com/en/rest/reference/repos

I like this idea, so we won't have to constantly maintain this or add more projects.

One question though, is there a way to automatically add the background image as well?

One question though, is there a way to automatically add the background image as well?

For that I think we can pass the source for background image just like the icon. Or we can find other ways.

For that I think we can pass the source for background image just like the icon. Or we can find other ways.

The other way could be to use the social preview image of the repo itself don't know if the API sends this by itself

For that I think we can pass the source for background image just like the icon. Or we can find other ways.

The other way could be to use the social preview image of the repo itself don't know if the API sends this by itself

Yeah, it would be great if it works

For that I think we can pass the source for background image just like the icon. Or we can find other ways.

The other way could be to use the social preview image of the repo itself don't know if the API sends this by itself

Okay, so what next?  Should I merge this so you can write the code?.

Okay, so what next?  Should I merge this so you can write the code?

I leave it open for someone else we can make a new issue out of this?

One other question is this a copyright free image?
and I think @Evavic44 the problem with the z-index is still open?

One other question is this a copyright free image?
and I think @Evavic44 the problem with the z-index is still open?

Okay, I'll fix the z-index issue and then create another PR. The image is just some random image I saw online, maybe will delete it for now or use a free photo from Pexels or Unsplash.


LIVERY REQUEST: Thai Airways Airbus A380-800

I'm Back Requesting Thai Airways Airbus A380 After A Holy Week Or Passion Week Break


Framework for sample that doesn't render

I'm experimenting with writing a Debug Printf sample that would run a compute shader to generate Debug Printf output.  I don't see a way to create a sample that doesn't create a window.  It seems that before any of my code is run, a window has already been created.  Is there a way for a sample to avoid window creation and simply output to the console window?

Interesting idea, currently --headless can be used to disable the window, but there is no way - to my knowledge - for a sample to manipulate the platform before the platform has initiated its components. I think this is due to the fact that a samples init phase can involve Vulkan which requires a window to be previously created.
A call-back would be needed before this phase and the platform will need to be adjusted to react to changes in configurations. I don't believe we destroy and recreate windows in the apps current lifecycle, a window is created and its life time is the life time of the app.
Added as feature request for now


Add actual shadowJar plugin

./gradlew shadowJar was not working on my machine until I've added an explicit reference to shadowJar plugin.

Actually, the shadowJar instruction in the README is out of date - drongo is currently only intended to be used a submodule in Sparrow. Fixed in 35bebe1.


Update fides.js API options and improve automated tests

Closes PROD-1234
Description Of Changes
This is a few small changes to the FidesJS API for some different names of options/events, and some fixes and improvements to the Cypress tests.
Code Changes

[X] Rename FidesPreferenceToggled -> FidesUIChanged
[X] Rename window.config.fides -> window.config.tc_info
[X] Update Cypress specs
[ ] Make window.config.tc_info a configurable option, change default to window.fides_config

Steps to Confirm
n/a
Pre-Merge Checklist

[X] All CI Pipelines Succeeded
Documentation:

[X] documentation complete, PR opened in fidesdocs
[X] documentation issue created in fidesdocs

[X] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[X] Update CHANGELOG.md
[ ] For API changes, the Postman collection has been updated

@eastandwestwind updated 👍


Android-Java  4.2: Android-Popup-Menu

Description
What is popup menu?
Usage and implementation
Example
Domain
Android Dev (Java)
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign

Issue fixed
PR #6260
@VikasPandey121 Sir please review the PR.


Cannot find module './mysql_bindings'

In 1.2.5 the mysql_bindings.node symlink to build/default/mysql_bindings.node is missing therefore the module fails to work out of the box. The wscript misses the relevant bits.

Same error
$ git clone https://github.com/Sannis/node-mysql-libmysqlclient.git mysql-libmysqlclient
$ cd mysql-libmysqlclient
$ git checkout v1.2.6
$ node-waf configure build
$ node doc/examples/url_shortener/index.js
node.js:134
    throw e; // process.nextTick error, or 'error' event on first tick
    ^
Error: Cannot find module './mysql_bindings'

I've fixed it with copying build/default/mysql_bindings.node to directory:
$ cp build/default/mysql_bindings.node .
$ node doc/examples/url_shortener/index.js
Server running at http://localhost:12700/

Also I tried node-waf install
$ node-waf install
Waf: Entering directory `/usr/local/lib/node_modules/mysql-libmysqlclient/build'
* installing build/default/mysql_bindings.node as /usr/local/lib/node_modules/mysql_bindings.node

— as you can see it've copied mysql_binding.node upper than module directory, and Cannot find module './mysql_bindings' error appears again.
npm produce same behavior and same error.

That's because most packages that build native modules make a symlink foo.node -> build/default/foo.node.

Can you post here npm install mysql-libmysqlclient output? For me i works properly:
efimovov@efimovov-pc:~/tmp> npm install mysql-libmysqlclient

><EMAIL_ADDRESS>install /home/efimovov/tmp/node_modules/mysql-libmysqlclient
> make conf all

rm -rf ./build
rm -f ./mysql_bindings.node
node-waf configure
Checking for program g++ or c++          : /usr/bin/g++
Checking for program cpp                 : /usr/bin/cpp
Checking for program ar                  : /usr/bin/ar
Checking for program ranlib              : /usr/bin/ranlib
Checking for g++                         : ok
Checking for node path                   : ok /home/efimovov/.node_libraries
Checking for node prefix                 : ok /usr/local
Checking for library mysqlclient_r       : yes
Checking for header mysql.h              : yes
'configure' finished successfully (0.719s)
node-waf build
Waf: Entering directory `/home/efimovov/tmp/node_modules/mysql-libmysqlclient/build'
[1/5] cxx: src/mysql_bindings.cc -> build/Release/src/mysql_bindings_1.o
[2/5] cxx: src/mysql_bindings_connection.cc -> build/Release/src/mysql_bindings_connection_1.o
[3/5] cxx: src/mysql_bindings_result.cc -> build/Release/src/mysql_bindings_result_1.o
[4/5] cxx: src/mysql_bindings_statement.cc -> build/Release/src/mysql_bindings_statement_1.o
[5/5] cxx_link: build/Release/src/mysql_bindings_1.o build/Release/src/mysql_bindings_connection_1.o build/Release/src/mysql_bindings_result_1.o build/Release/src/mysql_bindings_statement_1.o -> build/Release/mysql_bindings.node
Waf: Leaving directory `/home/efimovov/tmp/node_modules/mysql-libmysqlclient/build'
'build' finished successfully (1.555s)
<EMAIL_ADDRESS>./node_modules/mysql-libmysqlclient

@Sannis: after the build try this:
cd node_modules/mysql-libmysqlclient
ls -l | grep mysql_bindings

Hint: there's something missing aka mysql_bindings.node into the root of the mysql-libmysqlclient directory.

@Sannis, yeah, install log shows nothing wrong, but as @SaltwaterC said, mysql_bindings.node in mysql-libmysqlclient is missing.

Yep, I've checked it... Unfortunatly:
efimovov@efimovov-pc:~/tmp> cd node_modules/mysql-libmysqlclient
efimovov@efimovov-pc:~/tmp/node_modules/mysql-libmysqlclient> ls -l | grep mysql_bindings
lrwxrwxrwx 1 efimovov users    33 Nov  2 15:10 mysql_bindings.node -> build/Release/mysql_bindings.node

I'll try to move ln -s to Makefile and post a test tarball.

Are you expecting this with 1.2.7 too?

Yes. I'll try a wscript patch inspired from another module that does it properly. Stay tuned :)

Thanks for this patch. Can you make it compatible with Node v0.6? It uses build/Release folder for builded module.

Sorry about that. I thought that I tested it against 0.6, but I didn't. I'll try patch things for this case.


RTL support

motivation: #319
further work: implement a helper function

@osdnk Would you mind share your opinion about this? It certainly fixes the issue of not being able to swipe the row. The only thing I see is that your implementation of an Apple-styled swipeable row does not work in the same way as without RTL enabled. My guess is it is not related to the library but just wanted you to take a look at this one as you were the author.

I will give a look.
For now I'm not able to build the example app on android....
Did you read my suggestion. After looking again at the file I have an idea to merge the suggestion easily.

I updated the Example app.
Everything works as it should for both layouts.
Because rtl layout needs flexDirection: row-reverse there's more dynamic styling to be applied higher up the component tree.
I think that in some use cases additional interpolation will be needed to be applied on progress/dragX passed to renderRightActions to achieve the desired behavior.
I tested both.
I think that styling is the answer in most use cases.
It might be good to document this because it might be frustrating handling right actions with rtl layout without peeking under the hood. (i.e. if someone needs to calculate interpolation they need to take into account that some measurements are relative to the right while most logic is relative to the left, meaning they might need to compensate for the width of the view in question or something alike for the calculation to be correct)
Hope I was clear

I will submit another PR for androidX build for Example app

this is wrong!! you actually check if the device is an rtl device but what you should check is the inherited View and know what direction you are in https://facebook.github.io/react-native/docs/layout-props#direction

AFAIK I18nManager is the standard for rtl layout logic.
Anyways this PR fixes calculations that shouldn't change (I think) due to direction prop.
Did you run the example app? and read the docs I've edited?

Any intention on merging this?

Guys, any progress here, please?
We really love this plugin, and we must have this fix.

If you want to use the version with a fix, you can simply provide GitHub link in package.json I guess. It was long time ago, I have limited time now, I will review it once again I guess. Not sure when though.

I've been using it since, seems to be fixed

It is a very minor change to js files

If you want to use the version with a fix, you can simply provide GitHub link in package.json I guess. It was long time ago, I have limited time now, I will review it once again I guess. Not sure when though.

Yep. It is what I did later...It is working.
@ShaMan123 thank you!

Dudes I know I am not a full time maintainer here as @osdnk was and I don't want to break anything, as I won't have time to fix it.

Please remove native changes and all white spaces changes and I’ll review it then

done

@vovkind
I tagged you to let you know I updated my fork from base so it should be good for RN0.61+.
Build passes.
Maintainers,
This repo is excellent.
Please make it RTL compatible, review this PR and accept it.

Any plans on merging this?

Sorry about this delay!


Added ready() method on ICE candidate event

This modification to the RTCPeerConnectionIceEvent notfication allows the client to inspect the incoming event and, if appropriate, to terminate ICE gathering and proceed immediately to SDP generation with the current collection of ICE candidates. It can reduce connection time significantly, for example, when simply an srflx or relay candidate is needed for a client with multiple IP addresses. The code intercepts the RTCPeerConnectionIceEvent and wraps it in an object of type RTCPeerConnectionIceEventEx, which presents a a ready() method. When the latter is called, iceGatheringComplete() is called on the SessionDescriptionHandler instance.
In my use case - connecting to a Kamailio proxy - call setup time is reduced from about 8 to about 2 seconds.
An alternative approach would be to deep-clone the RTCPeerConnectionIceEvent and add the ready() method, but this preserves the original WebRTC specification for the event.

Thanks. That works. It's a bit indirect, but if I give the SessionDelegate a method which provides me with a reference to the SessionDescriptionHandler, I can call the iceGatheringComplete() method on that reference. Trouble is, I have to cast the SessionDescriptionHandler as an any, because that method isn't published, which makes me uneasy. Is there another way?
I'm basically trying to replicate the action produced by iceGatheringTimeout. I agree that this is not part of the WebRTC standard (I'm not sure that iceGatheringTimeout is either, though), but it does provide a way to launch the connection the instant we know we have a suitable route. It really does produce a fast connection in what I suspect is a common use case - trying to route an SRTP connection to a public server.

The iceCheckingTimeout is definitely not part of the WebRTC spec.
You can copy our SDH and modify it. Then create a factory for it and pass that into the UA sessionDescriptionHandlerFactory.
There is some outstanding work on our end to make it easier to extend our SDH - but we have not gotten to it yet. So this is probably the best bet for now.

OK. That's what I'll do. I'll keep checking back, because I'd rather avoid cutting and pasting swathes of the project. I'd ask you to look at this feature though. I'd like to claim it was my idea, but it is implemented in another WebRTC project, and it works well in reducing connection times in internet-routed scenarios. That said, you've done a superb job on this project.  I need to fit a tricky orthogonal state model on top of a websocket SIP connection, and only sip.js gives me the close level of control I require.
I'm happy for you to close this one and reject the pull request. Thanks for your attention.


Enable MemoryLayoutTest in CI/release builds

MemoryLayoutTest is currently only built in debug mode, which means that we don’t test it in CI, where we build swift-syntax in release mode.
We should also enable it in release mode. The expected memory layout sizes might be different in release mode. In that case, we need to have two different expected dictionaries.

Tracked in Apple’s issue tracker as rdar://115176290

I believe that PR #2175 resolves the issue, but something seems to have gone wrong with the auto-close, hasn't it?


Where is commands and subprocess?

Inside cmd.py:
def cmd(cmd):
try:
import commands
return commands.getoutput(cmd)
except:
import subprocess
return subprocess.check_output(cmd, shell = True)
return os.system(cmd)
May i know where is commands and subprocess??Thanks

Got it. Commands module is no longer exists in Python 3


Remove register paragraph

ref #2594
Should I remove this section in all places?

What is "all places" @enilsen16 ?
Without knowing, my general answer would be, yes.

What is "all places" @enilsen16 ?

This same paragraph exists in 7 places in the documentation.

Without knowing, my general answer would be, yes.

:+1: Cool I'll update the PR


Dotted underline

Proposal to implement solution for issue #316: "Dotted underline".
This patch adds a path to render underlines for text segments.
The segments can be styled through the following CSS properties:
-fx-underline-stroke           (Color of the underline)
-fx-underline-stroke-dash-size (size of the dashes/spaces for a dashed line - this should really be an array some time)
-fx-underline-stroke-width     (The width of the underline)

The patch contains an enhancement of the JavaKeywords example where the word "simplements" is underlined:

Very cool! Can I propose to change the the names of CSS properties to omit the word "stroke", which kind of refers to the implementation detail that the visible underline is actually a stroke of a Path?
I suggest
-fx-underline-color
-fx-underline-width
-fx-underline-dash-size

Marking just the word simplements as error is somewhat arbitrary in the JavaKeywords demo. I am kind of already spreading bad ideas like using regular expressions to parse Java code. Don't want to get even messier :D. Maybe we can demonstrate the functionality better in a separate, say spell-checker, demo. That doesn't need to be part of this PR though.
I wasn't quite happy with the implementation of the background, because it creates the background Path for each Text node, even if that node doesn't specify any background. We might want to optimize this in the future.
For good looking results, it might also be necessary to join the underlines of neighboring segment, if they specify the same underline style, into one. This would be less of a problem with solid lines, but adjacent dashed lines will look ugly.

Hi Tomas,
I have now implemented the following properties:
-fx-underline-color
-fx-underline-width
-fx-underline-dash-array
-fx-underline-cap

With -fx-underline-dash-array it is now possible to specify a real array of dash lengths so that it supports also dot/dash style lines.
I also added a simple spell checking example and reverted the JavaKeywords sample. I think it makes sense to have a (at least simple) example available.
I have not yet approached the possibly unnecessary creation of Paths for each text segment.
I have also not yet worked on joining adjacent lines if they have the same style - this might require some more investigation. Its probably not only about the styles of the lines which need to be the same, but also the vertical position, which might depend on the style of the text segment itself.
Anyway, please let me know if you think that either of these topics still need to be addressed for the pull request ....

Looks good 👍  Thanks for the contribution!

@afester Am I correct in understanding that the underline CSS properties you added take affect regardless of Text#isUnderline()? I've written that in the CSS guide for this project, but I wanted to confirm that.

@JordanMartinez yes, as of now that is correct. Probably we should change that though - I will Check when I am back from vacation...

What @afester implemented is much richer than the pre-existing boolean property, that supports only a solid line of the same color as the text. I'm fine with keeping them as two independent properties, although I see that the naming will be confusing.

@afester ok. Enjoy your vacation :tropical_drink:
@TomasMikula what should the naming scheme be then?

@JordanMartinez Ideally the -fx-underline property should control whether the stylable underline which I implemented is visible or not. However, the property is implemented as final in the Text class and it directly controls the creation of the underline node (implemented in the Text's peer class NGText) - which, as @TomasMikula wrote, is always solid and in the same color as the text. So it seems that there is no possibility to redirect and/or reuse that property to control the stylable underline, instead of enabling/disabling the solid underline provided by Text. I am not completely satisfied with the confusing naming scheme either, and I am definitely open for any suggestions on better alternatives ...

I have an idea for the name scheme. Since the underline CSS is what is typically found in the Text class and we have implemented an alternative form for the underline, why don't we add the alt word in front?
In order words, the CSS you've implemented would be renamed to:
-fx-alt-underline-color
-fx-alt-underline-width
-fx-alt-underline-dash-array
-fx-alt-underline-cap
````

Yes, that makes sense. I would then also add -fx-alt-underline as the fx-underline equivalent which  then serves as the toggle switch to enable/disable the underline. The default rendering would be a solid line in the same color as the text, to be compatible with the normal -fx-underline behaviour. @TomasMikula what do you think?

A non-zero width can serve as the toggle. To choose from different styles of the line, we could have
-fx-alt-underline-style: solid | dashed

with solid being the default. We could add e.g. dotted later.

Ok, that is fine. We should not need -fx-alt-underline-style though - that is configurable in a much more flexible way through the -fx-alt-underline-dash-array property.

One (final) thought: Should we not use a custom prefix for RichTextFX specific CSS property names, like -rtfx instead of -fx? It seems that there is not a definitive recommendation for that in the JavFX specs, but it would at least lower the risk for future name clashes. See http://stackoverflow.com/questions/36725475/naming-of-css-property-names-for-javafx.
The property names could then be like
-rtfx-underline-color
-rtfx-underline-width
-rtfx-underline-dash-array
-rtfx-underline-cap

-rtfx sounds good to me 👍
Well, dotted is not quite the same as dashed, is it? And what if someone wants to contribute a squiggly line?

I'll file a new issue to update the RTFX-specific CSS to use the -rtfx- prefix, that way we can track it.

I have updated the property names and the behaviour wrt. the non-zero width in #324.

Well, dotted is not quite the same as dashed, is it? And what if someone wants to contribute a squiggly line?

Yes, but you can define simple dotted lines already now, like
-rtfx-underline-dash-array: 2 2;
-rtfx-underline-width: 2;

Squiggly/waved/triangled underlines (often seen in IDEs like Eclipse), or even a completely custom  rendering is if course another thing, which could be added later, now that we have the required path segments which make up the underline ...


feat: Migration tool

This is a tool to help migrate the old layout file format to the new one

Thanks. Which node version you did this test on, please?


Callbacks:Will langchaingo consider implementing CallbackManager like langchain-python does

I'm working with langchaingo to create chains and agents. I found out that callbacks can not trace all the execution steps when I attempt to debug my agents or chains.I would like to have a trace_id like langsmith does to display all the steps.
I also found that CallbackManager was implemented by langchain-python to manage callback handlers and use run_id/parent_run_id to trace all the steps.
Will langchaingo consider implementing CallbackManager like langchain-python does?For example,using and propagating trace info(trace_id and span_id) in context.Context to connect all the steps would be useful.

We have an implementation of this as of https://github.com/tmc/langchaingo/pull/257


[release-4.6] force use of runc, since we know we're privileged, and customize our seccomp filter

Force OCI isolation using runc instead of whatever we're configured for by the build controller (currently, usually chroot) to get control group settings that chroot isolation doesn't implement.
Replace the default seccomp filter with one based on Fedora 33's, but with listen, accept, mount, and umount disabled even for RUN instructions that run as root.

Closing until after we decide whether we want to do any of this on the master branch.

Closing until after we decide whether we want to do any of this on the master branch.


feat: create attribute-form component

This PR creates the AttributeForm component that opens as a modal inside the extension. This component allows you to set/update the alt and title attributes of a selected image.
This PR also creates the ButtonList icon.
This PR also includes some small styling adjustments to account for the rem value for SFCC bot being 16px.
Video
alt-title-settings.mov

Current dependencies on/for this PR:

next

PR #283

PR #284

PR #285

PR #286

PR #290

PR #288

PR #287

PR #289

@frederickfogerty assuming this was closed in error?


Add CreatePokerGameCommand and project structure

You're coupled to Future

@rgomezcasas that's the point! we want to show an evolution from purely imperative code to a more functional architecture :)


In Arabic showing empty

This control working perfectly in the L-TO-R screen but if we change the screen R-To-L it's not working perfectly. showing empty list

Please let me know if you got the solution

Please let me know if you got the solution

@arpitjain03 please update container frame size as per the total circle added in container it will work

@arpitjain03 please update container frame size as per the total circle added in container it will work

@ubrainrepo Can you share the code snippet you are using

@ubrainrepo Can you share the code snippet you are using

Got the solution:

Got the solution:

Got the solution, whenever you are changing the screen to R-To-L by applying for loop or any other approach. Make sure that you are not updating semanticContentAttribute for OnlyHorizontalPictures view.

Got the solution, whenever you are changing the screen to R-To-L by applying for loop or any other approach. Make sure that you are not updating semanticContentAttribute for OnlyHorizontalPictures view.

@ubrainrepo  can you please add the code snippet  you are using


Set indent as 4 spaces

Defined that indent are 4 spaces in tslint.json. Make sure that this is inforced during the lint job of the CI/CD workflow.

TS projects use almost equally 2 and 4 spaces according to this dashboard. Google, who develop Angular, use 2 spaces. Hence, projects generated using Angular CLI use 2 spaces. My preferred approach is to follow the "common" standard adopted by the community of a given programming language.


SyntaxError: import

In a non-next.js project, after installing styled-jsx and adding "styled-jsx/babel" to the  plugins array in my .babelrc file, I'm seeing the following error on compilation:
Module build failed: /my_project/node_modules/styled-jsx/babel.js:1
(function (exports, require, module, __filename, __dirname) { import jsx from 'babel-plugin-syntax-jsx'
                                                              ^^^^^^
SyntaxError: Unexpected token import

Is there something else needed in the babel config to get this to work?

Were fixing this now. It's publishing import export rather than compiling it atm<EMAIL_ADDRESS>

@adamyonk Does 0.0.3 work?

Fixed!


(chore): Added ProjectDetailCard Component for the Fourth theme

Signed-off-by: Abhijay Jain<EMAIL_ADDRESS>Description
Added ProjectDetailCard Component for the Fourth theme
Resolves #318
Screenshots (In case of UI changes):

Desktop  View

Types of changes

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests have passed and it does not give any unexpected error for the same.

cc @dinithminura


[FEA] Expose an API to get import error message

Is your feature request related to a problem? Please describe.
cuCIM ignores ImportError exception to allow partial imports (either cucim.skimage or cucim.clara package).
When an import error happens, there is no way to get the root cause of the error message.
python -c "import cucim; print(cucim.__version__); from cucim import CuImage"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'cucim'

Edit /home/cucim/anaconda3/envs/monai/lib/python3.8/site-packages/cucim/__init__.py
@@ -52,7 +52,8 @@ try:
     _is_clara_available = True
     submodules += ['clara']
     submod_attrs['clara'] = ['CuImage', 'cli']
-except ImportError:
+except ImportError as e:
+    print(e)
     from ._version import get_versions
     __version__ = get_versions()['version']
     del get_versions

libcudart.so.11.0: cannot open shared object file: No such file or directory
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name 'CuImage' from 'cucim' (/home/cucim/anaconda3/envs/monai/lib/python3.8/site-packages/cucim/__init__.py)

We would like to catch libcudart.so.11.0: cannot open shared object file: No such file or directory message without editing package source code so that root-cause the issue.
In above case, conda install -c conda-forge cudatoolkit=11.3   # or any 11.x version solves the issue.
Describe the solution you'd like
Store import error message in the module's variable and expose an API to get the error message.

Is there a way to fix this error on Windows with pip ?


Add requirement.txt file

@farzadoxo  please add the requirements.txt and the manual for running the backend service

ok engineer

please also add instructions on how to running the backend server. :-)

I make a tutorial in docs directory > backend-manual.md