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

nixos/auto-upgrade: add persistent option #107957

Merged
merged 1 commit into from Apr 16, 2022

Conversation

tex
Copy link
Contributor

@tex tex commented Dec 30, 2020

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
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

Copy link
Member

@bbjubjub2494 bbjubjub2494 left a 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

@tex
Copy link
Contributor Author

tex commented Dec 30, 2020

Oh, sure. Updated. Thanks!

@tex tex changed the title add persistent option nixos/auto-upgrade: add persistent option Dec 30, 2020
type = types.str;
default = "daily";
Copy link
Contributor

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 🤔 ?

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Comment on lines +103 to +142
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.
'';
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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 🤔 ?

Copy link
Member

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>

Copy link
Contributor

@thiagokokada thiagokokada left a 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.

@tex
Copy link
Contributor Author

tex commented Dec 30, 2020

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:

Cut the crap! How do I make sure that my service starts after the network is really online?

Well, that depends on your setup and the services you plan to run after it (see above). If you need to delay you service after the network is up, include

After=network-online.target
Wants=network-online.target

in the .service file.

So, I do what it says.

Copy link
Contributor

@thiagokokada thiagokokada left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/317

@thiagokokada
Copy link
Contributor

I decided to give a try and test the PR to make sure everything is alright. My /etc/nixos/configuration.nix:

{
  # 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 💯 .

@thiagokokada
Copy link
Contributor

@tex Can you fix the merge conflict?

@thiagokokada
Copy link
Contributor

@tex AFAIK we generally don't fix merge conflicts with merging other branches, but with a rebase.

@tex
Copy link
Contributor Author

tex commented Jan 31, 2021

And I though I get from this easily by doing web-based merge conflict solve :)

@tex tex force-pushed the nixos/auto-upgrade branch 2 times, most recently from f8ef5e9 to 276f280 Compare January 31, 2021 12:23
@tex
Copy link
Contributor Author

tex commented Jan 31, 2021

So here you are and please merge it.

@thiagokokada
Copy link
Contributor

@tex Now that #107959 can you fix the merge conflict again?

@SuperSandro2000 Do you know someone that can help reviewing this PR?

@stale
Copy link

stale bot commented Sep 3, 2021

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Sep 3, 2021
@TredwellGit TredwellGit removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Sep 3, 2021
@thiagokokada
Copy link
Contributor

Still relevant.

@SuperSandro2000
Copy link
Member

@SuperSandro2000 Do you know someone that can help reviewing this PR?

Not really.

@stale
Copy link

stale bot commented Apr 16, 2022

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Apr 16, 2022
@thiagokokada
Copy link
Contributor

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.

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Apr 16, 2022
Copy link
Member

@Lassulus Lassulus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm

@Lassulus
Copy link
Member

But needs a rebase. After that i can merge it. Maybe i can rebase myself later today

@Lassulus
Copy link
Member

@thiagokokada feel free to review and merge please :)

@thiagokokada thiagokokada merged commit 99b20f5 into NixOS:master Apr 16, 2022
@thiagokokada
Copy link
Contributor

Thanks @Lassulus for the rebase.

Thanks @tex for the original PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants