<aanderse>
upstream switch-to-configuration to systemd!? :-O
<aanderse>
seems difficult, though
<andi->
I don't know.. they also have this ostree idea. Not sure who they treat config switching there.
<andi->
Also we are mostly doing lists of services that have been running that we get via DBus... no reason systemd couldn't just ship a `systemctl reconfigure` or whatever
<aanderse>
that'd be great
aminechikhaoui has quit [Ping timeout: 240 seconds]
aminechikhaoui has joined #nixos-systemd
aminechikhaoui has quit [Quit: Ping timeout (120 seconds)]
aminechikhaoui has joined #nixos-systemd
<arianvp>
It already exists
<arianvp>
it's called `systemctl isolate`
<arianvp>
`systemctl isolate default.target`
<arianvp>
problem is it kills processes that are not systemd-managed
<arianvp>
hence it kills your desktop manager etc
<arianvp>
but it works on servers great
<arianvp>
but also restaerts more than needed
<flokli>
so, systemd having an idea about multiple "generations" of unit files, and some sort of transactional behaviour has been popping up in discussions at all systems go for some years now
<flokli>
I think it not being handled yet might be also a reason for fedora silverblue to just say "if you want to update, reboot".
feepo has joined #nixos-systemd
<aanderse>
flokli: so the nginx reload thing
<flokli>
orr
<flokli>
yes
<flokli>
it's awful
<aanderse>
that service might be considered obsolete by what i'm working on now
<aanderse>
i agree
<flokli>
it should be handled properly, by having this indirection via /etc/, and a reloadCommand
<flokli>
I just wanted to make something backport-able to 20.03 first
<flokli>
but while doing so, realized I'm opening another can of worms
<flokli>
as the nginx -t "check config" command seems to not only try to create files, but also bind to ports…
<aanderse>
currently restartTriggers acts as both "reloadTriggers" (which doesn't exist) and "restartTriggers"
<aanderse>
there should be separate reloadTriggers and restartTriggers options
<arianvp>
aanderse: yess
<arianvp>
however this still doesnt' solve this problem in general
<arianvp>
e.g. postgres has options that require reload and others restart
<aanderse>
so now i added logic which says "cool you want reloadIfChanged? i can probably do that... so long as restartTriggers hasn't changed."
<aanderse>
arianvp: same with mysql, and this doesn't fix that problem
<aanderse>
but
<aanderse>
module authors have to deal with that
<flokli>
wait what, I don't understand the problem
<flokli>
we always need to restart if the underlying binary has changed
<arianvp>
yes correct
<flokli>
we always need to restart if any parts of the ExecStart has changed
<arianvp>
(or ExecStop)
<flokli>
yes
<flokli>
or ExecStartPre= and whatnot
<flokli>
all sort of options
<flokli>
but let's simplify this
<aanderse>
flokli: yes, but we might *also* need to restart the binary if OTHER things changed
<flokli>
yes
<aanderse>
so arianvp i actually had mysql in mind (which is the same as postgresql) with your exact thought
<flokli>
I'd advocate to default to restarting in most cases
<aanderse>
"some options require reloaded vs restarted"
<aanderse>
i'm not saying we should
<arianvp>
(one could split up your mysql config into two files; one with restartable and one with reloadable settings :P )
<aanderse>
but in theory
<aanderse>
a module author could grab a list of options which require a restart
<flokli>
if all unit options are still the same, and just the symlink location of the config (files) has changed, we might be able to run the reload script
<flokli>
but only then
<flokli>
in all other cases, we shoul just restart.
<aanderse>
and do some sort of logic on that
<aanderse>
forcing a restart when required, or a reload when not
<arianvp>
why is restarting nginx bad by the way?
<aanderse>
yes
<aanderse>
exactly
<aanderse>
flokli: i opted to make an explicit option instead of ExecStart+ExecStop for flexibility
<arianvp>
because dropping connections right?
<aanderse>
but
<flokli>
> aanderse: a module author could grab a list of options which require a restart
<{^_^}>
<LAMBDA>
<flokli>
I'd disagree
<flokli>
we might add sandboxing and whatnot
<aanderse>
what your saying is legit
<aanderse>
arianvp: its the worst
<arianvp>
(If only nginx had socket activation. restarting wouldnt be a problem)
<flokli>
and module authors don't necessarily understand when restarts need to happen
<arianvp>
it could just restart without dropping anything :P
<aanderse>
arianvp: i can't effectively use vanilla services.httpd because it restarts the web server
<flokli>
so better restart always if anything in the unit has changed
<flokli>
and if there's some way to handle reloads, use the reload.
<aanderse>
restarting a web server kills all active connections and gives you a dead page for a second or two
<flokli>
arianvp: having ways to smarter handle restarts is another optimization layer I'd propose ignorning for now
<flokli>
it doesn't prevent eventually dropping long-running connections.
<aanderse>
i still think there is value in having a place to put "restart my service if any of these things have changed" but i don't feel that strongly about it :)
<aanderse>
any reasonable solution that prevents me from having to restart apache when i change config, but restarts it when change the binary is a winner in my books
<arianvp>
this also sounds like a sane first step
<flokli>
so I'd again advocate for "restart always if any option has changed", and only reload if a reload command is set, the module author opted in for reloading, and no option (including the ExecStart line) has changed. This implies indirecting config files via environment.etc, so they're not part of the unit contents.
<flokli>
seems much cleaner to me than shifting the burden on "blacklisting" each individual systemd unit option on the planet to each individiual module author
<flokli>
better safe than sorry
<flokli>
and restarting is safer.
<aanderse>
flokli: in branch i linked against everything is explicit.... so it is shifting everything on module authors which is a negative as you mention, for sure
<arianvp>
nginx supports updating the server executable without downtime
<flokli>
arianvp: but again, this might be an application-specific thing. let's focus on getting the default semantics right.
<arianvp>
yes
<flokli>
I'll have a lot of time next week. Might draft some document explaining the different pros and cons. would need a perl magician to help me with the activation script parts.
<arianvp>
one sec I know ap erson
chloekek has joined #nixos-systemd
<chloekek>
I was summoned.
<arianvp>
^ chloekek is my Perl magician
<arianvp>
flokli: ask them questions when you need :P
<aanderse>
woo! perl magicians!
<chloekek>
$@% lingua romana perligata ~ ~ *poof*
<flokli>
chloekek: not this week ;-) but thanks for the offer, will get back to it :-)
<aanderse>
well flokli please keep us in the loop because this is of high interest to me :)
chloekek has quit [Quit: WeeChat 2.7]
<flokli>
Sure
<aanderse>
flokli++
<{^_^}>
flokli's karma got increased to 28
<arianvp>
arianvp--
<arianvp>
wow cant neg
<arianvp>
,help
<{^_^}>
Use `,` to list all commands, `,foo = Foo!` to define foo as "Foo!", `,foo =` to undefine it, `,foo` to output "Foo!", `,foo somebody` to send "Foo!" to the nick somebody
<arianvp>
,
<{^_^}>
Special commands: find tell locate expand inclusive-language random-pr - Commands sorted by use count, page 0 (use ,<n> to view page <n>): help libraries unstable escape'' paste declarative channels library tofu ping overlay unfree escape" -a pinning ifd profiling ask which-channel botsnack pr xml wololo cache nixlang++ xy fancy-uninstall imperative tofu-vim invite pills loot home-manager pointers runtimedeps matrixbridge smart-questions
<flokli>
arianvp: try to self-incrementing your karma ;-)