Re: openat("./...", O_CREAT) fails even though the directory exists
- Reply: Olivier Certner : "Re: openat("./...", O_CREAT) fails even though the directory exists"
- Reply: Marcin Cieslak : "Re: openat("./...", O_CREAT) fails even though the directory exists"
- In reply to: Olivier Certner : "Re: openat("./...", O_CREAT) fails even though the directory exists"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 13 Oct 2025 09:27:20 UTC
Olivier Certner wrote in <2507674.THHZn3L5Ee@ravel>:
> > 44288: fstatat(AT_FDCWD,"./df59D8I2px044288",0xecbda905210,0x0) ERR#2 'No such file or directory'
> > 44288: fstatat(AT_FDCWD,".",{ mode=drwxr-xr-x ,inode=129826,size=2,blksize=131072 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
> > 44288: geteuid() = 0 (0x0)
> > 44288: fstatat(AT_FDCWD,".",{ mode=drwxr-xr-x ,inode=129826,size=2,blksize=131072 },0x0) = 0 (0x0)
> > 44288: openat(AT_FDCWD,"./df59D8I2px044288",O_RDWR|O_CREAT|O_EXCL,0600) ERR#2 'No such file or directory'
> >
> > this doesn't make sense to me: since "." exists, how can openat() return
> > ENOENT here?
>
> How do you come to this conclusion? In what you pasted above, and in
> the full traces, the openat(AT_FDCWD) fails on the same file
> ("./df59D8I2px044288") on which the fstatat(AT_FDCWD) just above
> already failed with ENOENT. So the most plausible explanation is that
> that file just does not exist at this point.
the file should not exist, and this is expected. the truss output shows:
- "./df59D8I2px044288" does not exist: fstatat() returns ENOENT. this
is expected, because this is a new file we are trying to create (if it
existed, this would be a different error).
- "." exists: fstatat(AT_FDCWD, ".") returns 0
- trying to create "./df59D8I2px044288", which doesn't exist, with
O_CREAT|O_EXCL fails with ENOENT.
the issue is in the last item: since this file doesn't exist, and we're
opening it with O_CREAT, how can this fail?
after some more debugging, i think what's going on here is that pkg(8)
is deleting and recreating /var/spool/mqueue on upgrade, which means
smmsp's open fd to that directory is no longer valid, and therefore
openat() returns this unusual error.
i am not sure how to fix this, but the impact is that upgrading the
FreeBSD-sendmail package breaks sendmail on a running system, so we
need to fix this somehow for 15.0. i suspect the fix will be in pkgbase
somewhere: for example, we could restart sendmail on upgrade, or tell
the user to do that.