Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

auto-cpufreq: should start on boot if enabled #126320

Closed
pnelson opened this issue Jun 9, 2021 · 6 comments · Fixed by #126897
Closed

auto-cpufreq: should start on boot if enabled #126320

pnelson opened this issue Jun 9, 2021 · 6 comments · Fixed by #126897
Labels
0.kind: bug Something is broken

Comments

@pnelson
Copy link
Contributor

pnelson commented Jun 9, 2021

Describe the bug
I believe the auto-cpufreq daemon should start on boot if enabled.

To Reproduce

  1. Enable auto-cpufreq daemon: services.auto-cpufreq.enable = true;.
  2. Reboot the system.
  3. Run systemctl status auto-cpufreq.
  4. Observe auto-cpufreq as dead/inactive.

Expected behavior
auto-cpufreq service should be started on boot.

Additional context
I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love.

I was able to fix this by adding the following to my configuration:

  systemd.services.auto-cpufreq.wantedBy = [ "default.target" ];

Notify maintainers
@Technical27

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

  • system: "x86_64-linux"
  • host os: Linux 5.10.40, NixOS, 21.05.804.5de44c15758 (Okapi)
  • multi-user?: yes
  • sandbox: yes
  • version: nix-env (Nix) 2.3.12
  • channels(pnelson): ""
  • channels(root): "nixos-21.05.804.5de44c15758, nixos-unstable-21.11pre294109.fbfb79400a0, nixos-hardware"
  • nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
@pnelson pnelson added the 0.kind: bug Something is broken label Jun 9, 2021
@Artturin
Copy link
Member

Artturin commented Jun 9, 2021

#81138

@Technical27
Copy link
Contributor

Sorry for being late, #126897 should fix this.

@ASHGOLDOFFICIAL
Copy link
Contributor

I have the exact same issue now, on 23.11.

@becknik
Copy link
Contributor

becknik commented Apr 11, 2024

Same here, also facing this problem on 23.11...

@becknik
Copy link
Contributor

becknik commented Apr 11, 2024

@nicoo

Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...

  systemd.services.auto-cpufreq =
    let
      cfg = config.services.auto-cpufreq;
      cfgFilename = "auto-cpufreq.conf";
      cfgFile = format.generate cfgFilename cfg.settings;

      format = pkgs.formats.ini { };
    in
    {
      description = "auto-cpufreq - Automatic CPU speed & power optimizer for Linux";
      wants = [ "multi-user.target" ];
      after = [ "multi-user.target" ];

      serviceConfig = {
        Type = "simple";
        User = "root";
        Restart = "on-failure";
        ExecStart = lib.mkForce [ "${lib.getExe pkgs.auto-cpufreq} --daemon --config ${cfgFile}" ];
      };
    };
  auto-cpufreq = with prev; auto-cpufreq.overrideAttrs (oldAttrs: {
    # https://github.com/AdnanHodzic/auto-cpufreq/issues/661
    patches = oldAttrs.patches ++ [ ./modifications/auto-cpufreq_pipe-log-spam.patch ];

    # manually creating the systemd service due to this one with overwrites not working...
    # (see /nixos/lnix/default.nix)
    postInstall = ''
      # copy script manually
      cp ${oldAttrs.src}/scripts/cpufreqctl.sh $out/bin/cpufreqctl.auto-cpufreq

      # systemd service
      mkdir -p $out/lib/systemd/system
      #cp ${oldAttrs.src}/scripts/auto-cpufreq.service $out/lib/systemd/system
    '';
  });
$ sc-status auto-cpufreq.service
○ auto-cpufreq.service - auto-cpufreq - Automatic CPU speed & power optimizer for Linux
     Loaded: loaded (/etc/systemd/system/auto-cpufreq.service; enabled; preset: enabled)
     Active: inactive (dead)
$ cat /etc/systemd/system/auto-cpufreq.service
[Unit]
After=multi-user.target
Description=auto-cpufreq - Automatic CPU speed & power optimizer for Linux
Wants=multi-user.target

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/ar5wxfgqbzc84zy1yimj1s0yf7a63qba-glibc-locales-2.38-44/lib/locale/locale-archive"
Environment="PATH=/nix/store/r9h133c9m8f6jnlsqzwf89zg9w0w78s8-bash-5.2-p15/bin:/nix/store/rk067yylvhyb7a360n8k1ps4lb4xsbl3-coreutils-9.3/bin:/nix/store/rk067yylvhyb7a360n8k1ps4lb4xsbl3-coreutils-9.3/bin:/nix/store/q7x6rjg6ya1gsg068fxj1sgf1k2n144n-findutils-4.9.0/bin:/nix/store/r1lp9kxlrc6h7vrba90gm6i94s31xvvx-gnugrep-3.11/bin:/nix/store/29w8hg0fis0pl3j4d3v0p02aicyw10lv-gnused-4.9/bin:/nix/store/dzp7d4k1d94s1x49p9171mvcsfyxr7bj-systemd-254.6/bin:/nix/store/r9h133c9m8f6jnlsqzwf89zg9w0w78s8-bash-5.2-p15/sbin:/nix/store/rk067yylvhyb7a360n8k1ps4lb4xsbl3-coreutils-9.3/sbin:/nix/store/rk067yylvhyb7a360n8k1ps4lb4xsbl3-coreutils-9.3/sbin:/nix/store/q7x6rjg6ya1gsg068fxj1sgf1k2n144n-findutils-4.9.0/sbin:/nix/store/r1lp9kxlrc6h7vrba90gm6i94s31xvvx-gnugrep-3.11/sbin:/nix/store/29w8hg0fis0pl3j4d3v0p02aicyw10lv-gnused-4.9/sbin:/nix/store/dzp7d4k1d94s1x49p9171mvcsfyxr7bj-systemd-254.6/sbin"
Environment="TZDIR=/nix/store/i6nk8llh46f2xjzc5h8j83kwwr1w3kx0-tzdata-2024a/share/zoneinfo"
ExecStart=/nix/store/yfmy07a1fsjvkly4f7s46rcq4293radg-python3.11-auto-cpufreq-1.9.9/bin/auto-cpufreq --daemon --config /nix/store/ssbbdkqwf1xj5ywysfnch7i2ginqc1cp-auto-cpufreq.conf
Restart=on-failure
Type=simple
User=root
WorkingDirectory=

@stusmall
Copy link
Contributor

stusmall commented Jun 8, 2024

For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: services.power-profiles-daemon.enable = false;

From looking at this code, and be kind with me here since I'm a nix beginner, while this is off by default it is enabled when using gnome.

I think the best action would be to add an assertion to give users a prompt like with tlp
. If this looks correct I can open a PR for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: bug Something is broken
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants