Hi, all, A couple of years ago, I wrote a perl script that ran a specified number of ssl_crtd processes with simultaneous requests to expose the problem and test the resolution. I’ve attached it below in case it would help test/diagnose the situation. It has hard-coded paths at the top of the script that would need to be updated for any particular test environment, and its testing certificate directory would need to be prepared in advance just as for a regular instance of squid running ssl_crtd. I initially investigated the problem and helped improve the database file locking problem by changing the locking protocol from lockf() to flock(). I haven’t seen the problem occur on FreeBSD since the flock() changes went in. However, when I last looked at the code, some operating systems were still configured to use lockf() locking which does not function as needed due to its unintuitive POSIX / X/Open semantics: the first close() on the locked file (even via a different file descriptor) releases the lock. MacOS’s man page notes "File locks are released on first close by the locking process of any file descriptor for the file”. There are situations in the ssl_crtd code where the database file is open using multiple file descriptors simultaneously, and close() calls occur that would cause read/write hazards due to loss of the lockf() lock. My $0.02, Guy > On Mar 4, 2017, at 11:36 AM, Eliezer Croitoru <eliezer@xxxxxxxxxxxx> wrote: > > Hey Alex, > > I still believe that an upgrade will improve since it's hard for me to imagine that only two admins are having trouble with it. > What will scare me is that If indeed many admins are having such issues and they do not ask or report about these. > I hope that with this thread we will be one step smarter and one step closer to a satisfying solution rather then the currently used options. > > Eliezer > > ---- > Eliezer Croitoru > Linux System Administrator > Mobile: +972-5-28704261 > Email: eliezer@xxxxxxxxxxxx > > > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] > Sent: Friday, March 3, 2017 5:56 PM > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Cc: Eliezer Croitoru <eliezer@xxxxxxxxxxxx> > Subject: Re: squid 3.5.2==> HTTPS FATAL: The ssl_crtd helpers are crashing too rapidly, need help! > > On 03/03/2017 06:17 AM, Eliezer Croitoru wrote: > >> one of the options is to fence the ssl_crtd with some kind of lock >> mechanism for the DB rebuild time. > > ssl_crtd already has a lock mechanism. If that mechanism is buggy, it > needs to be fixed, but it does not make sense to add another one. > > There is still a lot of room for improvements, of course. For example, > compared to a log-monitoring watchdog mentioned by Yuri: > > * Teaching ssl_crtd to run a sysadmin-provided script on database > failures will allow the sysadmin to handle such failures almost > transparently to the users and may reduce configuration headaches > associated with ssl_crtd message text changes. > > * Teaching Squid to run a sysadmin-provided script on helper crashes > will allow the sysadmin to handle such failures more transparently to > the users and may reduce configuration headaches associated with helper > message text changes. > > > Alex. > > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users
Attachment:
stress-sslcrtd.perl
Description: Binary data
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
