On October 13, 2025 9:57:54 PM GMT+03:00, Adrian Chadd <[email protected]>
wrote:
>On Mon, 13 Oct 2025 at 11:22, Sulev-Madis Silber <
>[email protected]> wrote:
>
>>
>>
>> On October 13, 2025 9:06:02 PM GMT+03:00, Adrian Chadd <[email protected]>
>> wrote:
>> >...
>> >
>> >On Mon, 13 Oct 2025 at 03:23, Lexi Winter <[email protected]> wrote:
>> >
>> >> Olivier Certner wrote in <6142242.Zv9zXsTiuT@ravel>:
>> >> > > i suspect the fix will be in pkgbase somewhere: for example, we
>> >> > > could restart sendmail on upgrade, or tell the user to do that.
>> >> >
>> >> > Most probably it will need too, yes.
>> >>
>> >> proposed fix at https://reviews.freebsd.org/D53061. i really don't
>> like
>> >> this (nothing else restarts services on upgrade) but this is probably
>> the
>> >> least disruptive solution for users.
>> >>
>> >
>> >I'm curious - why are we NOT restarting services after an upgraded
>> package?
>> >
>> >
>> >-a
>>
>> i hope this wasn't proposal of blanket restarts everywhere. this could get
>> bad quickly. i recall friends cursing linux distros going one step further,
>> starting everything that's installed with default config
>>
>> many things would happily run after update, nginx even has special no
>> interrupt upgrade which replaces binary
>>
>> for sshd it would maybe ok but who knows. all around restarting is bad. at
>> least optout would be needed
>>
>> what if it needs config change or other kind of adjustments before admin
>> decides to restart it. or wants to choose time
>>
>>
>The only reason I'd like services not to be restarted is in case it's a
>last ditch attempt to recover a broken system.
>Otherwise:
>
>* your currently executing binary can be referencing libraries, files, etc
>which themselves are deleted but won't be freed until you kill the process;
>* the binary itself may be deleted, but it won't be freed until the process
>is killed;
>* the binary may be pointing to old paths / binaries / etc (think web
>servers, mail servers, etc) which no longer exist until you kill/restart
>the process (as ivy saw);
>
>So yes, i'd like services to be restarted when the package itself is
>reinstalled. This gets hilarious when you start thinking about the
>underlying libraries being upgraded and old ones being deleted, but like,
>in theory package management should handle that for me too as it should
>know all of those dependencies.
>
>If the package system doesn't do that then I'm going to need to reboot my
>system after a non-trivial package upgrade anyway, as a bunch of stuff may
>have changed and it may behave unpredictably until it reboots.
>
>
>
>-adrian
yes reboots are useful as a test too. and all up there are reasonable
but now you need to make sure that machine is not doing any work. i guess one
would say that machine should never be doing any useful work when you start
touching it
but this changes going live immediately would turn some of those practices
upside down where you upgrade and hope to later restart it in one go
and how to even restart? do you restart on every library being upgraded, and
finally for the binary itself?
i realize that leaving thing hanging there without binaries found or pulling a
lib out underneath would cause bad things to happen in some cases but isn't
that like being often done?
one other option would be to create complete new system and boot into it. that
would need data decoupling and so on
and when do you restart? some things might need stop first before you delete
the files off, then start. in the middle there's nothing running. hopefully
nothing accesses system then. eg you have made it externally impossible
but at least some situations i see much more interruptions
this messes up some admin brains for sure
also what order the things should get upgraded and restarted at? what if
package dep order is the wrong one?
also if you can't get the machine isolated, and you did just stop daemons, do
they come back up out of sequence as you upgrade?
yeah restarting things as upgrade goes would make entire life completely
different
maybe it helps on good sysadmin practices but you bet it raises ton of people
cursing like what you mean it got restarted, i thought i just upgraded it, i
meant to commit later or even maybe turn my actions back
if ports starts doing that, it needs warnings. many warnings
also what about those setups where install environment isn't really the run
environment? like one jail installs, other runs it from ro fs. i bet those are
special enough that admin is aware of it
btw, if this change would go into effect, where do people learn that? there are
number of cases of major release doing changes or about to do changes that are
being only told in release notes casually. like, btw, 32bit is deprecated, or
btw, different shell, or btw, home dir location changes. and person could be
like wow wow wow wait www... wh wha what? now hold on why i never knew
i recall
https://forums.freebsd.org/threads/ars-technica-article-focused-on-wireguard-regarding-freebsd.79537/
but i also recall other things. let's not make service autorestarting one of
them
i once had like honest question that nobody answered, why is breaking code
being introduced between alphas and betas and rc's? or between their versions?
isn't it like, alpha is where things don't work, beta is where things work, rc
when it's perfect and release when it's done? instead of that, mid-alpha is
where new nic driver appears, beta is where new zfs comes, etc. i didn't pull
out exact things but you get the idea. oh after the release we found out that
we need to patch it. the code that needed patching is only in that new release
good thing is that we still have those 1-2 older releases one can hang out in
and watch this freshly out of factory train running on either other people's
systems or in their test env
but that restarting, would it come from pkg or via certain release?
before freebsd was like where's the gas lever, we need to add some pace. now
it's like where's the brake handle, need to slow down?
i recall being very pissed about xo back then. that got others pissed
idea was good, i like json
now i was pointed at bugs in vmstat loop run. generates broken json. normal run
generates padded entries. then i found more bugs in w. padded entry. if you set
locale to one where decimal separator is comma, it directly goes out as invalid
json. i gave up on workload and was thinking of asking juniper itself if they
could allocate some time to this. i don't seem to have brain wired for reading
xo functions. i reported 2 of those bugs, 1 is still out. and i lost energy to
find more. yet i want it all to be nice warm and fuzzy
i don't know if it's inevitable that those things happen but i don't like bugs
but i admit that lost sshd in upgrade could be bug too, if it won't come up,
what then? pray and go back? in one place i had static dropbear as second means
to access. didn't have oob mgmt there. not all things have. so yeah, i don't
know what good way is. for ssh for other things
servers can be sysadminned in various ways depends on need. but i bet if all
services start restarting, there would be lot of (bad) surprises. and this
would be another change nobody notices
where/who/what was it, iirc here or somewhere near
it went like, change was presented in a file in bottom of a locked file cabinet
in a back room of office with sign beware of a dog
recently i found very bad bug in cu and maybe in sc(/getty?) that mysteriously
corrupts data and sends out to in and in sc, to other console as input. and was
asked if i knew that cu is old and buggy thing and no normal person uses it.
yet every example has it in. manpage has example of usb serials. looked recent
enough to me!
i mean how would one learn stuff if (s)he's not in "inner circle". things just
happen and without his/her control. that part i don't really like
in my entire path to this day from 4.6 i don't know how many things i are
supposed or not supposed to be using but so far it worked. like ntpdate is
deprecated but why is it still in? what's replacement, ntpd -g? but that was bg?
often changes could be found in last minute at worst possible time where you
can't get the system back up because you missed one line in some notes
could probably split it all up into smaller bits and put into better specific
fbsd design lists like arch@ but those are things i see
also, me, or perhaps many, don't see the behind scene talks, they just see the
end
eg with that boot loader issue. got people mad. i went and looked why that
change was made. turned out there was entire long thread where things went out
things went in. not all did fit. unfortunately end result pissed into coffee
cup of that particular admin and he took a big sip without looking
i bet that change where bridge members aren't supposed to have ip's is going to
bit many too for years to end. i can get the logic, but not fully. i mean this
is all happening inside same kernel anyway, so why? i think i had issues with
it in past and did realize this was a bad config but...
yes, those are changes that make people mad
i had people asking wtf is going on in fbsd. i just shrug and say i guess
somebody had an idea, that got traction and was implemented
eg, pkgbase. very good idea. supposedly old idea too. but nobody tried much.
there wasn't even a tiny nudge. all of sudden there was a big push and lot more
bugs popped out. i bet pkgbase bugs continue well into 15 and maybe even 16 or
more. that's a huge breaking change that needs production release testing.
because people apparently aren't using it before that much. you know, that
thing, let's wait until it gets ready, but it can be ready until you use it for
real. i do already. found bugs, reported. good
so yeah, changes can be difficult!
