Re: openat("./...", O_CREAT) fails even though the directory exists

On October 13, 2025 9:57:54 PM GMT+03:00, Adrian Chadd <adrian@freebsd.org> wrote:
>On Mon, 13 Oct 2025 at 11:22, Sulev-Madis Silber <
>freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote:
>
>>
>>
>> On October 13, 2025 9:06:02 PM GMT+03:00, Adrian Chadd <adrian@freebsd.org>
>> wrote:
>> >...
>> >
>> >On Mon, 13 Oct 2025 at 03:23, Lexi Winter <ivy@freebsd.org> 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!