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
nixos/auto-upgrade: add persistent option #107957
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code LGTM. Tested in the field, all my hosts updated.
Commit message and CONTRIBUTING.md, not to excessively nitpick, but this should be "nixos/auto-upgrade: add persistent option", otherwise it doesn't say what we're adding the option to. See most other commits on services for reference
4c3405c
to
7ed9eec
Compare
Oh, sure. Updated. Thanks! |
nixos/modules/tasks/auto-upgrade.nix
Outdated
type = types.str; | ||
default = "daily"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why change the old default?
But if we do need to change it anyway, I think this may needs some documentation in the changelog for the next release 🤔 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because of security. Currently if you just enable auto-upgrade it will never run on laptop (unless you keep it running over night, but who does it with laptops?). So user might expect to get security fixes, but he doesn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought just setting persistent = true
fixed this issue. Does it not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I read systemd manual, but I am not sure if persistent applies to a specific date/time. It looked it applies only to intervals, but I might be wrong. Do you know it better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can confirm it does apply to specific date/times based on a month of using it in my config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll revert to original specific date/times. One last question, if set to 4:40, that is very early morning, does it mean that for laptop it always tries to run it as soon as it finishes booting? Would like to know how it behaves with daily. I'd like to avoid every such timer expiring right after boots finishes... Would be better to spread it out more... But eh, probably just trying to find good spot where there are none, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the manpage give us the answer:
Persistent=
Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. Such triggering is nonetheless subject to the delay imposed by RandomizedDelaySec=. This is useful to catch up on missed runs of the service when the system was powered down. Note that this setting only has an effect on timers configured with OnCalendar=. Defaults to false.
Use systemctl clean --what=state … on the timer unit to remove the timestamp file maintained by this option from disk. In particular, use this command before uninstalling a timer unit. See systemctl(1) for details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll return defaults back to original value. Do you agree?
default = true; | ||
type = types.bool; | ||
example = false; | ||
description = '' | ||
Takes a boolean argument. If true, the time when the service | ||
unit was last triggered is stored on disk. When the timer is | ||
activated, the service unit is triggered immediately if it | ||
would have been triggered at least once during the time when | ||
the timer was inactive. Such triggering is nonetheless | ||
subject to the delay imposed by RandomizedDelaySec=. This is | ||
useful to catch up on missed runs of the service when the | ||
system was powered down. | ||
''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, think it needs documentation, but I think this is less controversial since persistent = true
makes more sense for this service.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know what documentation (where) exactly? If I can, I would update it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know exactly, I think maybe it is only filled after the release is tagged 🤔 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Release notes for Okapi are over there:
<title>Backward Incompatibilities</title> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the systemd.services.nixos-upgrade
needs to be altered too to include after = [ "network-online.target" ];
(and maybe "network.target"
too? I am not sure if only "network-online.target"
is sufficient), otherwise the service will fail during restart because of the lack of network access.
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ says:
So, I do what it says. |
7ed9eec
to
406d7de
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
I decided to give a try and test the PR to make sure everything is alright. My {
# Backport module from unstable.
imports = [
/home/thiagoko/Projects/nixpkgs/nixos/modules/tasks/auto-upgrade.nix
];
disabledModules = [ "tasks/auto-upgrade.nix" ];
system.autoUpgrade = {
enable = true;
dates = "daily";
};
} And this is the result: ~/Projects/nixpkgs nixos/auto-upgrade 14s
❯ systemctl cat nixos-upgrade.timer
# /nix/store/qcv8x0xp01yn5zpz0nffk6y6zx7qdjn3-unit-nixos-upgrade.timer/nixos-upgrade.timer
[Unit]
[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=0
~/Projects/nixpkgs nixos/auto-upgrade
❯ systemctl cat nixos-upgrade.service
# /nix/store/ivsfnlkw0ckf2s3qh7d12f795yq83hgj-unit-nixos-upgrade.service/nixos-upgrade.service
[Unit]
After=network-online.target
Description=NixOS Upgrade
Wants=network-online.target
X-StopOnRemoval=false
[Service]
Environment="HOME=/root"
Environment="LOCALE_ARCHIVE=/nix/store/a2px4kdz1jm03f8ifr1pzir0csfmyrlv-glibc-locales-2.31/lib/locale/locale-archive"
Environment="NIX_PATH=nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/>
Environment="PATH=/nix/store/z1qvlavy35wanw5k54fvvfffws5bvigj-coreutils-8.31/bin:/nix/store/xlfmnfbqryr6s52xgaqfaljmiccrv2rk-gnutar-1.32>
Environment="TZDIR=/nix/store/w1g27pgslf28nh1py1szj7lk4xksdhqq-tzdata-2020c/share/zoneinfo"
X-RestartIfChanged=false
ExecStart=/nix/store/h45gf360a2h7pbq86b2kvqmyxn9dsz75-unit-script-nixos-upgrade-start/bin/nixos-upgrade-start
Type=oneshot So this seems 💯 . |
@tex Can you fix the merge conflict? |
@tex AFAIK we generally don't fix merge conflicts with merging other branches, but with a rebase. |
And I though I get from this easily by doing web-based merge conflict solve :) |
f8ef5e9
to
276f280
Compare
So here you are and please merge it. |
@tex Now that #107959 can you fix the merge conflict again? @SuperSandro2000 Do you know someone that can help reviewing this PR? |
I marked this as stale due to inactivity. → More info |
Still relevant. |
Not really. |
I marked this as stale due to inactivity. → More info |
I am still interested in this PR. I can give a review/merge now. @tex Sorry for the inconvenience. If you can rebase this PR I can review/merge ASAP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
But needs a rebase. After that i can merge it. Maybe i can rebase myself later today |
276f280
to
a5fb565
Compare
@thiagokokada feel free to review and merge please :) |
Motivation for this change
I am complaining about auto-upgrade not correctly working in laptop environment where laptop is turned on and off unpredictable causing those timers never expire and this service never executed.
Here is my fix.
I think that current situation is making this service unusable on laptops. Since it is auto upgrade that could lead to security issues as user might expect getting automatic updates while he is really not.
One can add this to his configuration.nix: systemd.timers.auto-upgrade.timerConfig.Persistent = true; but it is not apparent for users...
#15689
#75861
#107805
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)