On Fri, 28 Aug 2020 08:32:59 +0200, Sebastien Marie <sema...@online.fr> wrote:
> On Thu, Aug 27, 2020 at 03:27:58PM -0400, Daniel Jakots wrote: > > Hi, > > > > I'm chasing a weird behavior with postgresql. Sometimes (it's very > > infrequent) a sql request fails with "could not send data to client: > > Permission denied". I reported the problem on pgsql-general@ [0] > > and if I understood correctly, this happens when pgsql uses send(2) > > and gets EACCES. > > > > According to send(2) this happens when "The connection was blocked > > by pf(4)". I have a cron that modifies a table with > > `pfctl -t TABLE_NAME -Tr -f TABLE_FILE_PATH` > > > > The file is large so it's not exactly immediate. Could pf > > temporarily block new connections while it loads the file? Or am I > > looking at the wrong thing? > > > > From your pf rules, does the postgresql connection could be blocked if > TABLE_NAME is empty/inconsistent ? > > Could you add (if you don't have already tested it), an explicit > allow rule for postgresql to ensure the connection will success ? They are distinct rules: # grep -e api_bans -e 5432 /etc/pf.conf table <api_bans> persist file "/etc/pf.api" block drop in quick from <api_bans> pass in on vio0 proto tcp from $docker3 to (self) port 5432 pass in on vio0 proto tcp from $web1 to (self) port 5432 The thing is that it happens very rarely, and I'm not sure how to reproduce it. > From my reading, pfctl -Treplace is using DIOCRSETADDRS ioctl. On > userland side, it tries to do it in one step (see > src/sbin/pfctl/pfctl_table.c line 228), but could iterate on > pfr_set_addrs() (I am unsure if the change is atomic or if the > iteration is to ensure the change will be atomic with large enough > buffer for result). > > The DIOCRSETADDRS ioctl on kernel side is done under PF_LOCK(). But I > didn't check if the match rule would be done under PF_LOCK() or not > (I am not familiar enough with pf(4) code to find the code which do > the check). Merci, Daniel
