JRE writes "Duplicate cpuset controllers detected." to stdout in a FHSUserEnv

[raboof]

Describe the bug

In a nix-shell sessions using buildFHSUserEnv, any invocation of java (even java -version) will write an error to stdout:

$ java -version 
[0.001s][warning][os,container] Duplicate cpuset controllers detected. Picking /sys/fs/cgroup/cpuset, skipping /host/sys/fs/cgroup/cpuset.
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12-nixos)
OpenJDK 64-Bit Server VM (build 17.0.1+12-nixos, mixed mode, sharing)

(the first line goes to stdout, the rest to stderr.

This causes problems when the stdout is supposed to be interpreted by another tool in some pipeline.

Steps To Reproduce

Use this shell.nix:

{ pkgs ? import <nixpkgs> {} }:

(pkgs.buildFHSUserEnv {
  name = "test";

  targetPkgs = pkgs: [
    pkgs.jdk
  ];
  
}).env

Expected behavior

Warnings/errors should go to stderr

Additional context

The 'real' bug is in OpenJDK, and it has been reported upstream as https://bugs.openjdk.java.net/browse/JDK-8270087 but closed as not reproducible. I'm pretty sure they didn't reproduce the warning at all (and consequently didn't see it get reported on stdout instead of stderr).

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.16.5, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.6.0`
 - channels(root): `"nixos-20.03pre194293.2436c27541b"`
 - nixpkgs: `/home/aengelen/nixpkgs`

[Cjen1]

Just to also say that I am experiencing this bug as well.

This seems to be the relevant line, but I am definitely not good enough at cpp to diagnose this.

Here is my reproducing flake.nix:

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let pkgs = nixpkgs.legacyPackages.${system};
      in {
        devShell = pkgs.mkShell {
          buildInputs = with pkgs; [
            sbt
            jdk17
          ];
        };
      });
}

And flake.lock:

  "nodes": {
    "flake-utils": {
      "locked": {
        "lastModified": 1644229661,
        "narHash": "sha256-1YdnJAsNy69bpcjuoKdOYQX0YxZBiCYZo4Twxerqv7k=",
        "owner": "numtide",
        "repo": "flake-utils",
        "rev": "3cecb5b042f7f209c56ffd8371b2711a290ec797",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "flake-utils",
        "type": "github"
      }
    },
    "nixpkgs": {
      "locked": {
        "lastModified": 1647872504,
        "narHash": "sha256-GwI8N6Ks0LoktqRLL/MyqtPJwbErXaWNZUROHO7vW6Y=",
        "owner": "nixos",
        "repo": "nixpkgs",
        "rev": "6aefdafbed9309f301d4605519f80b9498b98016",
        "type": "github"
      },
      "original": {
        "owner": "nixos",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "flake-utils": "flake-utils",
        "nixpkgs": "nixpkgs"
      }
    }
  },
  "root": "root",
  "version": 7
}

Although I expect that the problem is that I'm using the nix-chroot installation and hence this won't be easily reproducible.

[raboof]

The open upstream bug about this is https://bugs.openjdk.java.net/browse/JDK-8272121

Apparently it was intentionally done as per https://bugs.openjdk.java.net/browse/JDK-8153723

Unfortunately it seems -Xlog appenders are additive, so with -Xlog:all=warning:file=warnings.txt the warnings go to both stderr and warnings.txt.

With java -Xlog:disable -Xlog:all=warning:file=warnings.txt -Xlog:all=error:file=errors.txt warnings and errors go (only) to the respective files

With java -Xlog:disable -Xlog:all=warning:stderr -Xlog:all=error:stderr, however, the errors seem lost entirely?? That seems like a bug to me.

All this is easy to test with java -Xloggc:gc.log -version, which shows the version on stdout, and the warning about -Xloggc:gc.log being deprecated whereever you have configured errors to go.

[raboof]

With this background I'm OK to close this issue: upstream is unlikely to change the behavior, I don't think we should deviate too much from upstream, and now we know what parameters to add downstream if we want to avoid this output. Feel free to reopen, but I personally no longer think a change in nixpkgs is desirable.

[Cjen1]

@raboof The underlying problem I believe is the duplicate cpuset error, which I couldn't work out how to debug...

Its annoying that java logs the error to stdout (borking anything that communicates over stdout), but that is fixable in most cases by adding the relevant flags (in others it becomes... inconvenient, see gradle and various language servers).