Page MenuHomePhabricator

SquidPurgeClient fails on FreeBSD; incorrect constants + MSG_EOR w/ SOCK_STREAM
Closed, ResolvedPublic


On FreeBSD, the new SquidPurgeClient fails to write to the socket it opens (and thus fails to purge from the cache) for a couple of reasons:

  • On FreeBSD, EAGAIN is 35, and EINPROGRESS is 36, which do not match the (linux?) constants defined in SquidPurgeClient.php, thus causing getSocket() to return false when it actually created the socket correctly:

  • On FreeBSD, setting MSG_EOR on a SOCK_STREAM socket (as done in doWrites()) will result in EINVAL, so even if it gets the sockets, writing to them fails:;im=bigexcerpts#L378
I believe you are only meant to use MSG_EOR with SOCK_SEQPACKET.

Adjusting the constants to match those of FreeBSD and changing the $flags parameter to 0 in doWrites fixed this problem for me on FreeBSD 8.1-RELEASE-p1. Perhaps there's a better way to detect these platform-specific constants?

For what it's worth, I also added in a few more writes for Varnish, because it won't purge gzip and deflate versions unless you ask. Not sure if it's required for Squid (and there might be a better way to do this in VCL, too), but it was much easier with the new architecture:

public function queuePurge( $url ) {

$urlparts = parse_url(str_replace( "\n", '', $url ));
$msg =  'PURGE ' . $urlparts['path'] . " HTTP/1.0\r\n" .
        'Host: ' . $urlparts['host'] . "\r\n".
        "Connection: Keep-Alive\r\n" .
        "Proxy-Connection: Keep-Alive\r\n" .
        'User-Agent: ' . Http::userAgent() . ' ' . __CLASS__ . "\r\n";
$this->requests[] = $msg . "\r\n";
$this->requests[] = $msg . "Accept-Encoding: gzip\r\n\r\n";
$this->requests[] = $msg . "Accept-Encoding: deflate\r\n\r\n";


Version: 1.16.x
Severity: normal

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:30 PM
bzimport set Reference to bz27658.
bzimport added a subscriber: Unknown Object (MLST).
Aklapper lowered the priority of this task from Medium to Low.Mar 25 2015, 4:07 PM
Smalyshev reopened this task as Open.May 18 2018, 5:40 PM
IijimaYun added a subscriber: IijimaYun.EditedJul 17 2018, 12:52 PM

Perhaps there's a better way to detect these platform-specific constants?


Try again.
Operation now in progress.
root@hosting w/includes/clientpool # uname -v
FreeBSD 11.2-STABLE #2 r335760: Thu Jun 28 23:08:51 JST 2018

root@hosting w/includes/clientpool # php --version
PHP 7.2.7 (cli) (built: Jun 29 2018 10:31:57) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.7, Copyright (c) 1999-2018, by Zend Technologies

root@hosting w/includes/clientpool # php -r 'echo "SOCKET_EAGAIN=" . SOCKET_EAGAIN . " and SOCKET_EINPROGRESS=" . SOCKET_EINPROGRESS . "\n";'

Note: this is still not fixed in 1.32.

IijimaYun added a comment.EditedJun 6 2019, 5:27 PM

Patch (removes EOR flag and uses PHP constants instead of hard-coded ones):

This patch avoids bad request errors from Varnish as the original sends the Accept-Encoding headers slightly incorrectly.

daniel added a subscriber: daniel.Jun 11 2019, 1:25 PM

At a glance, the patch looks like it's doing the right thing. PHP is supplying the correct constant values for the OS, we shouldn't use our own hard coded ones.

I'd suggest to not remove the class constants, though, but instead just assign them the value of the global constants, e.g.


@IijimaYun could you submit the patch to gerrit? That would make review easier. Though I have to admit that I'm not sure where to find anyone willing to verify the fix on FreeBSD...

Change 536761 had a related patch set uploaded (by Iijima Yun; owner: Iijima Yun):
[mediawiki/core@master] clientpool: Use PHP constants in SquidPurgeClient

Change 536761 merged by jenkins-bot:
[mediawiki/core@master] clientpool: Use PHP constants in SquidPurgeClient

CCicalese_WMF closed this task as Resolved.Nov 6 2019, 7:53 PM
CCicalese_WMF claimed this task.
CCicalese_WMF added a subscriber: CCicalese_WMF.

Please feel free to reopen if the patch did not fix this.