hello Guys i do confirm that the issue resolved on the version 3.5.24 thanks all
> On Mar 6, 2017, at 4:33 PM, Guy Helmer <guy.hel...@gmail.com> wrote: > > 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 <elie...@ngtech.co.il> 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: elie...@ngtech.co.il >> >> >> -----Original Message----- >> From: Alex Rousskov [mailto:rouss...@measurement-factory.com] >> Sent: Friday, March 3, 2017 5:56 PM >> To: squid-users@lists.squid-cache.org >> Cc: Eliezer Croitoru <elie...@ngtech.co.il> >> Subject: Re: [squid-users] 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@lists.squid-cache.org >> http://lists.squid-cache.org/listinfo/squid-users > > <stress-sslcrtd.perl> > > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
