21
submitted 2 days ago by dadarobot@lemmy.ml to c/nix@programming.dev

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?

top 12 comments
sorted by: hot top controversial new old
[-] vividspecter@aussie.zone 10 points 2 days ago

This line:

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

is incorrect, as you've mixed a package path with an absolute path. Additionally, on my system at least, reboot is a part of pkgs.systemd and not pkgs.coreutils.

So this should work:

${pkgs.systemd}/bin/reboot

Or, since systemd is always installed on NixOS systems, you can use the absolute wrapper path:

/run/current-system/sw/bin/reboot
[-] dadarobot@lemmy.ml 4 points 2 days ago

excellent, thank you! in the future, how would i determine which package and path to use?

[-] Oinks 6 points 2 days ago

For installed packages, you can use readlink:

$ readlink $(type -P reboot)
/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot

The NixOS search can also search for binaries. It seems that busybox also provides a reboot which I guess might be useful for weird systemd-less deployments?

If you want to search for any file across all packages, there's also nix-index, which scrapes Hydra for output files and builds a database which you can then query with nix-locate.

[-] dadarobot@lemmy.ml 3 points 2 days ago

thank you so much for the information!

[-] jet@hackertalks.com 4 points 2 days ago* (last edited 2 days ago)

The reboot service isn't running because it's not time to reboot.

systemctl status autoreboot.timer

systemctl list-timers --all

[-] dadarobot@lemmy.ml 3 points 2 days ago

thanks for replying. the system has about a 24hr uptime from me rebooting last night, so it did not reboot at 9am.

autoreboot.timer Loaded: loaded (/etc/systemd/system/autoreboot.timer; enab> Active: active (waiting) since Thu 2026-07-30 19:36:04 CDT> Invocation: 0ebb672bd44e4efbb2a11aace109043b

Trigger: Sat 2026-08-01 09:00:00 CDT; 10h left                 Triggers: � autoreboot.service

Sat 2026-08-01 09:00:00 CDT 10h Fri 2026-07-31 09:00:02 CDT 13h ago autoreboot.timer autoreboot.service

hmm looks like everything ran except it didn't actually reboot. ill investigate more.

thank you!

[-] jet@hackertalks.com 3 points 2 days ago

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

This doesn't look right

[-] dadarobot@lemmy.ml 3 points 2 days ago

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

[-] jet@hackertalks.com 3 points 2 days ago

"${pkgs.systemd}/bin/systemctl --no-block reboot";

maybe something like this, but for testing just touch a file and see if it actually is triggering for you

[-] Oinks 2 points 2 days ago* (last edited 2 days 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.

[-] dadarobot@lemmy.ml 2 points 2 days ago

thank you for the information!

[-] dadarobot@lemmy.ml 1 points 2 days ago

thanks everyone, i have confirmed the system rebooted properly at 9am today. i just used the direct path without the package variable thing.

this post was submitted on 01 Aug 2026
21 points (100.0% liked)

Nix / NixOS

2819 readers
1 users here now

Main links

Videos

founded 3 years ago
MODERATORS