<{^_^}>
#64922 (by yorickvP, 1 week ago, open): systemd-timesyncd fails at step STATE_DIRECTORY on semi-clean install
<samueldr>
cc andi-
magnetophon has quit [Remote host closed the connection]
<aristid>
samueldr: yeah this laptop has been running unstable since way before stateVersion existed
<aristid>
and i guess i never set one :D
<samueldr>
hmm
<samueldr>
uuuuugh, I guess it would break even more stuff to set stateVersion to something like 00.00 by default
<samueldr>
since the default has been that none is like the latest :/
<samueldr>
(I think?)
<aristid>
i'm happy to just set it to something that works, for now
<samueldr>
tohugh I think you have a legit case of not having a stateVersion on your system
<yorick>
ah, this again
<samueldr>
I think there was head-scratching about users not having stateVersion set
<aristid>
samueldr: i set up this laptop in 2015
<yorick>
yeah, I think failure to set state version means "I don't care about state" for me
<aristid>
and have been rolling nixos-unstable ever since
<aristid>
yorick: in 2015 it didn't exist and i was never forced to set it and i didn't have any real issues until now... so i never set it :P
<yorick>
samueldr: maybe it should be mandatory
<aristid>
yeah, either make it work
<aristid>
without it set
<aristid>
or make it mandatory
<aristid>
the current state of affairs where some stuff is just weirdly broken is not great
<aristid>
so what do i need to set the stateVersion to? 19.03?
<yorick>
aristid: yes, or you can rm -rf /var/run/systemd-timesyncd
<yorick>
aristid: make a PR for mandatory :)
<aristid>
the rm -rf did not work
<aristid>
yay, deleting /var/lib/systemd/timesync is what really helped
<aristid>
yorick: also i feel like this "fix" was using stateVersion for something wrong. i think stateVersion is for stuff like databases, not things that a system activation script could fix up
<aristid>
there's another problem with this: it assumes people don't use nixos-unstable!
<samueldr>
nixos-unstable has stateVersion since stateVersion was instroduced, and is more about a "schema" of all state (including some service's) than datatabases only
<samueldr>
one of the mistakes might have been to tie it to the nixos release version numbering scheme
<aristid>
samueldr: well this was clearly a change significantly after 19.03
<aristid>
or did i just not notice the issue for multiple months? (possible, i guess)
<samueldr>
if one was to run a postgreSQL database on unstable without stateVersion in the upgrade from IIRC 17.09 to 18.03 it would have affected them
<aristid>
yeah but i don't run a postgres on my laptop :D
<samueldr>
there only a few places where it ended up being used, thankfully
<aristid>
samueldr: if stateVersion was a running counter instead of the nixos release string i think i could tolerate it much better
<globin>
it does not assume people don't run unstable, you generally always keep stateVersion where you started out
<samueldr>
globin: I think there might be issues with the "unset" use case here
<samueldr>
not sure if it's specific to the timesyncd one though
<aristid>
globin: what i meant is that changes in unstable that affect the stateVersion cannot be really represented with the stateVersion because it uses the release names
<aristid>
so in theory you would need to make sure to time those changes to coincide exactly with the release dates
<samueldr>
stateVersion defaults to `cfg.release` :/
<aristid>
samueldr: i'll make the PR to make it mandatory, but i don't expect it will actually be merged. nonetheless, this is a discussion that needs to be had.
<aristid>
infinisil: i think a simple running counter could work too
<aristid>
when you make a change that breaks stuff, you IMMEDIATELY increment that counter
<samueldr>
aristid: when a new release is cut, cfg.release is increased, so a nixos-generate-config on nixos-unstable on the day following the cutting of the new release is not an issue
<aristid>
in the same git commit
<samueldr>
aristid: I agree, I made the case in a PR already
<adisbladis>
infinisil: What would the ergonomics of that be? I have a hard time seeing how that would work.
<samueldr>
this was in addition to being user-hostile in the naming and looking like where you'd upgrade your system version
<infinisil>
adisbladis: Not sure about the ergonomics, but the usecase is that you can migrate the state from different modules independently
<adisbladis>
infinisil: The use case is awesome :)
<infinisil>
And it makes a lot of sense
<adisbladis>
I'm not understanding how it would work in practice though
<infinisil>
It's like a version number for modules
<infinisil>
adisbladis: Possibly every module could have its stateVersion option (if it needs it, could be done with some mkStateVersion function)
<adisbladis>
stateVersion now is nice because it's just the one number, it can easily be embedded in everyones config without much fuzz.
<samueldr>
the ergonomics are weird, since you can't assume "unset == latest", and users are unlikely to know they need to configure it unless they're pestered by the configuration to do so
<adisbladis>
infinisil: The bit I don't understand is how that would be expressed in my config
<infinisil>
Although, users won't have that set in their modules by default
<infinisil>
adisbladis: It would work just like stateVersion, in that you have to write it as an option value
<samueldr>
if you assume unset == epoch 0, then new installs will still use the old state scheme :/
<adisbladis>
infinisil: Oh so by default config has no epoch?
<infinisil>
samueldr: Yeah, so we'd have to force users to set it to the default value
<adisbladis>
And you can pin a service at an older one?
<samueldr>
so, the story is "on first upgrade requiring a module state epoch, pester the user to choose"?
<infinisil>
adisbladis: Yeah, a bit like pinning
<infinisil>
samueldr: Yeah.. it's not very nice
<samueldr>
so in actuality it's "for new users past the addition of module state, always be pestered"
<samueldr>
yeah
<infinisil>
But something like that would be ideal
<adisbladis>
I don't like the UX :/
<adisbladis>
Tough the intent is great
<infinisil>
I mean, that doesn't sound too bad actually, when you enable postgresql, you get "Please specify services.postgres.stateVersion = 0 to prevent problems when updating to future versions"
<aristid>
uh, i forgot how to make an option mandatory :D
<aristid>
can somebody remind me?
<infinisil>
aristid: Just don't declare any default value :)
<adisbladis>
infinisil: Hmm... It's probably not as bad as I think. There are not that many modules that actually care about stateVersion currently anyway.
<infinisil>
adisbladis: Yeah, it's rarely used
<samueldr>
the message is likely to be "set stateVersion to 0 if you were already using the module, to ${current} for new installations."
<infinisil>
And the UX for module authors is that they can just increase the default value for stateVersion in the relevant module itself when updating it in an incompatible way
<adisbladis>
infinisil: I like it =)
<adisbladis>
That's _much_ better than the current situation
<aristid>
i guess when i make the PR i shouldn't make the branch in the nixpkgs repo
<aristid>
last time i did that people were unhappy :D
<infinisil>
Ohhh, or even, `stateVersion = "9.4"` for postgres version 9.4
<infinisil>
You can have program-specific state versions
<samueldr>
infinisil: that's not likely a good idea :/
<infinisil>
Ah yeah upon second thought maybe not
<samueldr>
imagine if the idea is to change the superuser defaults
<aristid>
infinisil: too fine-grained becomes maintenance nightmare IMHO
<infinisil>
Okay just a simple integer then :)
<samueldr>
and as usual, the idea should be to strive never to need stateVersion
<aristid>
lol, using nixpkgs git you do kind of need a beefy machine given how huge the repo is these days
<infinisil>
samueldr: Yeah, stateVersion is probably only really needed if it's dangerous to do a migration automatically
<infinisil>
aristid: I think shallow clones should work
<infinisil>
And then with mkStateVersion we could even put migration documentation in the option description
<infinisil>
To look up how to update the postgres stateVersion you just have to look at that options description
<infinisil>
mkStateVersion { name = "postgres"; migrations = [ { target = 1; description = "Do this and that to migrate to this state"; } ]; }
<aristid>
infinisil: how would you make sure that for every relevant module, a value is actually set? or would you just always assume the oldest possible version by default?
<infinisil>
Yeah not sure about that one, but it would be fancy if you then could ask "How do i get from 0 to 2" and it would list steps from 0 to 1 and 1 to 2
<infinisil>
aristid: For every relevant module?
<aristid>
infinisil: the "how do i get from 0 to 2" could also be done with a global counter :-)
<aristid>
like when you commit a change that increases the current maximum counter you'd have to give a description to what changed and how to migrate
<infinisil>
Ah
<infinisil>
aristid: Simple: the current default value of stateVersion is the number of items the list has
<infinisil>
s/default/current
<aristid>
"the current current value"?
<infinisil>
Hehe, I mean, it's still a default value, just not one that gets accepted without users explicitly setting it
<infinisil>
Such a migration list would translate to a type `enum (range 0 (length list))`, and a message "Set services.foo.stateVersion = ${length list} to make sure it works for future updates"
<infinisil>
(and you don't actually need a `target` attribute because that could be inferred from the index in the list, but it might still be nice to have that just for visibility)
<infinisil>
Ohh, and with this we could even deprecate support for older stateVersions easily, just add an assertion for stateVersion being higher than some value
<infinisil>
With a nice migration warning
Jackneill has joined #nixos-dev
Drakonis has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
Jackneill has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Client Quit]
pie_ has joined #nixos-dev
<yorick>
I don't expect systemd-timesyncd to have state, hence I don't expect to have to set stateVersion on a 'stateless' system