ive got a surface tablet at work running nixos. it mostly is used to view security cameras.

the machine is fairly low spec and bogs itself down after a coupke days, so id like it to auto reboot at 9am. i work a late shift and often don't leave til around 2am.

i guess we don't use cron anymore? i really don't understand how the systemd timers work... the wiki doesnt really give great details...

systemd.timers."autoreboot" = {

wantedBy = [ "timers.target" ];

timerConfig = {

  OnCalendar="*-*-* 9:00:00";                                     Unit = "autoreboot.service";

};

};

systemd.services."autoreboot" = {

script = ''

set -eu

${pkgs.coreutils}/run/current-system/sw/bin/reboot

'';

serviceConfig = {

Type = "oneshot";

User = "root";

};

};

the systemd target seems to be created, but it reports as dead when i check it...

any advice?

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 3 points 13 hours ago (2 children)

basically modified this.

the path i used was the output of which reboot

just swapped it to remove the ${pkgs.coreutils} but i suspect thats not right either

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 11 hours ago* (last edited 11 hours ago)

    just swapped it to remove the ${pkgs.coreutils} but i suspect thats not right either

    Just /run/current-system/sw/bin/reboot actually would work, although it relies on your system closure containing a reboot binary. That's a reasonably safe assumption to make on a NixOS system, but you might not want to do this with other packages.

    the path i used was the output of which reboot

    The reason that doesn't work is that the structure of packages and the structure of a NixOS fiile system are different. Consider this:

    $ ls -l $(readlink $(type -P reboot))
    lrwxrwxrwx 33 root root 9  1. Jan 1970  /nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot -> systemctl
    

    So the systemd package in the nix store has a bin subdirectory containing its binaries. However:

    $ ls -l /bin/reboot
    ls: cannot access '/bin/reboot': No such file or directory
    $ ls -l /bin/*
    lrwxrwxrwx 1 root root 74 Aug  1 06:31 /bin/sh -> /nix/store/dddwfz7nph37q3cjky9lhpy9kb90rrrx-bash-interactive-5.3p15/bin/sh
    

    NixOS doesn't, at least not really (/bin/sh must exist because the system syscall uses it). Instead binaries for "installed" packages (the technical term would be "packages which are part of the system closure") are symlinked to /run/current-system/sw/bin:

    $ type -P reboot
    /run/current-system/sw/bin/reboot
    $ ls -l /run/current-system/sw/bin/reboot
    lrwxrwxrwx 9 root root 66  1. Jan 1970  /run/current-system/sw/bin/reboot -> /nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot
    

    More accurately, building a NixOS system creates a sort of meta-package that contains a link farm to all installed binaries in the sw/bin directory, and that meta-package is symlinked to /run/current-system at activation/boot. (Not all package contents are symlinked into this meta-package, also see the NixOS option environment.pathsToLink.)

    Putting that together with what string interpolation of packages does... well, you kinda just have to look at/know the contents of the package you are referring to:

    $ nix repl
    Nix 2.34.8
    Type :? for help.
    nix-repl> pkgs = import <nixpkgs> { }
    
    nix-repl> "${pkgs.systemd}/bin/reboot"
    "/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot"
    
    nix-repl> "${pkgs.systemd}/run/current-system/sw/bin/reboot"
    "/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/run/current-system/sw/bin/reboot"
    

    One of these paths exists, the other doesn't.

    Side note: You're looking at the old and mostly abandoned wiki, don't use that. There's an official wiki which is better. This particular article happens to be the same in both, but the old wiki also has tons of outdated and terrible articles like For Beginners or NixOS Woke Invasion.

  • source
  • parent