Quantcast
Channel: Serverphorums.com - HAProxy
Viewing all 11674 articles
Browse latest View live
↧

Un placement en diamant qui rapporte 6,50%/ an garantie par banque

March 14, 2016, 6:10 am
$
0
0
*|MC:SUBJECT|*
Un placement en diamant dont la valeur augmente
et qui rapporte 6,50% / an.*
*Taux annuel garantie par banque
Payé chaque année sur votre compte bancaire.
EN SAVOIR PLUS
" Déflation, taux d'intérêt négatifs… C'est un nouveau langage auquel les épargnants vont devoir s'habituer s'ils veulent comprendre ce qui arrive à leurs placements, et faire les bons choix."
" Placer son cash aujourd’hui est devenu un véritable casse-tête. Les produits court terme et sans risque rapportent de moins en moins. Quelles sont les alternatives ?"
INVESTISSEZ !
↧
Search

[SPAM] Votre complément de retraite à partir de 19€/mois

March 14, 2016, 8:30 am
$
0
0
Afficher la version web. (http://trk.mix.espoir17.com/view/zjo-63DIk.php) | Annuler votre abonnement. (http://trk.mix.espoir17.com/usb/zjo-63DIk.php) | Signaler comme courrier indésirable. (mailto:abuse@dgcnit.fr)

http://trk.mix.espoir17.com/tk/zjo-63DIk-zgY.php
#http://trk.mix.espoir17.com/tk/zjo-63DIk-zgY.php
http://trk.mix.espoir17.com/tk/zjo-63DIk-zgY.php N°1 de la retraite complémentaire, destinée aux Agents, anciens Agents de la Fonction Publique et leurs conjoints (http://trk.mix.espoir17.com/tk/zjo-63DIk-zgY.php)

http://trk.mix.espoir17.com/tk/zjo-63DIk-zgY.php Un régime sûr et solide, qui ouvre droit à une déduction fiscale annuelle(1) (http://trk.mix.espoir17.com/tk/zjo-63DIk-zgY.php)

http://trk.mix.espoir17.com/tk/zjo-63DIk-zgY.php Le montant de votre complément retraite est garanti à vie (http://trk.mix.espoir17.com/tk/zjo-63DIk-zgY.php)

Préfon-Distribution, 12 bis rue de Courcelles 75 008 Paris, N° ORIAS 13008416

Chez Préfon, nous sommes transparents.
Communication à caractère publicitaire.
Les caractéristiques présentées, dont les conditions et limites sont détaillées dans la notice d'information, dépendent également de la législation en vigueur. Elles sont susceptibles d'évoluer.

Les renvois des mentions qui figurent dans cet email :
(1) Sous réserve de la fiscalité en vigueur. Chaque année, les cotisations versées – annuelles et de rachat – sont déductibles du revenu global du foyer fiscal à hauteur de 10% des revenus d'activité professionnelle nets de cotisations sociales et de frais professionnels, retenus dans la limite de 8 fois le Plafond Annuel de la Sécurité Sociale de l'année précédente. Le plafond de déduction est commun à l'ensemble des dispositifs d'épargne retraite. Votre plafond d'épargne retraite est mentionné sur votre avis d'imposition. Le régime Préfon-Retraite est un régime de retraite dont les arrérages sont passibles de l'impôt sur le revenu dans les mêmes conditions que les « pensions et retraites ».

Informations sur Préfon-Retraite
Préfon-Retraite est un contrat d'assurance de groupe, régime régi par les articles L. 441-1 et suivants du Code des assurances, dont l'objet est la constitution et le service d'une retraite par rente au profit des affiliés.
Il est souscrit par Préfon, la Caisse nationale de prévoyance de la fonction publique, association régie par la loi du 1er juillet 1901 ayant son siège social 12 bis rue de Courcelles 75 008 Paris. L'objet social de l'association est d'offrir aux fonctionnaires et assimilés des régimes de prévoyance complémentaire, notamment en matière de retraite ; d'assurer la représentation des affiliés auprès des pouvoirs publics et des gestionnaires des régimes créés ; de veiller au respect des valeurs des organisations syndicales fondatrices de solidarité, de progrès social et d'égalité dans la gestion des fonds collectés par les régimes créés, notamment par le choix d'investissements socialement responsables.
Il est distribué par la SAS Préfon Distribution au capital social de 200 000 € entièrement libéré. 794 053 629 R.C.S. Paris immatriculée à l'ORIAS sous le n° 13008416 et ayant son siège social au 12 bis rue de Courcelles 75 008 Paris.

Retrouvez toutes nos informations sur : www.prefon-retraite.fr (http://trk.mix.espoir17.com/tk/zjo-63DIk-zgX.php)


Conformément à la loi "Informatique et Liberté" n° 78-17 du 6 janvier 1978 modifiée, vous bénéficiez d'un droit d'accès, de rectification, d'opposition et de suppression des données vous concernant.
Vous souhaitez vous désinscrire de cette liste ? Cliquez ici. (http://trk.mix.espoir17.com/usb/zjo-63DIk.php)
↧
↧

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

March 14, 2016, 12:00 pm
$
0
0
Hello Willy,

Le 14/03/2016 09:53, Willy Tarreau a écrit :
> I find this strange, it would mean that glibc would perform file system
> accesses for each call to localtime() which doesn't match my observations
> (would be terribly slow for logging).

Yes, localtime() can do an access to /etc/localtime each time it's
called, contrary to localtime_r(), like stated in the man page:
According to POSIX.1-2004, localtime() is required to behave as
though tzset(3) was called, while localtime_r() does not have this
requirement. For portable code, tzset(3) should be called before
localtime_r().

This is a small test showing that's the case even with recent version of
glibc (if TZ is *not* set):
bunch@bunchlinux:~/src/time$ cat localtime.c
#include <time.h>

int main(int argc, char *argv[])
{
time_t t;
struct tm *tm;
int i = 5;

while (i--) {
time(&t);
tm = localtime(&t);
}
}

bunch@bunchlinux:~/src/time$ gcc localtime.c -o localtime && strace
../localtime 2>&1 | grep /etc/localtime
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2971, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2971, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2971, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2971, ...}) = 0

bunch@bunchlinux:~/src/time$ uname -a
Linux bunchlinux 4.2.0-30-generic #35-Ubuntu SMP Fri Feb 19 13:52:26
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

But this is not a problem, since haproxy uses localtime_r() which is not
as brain dead!
Anyway, older version of strftime() also used to call tzset() (or an
internal variant), that's why I'm very nervous about my previous patch
used inside a chroot().

>> Another more portable solution is to code an equivalent of
>> strftime(..."%z"...) with no call to tzset().
>> We can get back to an GMT time and extract the GMT offset from that. It
>> would be slow, but we'd only do this twice, once for each tm_isdst value.
> Doesn't this bring us back to the initial principle of caching the offset
> for each possible value ?

Yes, it's the current patch but basically replacing strftime(..."%z"...)
by mktime()+gmtime_r()+tm_diff().
Please note that this will be done only twice, to populate the cache on
demand. After all, we're just trying to get a time offset from GMT, so
why not retrieving GMT time and computing a simple difference?
As I already said, the glibc already does this internally if not
compiled in BSD compatibility mode.

None of the functions called will do any timezone trickery (BTW,
gmtime_r() and mktime() are already used by haproxy and tm_diff() is
really simple math).
I'll send a patch on top of the previous patch, but please gimme some
time to test it extensively, I don't want to do another mistake.

> Willy
>
Benoit GARNIER
↧

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

March 14, 2016, 12:50 pm
$
0
0
Hi Benoit,

On Mon, Mar 14, 2016 at 07:49:14PM +0100, Benoît GARNIER wrote:
> Le 14/03/2016 09:53, Willy Tarreau a écrit :
> > I find this strange, it would mean that glibc would perform file system
> > accesses for each call to localtime() which doesn't match my observations
> > (would be terribly slow for logging).
>
> Yes, localtime() can do an access to /etc/localtime each time it's
> called, contrary to localtime_r(), like stated in the man page:
> According to POSIX.1-2004, localtime() is required to behave as
> though tzset(3) was called, while localtime_r() does not have this
> requirement. For portable code, tzset(3) should be called before
> localtime_r().
>
> This is a small test showing that's the case even with recent version of
> glibc (if TZ is *not* set):
> bunch@bunchlinux:~/src/time$ cat localtime.c
> #include <time.h>
>
> int main(int argc, char *argv[])
> {
> time_t t;
> struct tm *tm;
> int i = 5;
>
> while (i--) {
> time(&t);
> tm = localtime(&t);
> }
> }
>
> bunch@bunchlinux:~/src/time$ gcc localtime.c -o localtime && strace
> ./localtime 2>&1 | grep /etc/localtime
> open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2971, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2971, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2971, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2971, ...}) = 0

Ugly indeed.

> bunch@bunchlinux:~/src/time$ uname -a
> Linux bunchlinux 4.2.0-30-generic #35-Ubuntu SMP Fri Feb 19 13:52:26
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> But this is not a problem, since haproxy uses localtime_r() which is not
> as brain dead!

Ah OK, otherwise I would clearly have noticed!

> Anyway, older version of strftime() also used to call tzset() (or an
> internal variant), that's why I'm very nervous about my previous patch
> used inside a chroot().

Got it, thanks for the explanation. So now all what matters is to know
whether there are people running haproxy with the %Tl log tag (added in
2012) on distros that ship an older glibc. Simply stated, we'll see, and
if that breaks we can easily revert it. We try as much as possible to be
regression-free but we don't always succeed and it happened a few times
already that a fix broke something.

> >> Another more portable solution is to code an equivalent of
> >> strftime(..."%z"...) with no call to tzset().
> >> We can get back to an GMT time and extract the GMT offset from that. It
> >> would be slow, but we'd only do this twice, once for each tm_isdst value.
> > Doesn't this bring us back to the initial principle of caching the offset
> > for each possible value ?
>
> Yes, it's the current patch but basically replacing strftime(..."%z"...)
> by mktime()+gmtime_r()+tm_diff().
> Please note that this will be done only twice, to populate the cache on
> demand. After all, we're just trying to get a time offset from GMT, so
> why not retrieving GMT time and computing a simple difference?

That was my first proposal, to have one offset per DST computed before
chrooting :-)

> As I already said, the glibc already does this internally if not
> compiled in BSD compatibility mode.
>
> None of the functions called will do any timezone trickery (BTW,
> gmtime_r() and mktime() are already used by haproxy and tm_diff() is
> really simple math).
> I'll send a patch on top of the previous patch, but please gimme some
> time to test it extensively, I don't want to do another mistake.

Don't worry. I've released all pending versions yesterday evening, there
were several much more serious issues that were causing trouble to users
and needed to be fixed, so we'll queue your next fix for next releases.
Take your time, as I said in the worst case if someone faces a problem we
can simply revert your fix, there's no real problem with that as long as
you don't feel offended by a revert of course (I probably have the record
of number of reverts).

Willy
↧

Re: PATCH 1/1: OPTIM: args

March 14, 2016, 1:00 pm
$
0
0
Hi again,

There is the same changes made in one patch to make the review more
effective as the changes, finally, depend to each other.

Cheers.

On 14 March 2016 at 09:00, David CARLIER <devnexen@gmail.com> wrote:

> Hi all,
>
> This patch is in fact not exactly an OPTIM's kind but did not find any
> better ...
> After a discussion with Willy about the need to increase the number of
> arguments list for sample fetch / convertors hence the patch which is up to
> 12. The change applied in the sample part will follow.
>
> About backporting to 1.6 or not ... Well there is some pros and cons, I
> leave the decision to the commiters :-) If the patches are merged, I will
> apply changes to DeviceAtlas module as well in the near future.
> Thanks in advance.
>
↧
↧

Re: [PATCH] BUG/MINOR: log: GMT offset not updated when entering/leaving DST

March 14, 2016, 3:40 pm
$
0
0
Hi Willy,

Le 14/03/2016 20:40, Willy Tarreau a écrit :
>> Anyway, older version of strftime() also used to call tzset() (or an
>> internal variant), that's why I'm very nervous about my previous patch
>> used inside a chroot().
> Got it, thanks for the explanation. So now all what matters is to know
> whether there are people running haproxy with the %Tl log tag (added in
> 2012) on distros that ship an older glibc. Simply stated, we'll see, and
> if that breaks we can easily revert it. We try as much as possible to be
> regression-free but we don't always succeed and it happened a few times
> already that a fix broke something.

Good point, but I don't know the status of chroot()+strftime() on
non-linux platforms.

>>>> Another more portable solution is to code an equivalent of
>>>> strftime(..."%z"...) with no call to tzset().
>>>> We can get back to an GMT time and extract the GMT offset from that. It
>>>> would be slow, but we'd only do this twice, once for each tm_isdst value.
>>> Doesn't this bring us back to the initial principle of caching the offset
>>> for each possible value ?
>> Yes, it's the current patch but basically replacing strftime(..."%z"...)
>> by mktime()+gmtime_r()+tm_diff().
>> Please note that this will be done only twice, to populate the cache on
>> demand. After all, we're just trying to get a time offset from GMT, so
>> why not retrieving GMT time and computing a simple difference?
> That was my first proposal, to have one offset per DST computed before
> chrooting :-)

No, here I meant to compute on demand the needed offsets at runtime (as
I did in my patch), because at that time we have valid date/is_dst
combinations.
Anyway, that was a nice try, but a very bad idea: even if not stated in
the man page, mktime() calls tzset() and resets the timezone to GMT if
it cannot open /etc/localtime.
I could skip the mktime() part, but the interface would be ugly, I would
have to pass both time_t and the matching local struct tm at the same
time to the function.
So this solution can be eliminated now. I'm in the situation where I
don't have any elegant solution for older systems.

> Don't worry. I've released all pending versions yesterday evening, there
> were several much more serious issues that were causing trouble to users
> and needed to be fixed, so we'll queue your next fix for next releases.
> Take your time, as I said in the worst case if someone faces a problem we
> can simply revert your fix, there's no real problem with that as long as
> you don't feel offended by a revert of course (I probably have the record
> of number of reverts).

Well, no, I won't be offended if you revert my previous patch.
It fixed a bug, but if it introduces a regression it should be reverted
since I have no real solution for now.
It's up to you, such is the life of a BDFL! :-)

> Willy
Benoit GARNIER
↧

Your Website

March 14, 2016, 4:10 pm
$
0
0
Hi,



Hope you are keeping well.--



I am Ruchi, Website Expert.



We had gone through your website: www.formilux.org Would you be interested
in a possible Web Development and Search Engine Optimization of the site or
additional features that might benefit the overall usability and user
experience which usually leads to better sales. Google's research data shows
over 85% of people search for your products/services through search engines
and buy as well. These statistics also influence other channels and buying
medium as well.



I would like to request you for an opportunity to work and AMAZE you with
our service. We wish you the best of luck and looking forward to a long and
healthy business relationship with you and your company.



We use effective online project management tracking tools and ensure timely
and smooth communication.



We have expertise in the following areas:-



.. Professional Site Design,

.. Mobile compatible website design,

.. eShop/Online Payment Gateway Integration,

.. Credit Card Payment gateway Integration.

.. Joomla, WP, PHP Based sites etc



Give us a chance to see what we can do for your website and business. We
won't take you through binding contract unless you are absolutely happy with
our work



If our services are of any interest for you then please do contact us by
replying to us and our web consultants will be in touch with you to assist
you in all your requirements related to your website and business.

Looking forward to hear from you!



Kind Regards,



Ruchi

Website Expert



Karol Bagh

New Delhi (India)



Kindly reply back with "unsubscribe" to us if you don't wish to receive any
emails from us in future.
↧

ECDIS Navigation Display

March 14, 2016, 4:40 pm
$
0
0
Thismessagecontainsgraphics.Ifyoudonotseethegraphics,clickheretovie=w.=20=20=20=20=20=20=20=20=20=20=20FormoredetailsinformationaboutECDIS,Pleasevisitourwebsite:www.ewinsonic.com=20=208863370478988633704722sales@ewinsonic.com=
↧
Search

Fiber stick use for car perfume

March 14, 2016, 8:00 pm
$
0
0
Dear&nbsp;purchasing&nbsp;manager:Hello,&nbsp;this&nbsp;Jenifer&nbsp;from&nbsp;Weihai&nbsp;company&nbsp;in&nbsp;China,&nbsp;our&nbsp;company&nbsp;is&nbsp;a&nbsp;professional&nbsp;fiber&nbsp;stick&nbsp;(Fiber&nbsp;stick&nbsp;for&nbsp;car&nbsp;parfum,&nbsp;Fiber&nbsp;nibs,&nbsp;PE&nbsp;nibs,&nbsp;PE&nbsp;stick,&nbsp;Natural&nbsp;Rattan,&nbsp;Eyeliner&nbsp;pen&nbsp;nibs,&nbsp;Filter&nbsp;cotton&nbsp;core)manufacturer&nbsp;with&nbsp;years‘s&nbsp;&nbsp;experience.&nbsp;so&nbsp;we&nbsp;want&nbsp;to&nbsp;avail&nbsp;ourselves&nbsp;of&nbsp;opportunity&nbsp;establishing&nbsp;business&nbsp;relation&nbsp;with&nbsp;you.By&nbsp;the&nbsp;way,&nbsp;free&nbsp;sample&nbsp;are&nbsp;available.Thank&nbsp;you&nbsp;in&nbsp;advance!Best&nbsp;regards&nbsp;JeniferE&nbsp;mail:&nbsp;admin@weihaisz.comAddress:&nbsp;14&nbsp;Building&nbsp;Juzhi&nbsp;Industrial&nbsp;Zone，&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PingLong&nbsp;Road,&nbsp;PingHu&nbsp;Town,ShenZhenWeb:&nbsp;www.weihaisz.com&nbsp;Tel:+86-0755-84008869Fax:+86-0755-84008859Mob:+86-13713888018&nbsp;
↧
↧

EBD滚动周计划负荷分析

March 14, 2016, 9:40 pm
$
0
0
haproxy 附件供您参考

------------------ 原始邮件 ------------------
发件人: info@bycert.com
发送时间: 2016年2002-1-9 下午1:48:07
收件人: haproxy@formilux.org
抄送: 莫经理
主题: 答复: 滚动周计划负荷分析
↧

必须有效监管产品开发过程

March 15, 2016, 2:00 am
$
0
0
详情请参阅附件...

---------------- 原始邮件 ------------------
发件人: 黄课长
发送时间: 2016年2016-3-16 下午16:58:56
收件人: haproxy
抄送: 沈经理
主题: 答复: 有效监管产品开发
↧

peers and stick-table stats

March 15, 2016, 2:30 am
$
0
0
Hi,


Is there any good way to monitor stick-table utilization?
Also searching for any nice stats on peer replication (connectivity, fails
etc)

It doesn't seems that stats endpoint return any of this info.
Appreciate your feedback.

thnx

--
BR,
Pavlo Zhuk
↧

Asking for help: how to expire haproxy's stick table entry only after the closing of all sessions which used it

March 15, 2016, 6:30 am
$
0
0
Hi, my name is Hugo.

I'm currently using Haproxy 1.5, I have a backend with 2 servers. My app
servers receive connection from two clients and I want both of them to be
attributed to the same server. All connections have a url parameter X and
sessions that should be attributed to the same server have the same url
parameter X value. I use a stick table to save the server that a particular
url parameter value uses so that future connections can be attributed to
the same server.

I want to be able to add app servers as load increases. In order to
instruct haproxy to move previous connections to the new app server I need
to expire stick table entries when no session (of either client) is active
in the server.

Can you help me with this?

Thanks in advance for any kind of help.

Best Regards,

Hugo Maia
↧
↧

Re: Asking for help: how to expire haproxy's stick table entry only after the closing of all sessions which used it

March 15, 2016, 11:10 am
$
0
0
Greetings Hugo,

On 03/15/2016 09:25 AM, Hugo Maia wrote:
>
> Hi, my name is Hugo.
>
> I'm currently using Haproxy 1.5, I have a backend with 2 servers. My
> app servers receive connection from two clients and I want both of
> them to be attributed to the same server. All connections have a url
> parameter X and sessions that should be attributed to the same server
> have the same url parameter X value. I use a stick table to save the
> server that a particular url parameter value uses so that future
> connections can be attributed to the same server.
>
> I want to be able to add app servers as load increases. In order to
> instruct haproxy to move previous connections to the new app server I
> need to expire stick table entries when no session (of either client)
> is active in the server.
>
Table values can be changed by sending "set table <table> key <key>
data.<type> <value>" to the HAProxy socket ('socat stdio
/var/run/haproxy.sock'). "table" is the name of the section the table
is in, "key" is the key in the table, "type" is the datatype set in the
type argument to stick table (integer/ip/string/etc), and "value" is
what you want the value to be set to.

I don't think there is a good way to delete/expire stick table entires
via the socket, however (entirely possible there is and I just
overlooked it once I latched onto changing values).

So if I'm reading your problem correctly you should be able to have a
script change the value it wanted to expire to the new server instead of
removing it.

- Chad
>
> Can you help me with this?
>
> Thanks in advance for any kind of help.
>
> Best Regards,
>
> Hugo Maia
>
↧

Re: peers and stick-table stats

March 15, 2016, 11:10 am
$
0
0
Greetings Pavlo,

On 03/15/2016 05:23 AM, Pavlo Zhuk wrote:
> Hi,
>
>
> Is there any good way to monitor stick-table utilization?
The first line of a "show table" socket command has the "size" field
(showing the size as set in the config) and the "used" field (showing
how many entries are currently used). For example running 'echo "show
table <name>" | socat stdio /var/run/haproxy.sock | head -n1' will print:
# table: <name>, type: <type>, size:1048576, used:12331
> Also searching for any nice stats on peer replication (connectivity,
> fails etc)
I'm not aware of statistics for peer replication which can be extracted
from HAProxy during runtime. Someone else might be able to fill in that
point.

- Chad
>
> It doesn't seems that stats endpoint return any of this info.
> Appreciate your feedback.
>
> thnx
>
> --
> BR,
> Pavlo Zhuk
>
↧
Search

Dassault Systemes Directory

March 15, 2016, 11:20 am
$
0
0
Hi,

Would you be interested in Dassault Systemes Users You can approach the Information Security Decision Makers from Technology & Security industry.


* Our leads database contains information like First and Last name, Phone number, Email Address, Company Name, Job Title, Address, City, State, Zip, SIC code/Industry, Revenue and Company Size. The leads can also be further customized as per requirements.


* We provide 100% accurate data of the Companies who are using the mentioned security system:


* Autodesk

* Siemens PLM

* PTC and many more...


* We also have other Technology Users like - SAP, Oracle, Salesforce and Microsoft etc.


* Please review and let me know if you are interested in any of the technology users or different contact list for your campaigns and I will provide more information for the same.


* Target Criteria: ____________

* Target Titles: _____________

* Target Geography: ____________

Appreciate your time and look forward to hear from you.

Thanks,
Emma Megan

If you are not the right person, feel free to forward this email to the right person in your organization.
↧

Re: PATCH 1/1: OPTIM: args

March 15, 2016, 11:50 am
$
0
0
Hi David,

On Mon, Mar 14, 2016 at 07:54:24PM +0000, David CARLIER wrote:
> Hi again,
>
> There is the same changes made in one patch to make the review more
> effective as the changes, finally, depend to each other.

Great. I just spotted this, are you sure there isn't a mistake ?

> -/* encoding of the arg count : up to 5 args are possible. 4 bits are left
> +/* encoding of the arg count : up to 12 args are possible. 4 bits are left
> * unused at the top.
> */
> #define ARGM_MASK ((1 << ARGM_BITS) - 1)
> -#define ARGM_BITS 3
> -#define ARGM_NBARGS (32 - ARGM_BITS) / sizeof(int)
> +#define ARGM_BITS 4
> +#define ARGM_NBARGS (128- ARGM_BITS) / sizeof(int64_t)

This 128 should very likely be 64 since we're moving to 64 bits.
Also I'm having a hard time understanding why the number of bits
is divided by the size of an int in either case. I guess it should
have been something like this instead :

(before)
#define ARGM_BITS 3
#define ARGM_NBARGS (sizeof(int) * 8 - ARGM_BITS) / ARGT_BITS

(after)
#define ARGM_BITS 4
#define ARGM_NBARGS (sizeof(int64_t) * 8 - ARGM_BITS) / ARGT_BITS

Indeed, we need to subtract the number of bits needed to count args from
the whole int size, and divide it by the size of each individual arg to
get the total number of args. The original version only happened to work
by pure luck because sizeof(int) == ARGT_BITS! I think that deserves a
fix in older versions eventhough it's a minor bug which cannot have any
impact as-is.

And in your case, that used to work as well because (128-4)/8 = 15.5
instead of 15.0, both of which are rounded down to 15.

I remember that we always reserve one entry for ARGT_STOP, so the max
usable number of args is 14 here. What do you think ?

Just another detail here :

- unsigned int arg_mask; /* arguments (ARG*()) */
+ int64_t arg_mask; /* arguments (ARG*()) */

It's nicer to leave it unsigned (uint64_t), as seeing negative numbers for
bitfields it really annoying when debugging.

Thanks!
willy
↧
↧

Help! HAProxy randomly failing health checks!

March 15, 2016, 12:00 pm
$
0
0
Hello!

My name is Zack, and I have been in the middle of an on going HAProxy issue that has me scratching my head.

Here is the setup:

Our setup is hosted by amazon, and our HAProxy (1.6.3) boxes are in each region in 3 regions. We have 2 HAProxy boxes per region for a total of 6 proxy boxes.

These boxes are routed information through route 53. Their entire job is to forward data from one of our clients to our database backend. It handles this absolutely fine, except between the hours of 7pm PST and 7am PST. During these hours, our route53 health checks time out thus causing the traffic to switch to the other HAProxy box inside of the same region.

During the other 12 hours of the day, we receive 0 alerts from our health checks.

I have noticed that we get a series of SSL handshake failures (though this happens throughout the entire day) that causes the server to hang for a second, thus causing the health checks to fail. During the day our SSL failures do not cause the server to hang long enough to go fail the checks, they only fail at night. I have attached my HAProxy config hoping that you guys have an answer for me. Lemme know if you need any more info.

I have done a few tcpdump captures during the SSL handshake failures (not at night during it failing, but during the day when it still gets the SSL handshake failures, but doesn’t fail the health check) and it seems there is a d/c and a reconnect during the handshake.

Here is my config, I will be running a tcpdump tonight to capture the packets during the failure and will attach it if you guys need more info.

#---------------------------------------------------------------------
# Example configuration for a possible web application. See the
# full configuration options online.
#
# http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
#
#---------------------------------------------------------------------

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
log 127.0.0.1 local2

pidfile /var/run/haproxy.pid
maxconn 30000
user haproxy
group haproxy
daemon
ssl-default-bind-options no-sslv3 no-tls-tickets
tune.ssl.default-dh-param 2048

# turn on stats unix socket
# stats socket /var/lib/haproxy/stats`

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option httplog
retries 3
timeout http-request 5s
timeout queue 1m
timeout connect 31s
timeout client 31s
timeout server 31s
maxconn 15000

# Stats
stats enable
stats uri /haproxy?stats
stats realm Strictly\ Private
stats auth $StatsUser:$StatsPass

#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------

frontend shared_incoming
maxconn 15000
timeout http-request 5s

# Bind ports of incoming traffic
bind *:1025 accept-proxy # http
bind *:1026 accept-proxy ssl crt /path/to/default/ssl/cert.pem ssl crt /path/to/cert/folder/ # https
bind *:1027 # Health checking port
acl gs_texthtml url_reg \/gstext\.html ## allow gs to do meta tag verififcation
acl gs_user_agent hdr_sub(User-Agent) -i globalsign ## allow gs to do meta tag verififcation

# Add headers
http-request set-header $Proxy-Header-Ip %[src]
http-request set-header $Proxy-Header-Proto http if !{ ssl_fc }
http-request set-header $Proxy-Header-Proto https if { ssl_fc }

# Route traffic based on domain
use_backend gs_verify if gs_texthtml or gs_user_agent ## allow gs meta tag verification
use_backend %[req.hdr(host),lower,map_dom(/path/to/map/file.map,unknown_domain)]

# Drop unrecognized traffic
default_backend unknown_domain

#---------------------------------------------------------------------
# Backends
#---------------------------------------------------------------------

backend server0 ## added to allow gs ssl meta tag verification
reqrep ^GET\ /.*\ (HTTP/.*) GET\ /GlobalSignVerification\ \1
server server0_http server0.domain.com:80/GlobalSignVerification/

backend server1
server server1_http server1.domain.net:80

backend server2
server server2_http server2.domain.net:80

backend server3
server server3_http server3.domain.net:80

backend server4
server server4_http server4.domain.net:80

backend server5
server server5_http server5.domain.net:80

backend server6
server server6_http server6.domain.net:80

backend server7
server server7_http server7.domain.net:80

backend server8
server server8_http server8.domain.net:80

backend server9
server server9_http server9.domain.net:80

backend unknown_domain
timeout connect 4s
timeout server 4s
errorfile 503 /etc/haproxy-shared/errors/404.html
↧

Re: PATCH 1/1: OPTIM: args

March 15, 2016, 12:20 pm
$
0
0
Hi and thanks.
Attached the patch with the related changes.


> Great. I just spotted this, are you sure there isn't a mistake ?
>
>
It is indeed :), my initial plan was (64 - ARGM_BITS) / sizeof(int) which
is still wrong althought I assumed wrongly apparently the result
represented all the bits included the ones not used.


>
>
> I remember that we always reserve one entry for ARGT_STOP, so the max
> usable number of args is 14 here. What do you think ?
>
> Just another detail here :
>
> - unsigned int arg_mask; /* arguments (ARG*()) */
> + int64_t arg_mask; /* arguments (ARG*()) */
>
> It's nicer to leave it unsigned (uint64_t), as seeing negative numbers for
> bitfields it really annoying when debugging.
>
>
Ok no problems.


> Thanks!
> willy
>
>
↧

[PATCH] BUG/MINOR: log: Don't use strftime() which can clobber timezone if chrooted

March 15, 2016, 1:30 pm
$
0
0
From 6d89510559e6eeaa867555a76ca9fbe65b1a9a1c Mon Sep 17 00:00:00 2001
From: Benoit GARNIER <chezbunch+haproxy@gmail.com>
Date: Sun, 27 Mar 2016 03:04:16 +0200
Subject: [PATCH] BUG/MINOR: log: Don't use strftime() which can clobber
timezone if chrooted

The strftime() function can call tzset() internally on some platforms.
When haproxy is chrooted, the /etc/localtime file is not found, and some
implementations will clobber the content of the current timezone.

The GMT offset is computed by diffing the times returned by gmtime_r() and
localtime_r(). These variants are guaranteed to not call tzset() and were
already used in haproxy while chrooted so should be safe.

This patch must be backported to 1.6 and 1.5.
---
include/common/standard.h | 6 ++--
src/log.c | 4 +--
src/standard.c | 76 ++++++++++++++++++++++++++++++++++-------------
3 files changed, 62 insertions(+), 24 deletions(-)

diff --git a/include/common/standard.h b/include/common/standard.h
index 353d0b0..cd2208c 100644
--- a/include/common/standard.h
+++ b/include/common/standard.h
@@ -871,10 +871,11 @@ extern const char *monthname[];
char *date2str_log(char *dest, struct tm *tm, struct timeval *date, size_t size);

/* Return the GMT offset for a specific local time.
+ * Both t and tm must represent the same time.
* The string returned has the same format as returned by strftime(... "%z", tm).
* Offsets are kept in an internal cache for better performances.
*/
-const char *get_gmt_offset(struct tm *tm);
+const char *get_gmt_offset(time_t t, struct tm *tm);

/* gmt2str_log: write a date in the format :
* "%02d/%s/%04d:%02d:%02d:%02d +0000" without using snprintf
@@ -885,10 +886,11 @@ char *gmt2str_log(char *dst, struct tm *tm, size_t size);

/* localdate2str_log: write a date in the format :
* "%02d/%s/%04d:%02d:%02d:%02d +0000(local timezone)" without using snprintf
+ * Both t and tm must represent the same time.
* return a pointer to the last char written (\0) or
* NULL if there isn't enough space.
*/
-char *localdate2str_log(char *dst, struct tm *tm, size_t size);
+char *localdate2str_log(char *dst, time_t t, struct tm *tm, size_t size);

/* These 3 functions parses date string and fills the
* corresponding broken-down time in <tm>. In succes case,
diff --git a/src/log.c b/src/log.c
index ab38353..4d496cd 100644
--- a/src/log.c
+++ b/src/log.c
@@ -979,7 +979,7 @@ static char *update_log_hdr_rfc5424(const time_t time)

tvsec = time;
get_localtime(tvsec, &tm);
- gmt_offset = get_gmt_offset(&tm);
+ gmt_offset = get_gmt_offset(time, &tm);

hdr_len = snprintf(logheader_rfc5424, global.max_syslog_len,
"<<<<>1 %4d-%02d-%02dT%02d:%02d:%02d%.3s:%.2s %s ",
@@ -1495,7 +1495,7 @@ int build_logline(struct stream *s, char *dst, size_t maxsize, struct list *list

case LOG_FMT_DATELOCAL: // %Tl
get_localtime(s->logs.accept_date.tv_sec, &tm);
- ret = localdate2str_log(tmplog, &tm, dst + maxsize - tmplog);
+ ret = localdate2str_log(tmplog, s->logs.accept_date.tv_sec, &tm, dst + maxsize - tmplog);
if (ret == NULL)
goto out;
tmplog = ret;
diff --git a/src/standard.c b/src/standard.c
index e08795f..0ec4900 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -2552,31 +2552,66 @@ char *date2str_log(char *dst, struct tm *tm, struct timeval *date, size_t size)
return dst;
}

+/* Base year used to compute leap years */
+#define TM_YEAR_BASE 1900
+
+/* Return the difference in seconds between two times (leap seconds are ignored).
+ * Taken from glibc source code.
+ */
+static int tm_diff(const struct tm *a, const struct tm *b)
+{
+ /* Compute intervening leap days correctly even if year is negative.
+ * Take care to avoid int overflow in leap day calculations,
+ * but it's OK to assume that A and B are close to each other.
+ */
+ int a4 = (a->tm_year >> 2) + (TM_YEAR_BASE >> 2) - ! (a->tm_year & 3);
+ int b4 = (b->tm_year >> 2) + (TM_YEAR_BASE >> 2) - ! (b->tm_year & 3);
+ int a100 = a4 / 25 - (a4 % 25 < 0);
+ int b100 = b4 / 25 - (b4 % 25 < 0);
+ int a400 = a100 >> 2;
+ int b400 = b100 >> 2;
+ int intervening_leap_days = (a4 - b4) - (a100 - b100) + (a400 - b400);
+ int years = a->tm_year - b->tm_year;
+ int days = (365 * years + intervening_leap_days
+ + (a->tm_yday - b->tm_yday));
+ return (60 * (60 * (24 * days + (a->tm_hour - b->tm_hour))
+ + (a->tm_min - b->tm_min))
+ + (a->tm_sec - b->tm_sec));
+}
+
/* Return the GMT offset for a specific local time.
+ * Both t and tm must represent the same time.
* The string returned has the same format as returned by strftime(... "%z", tm).
* Offsets are kept in an internal cache for better performances.
*/
-const char *get_gmt_offset(struct tm *tm)
+const char *get_gmt_offset(time_t t, struct tm *tm)
{
/* Cache offsets from GMT (depending on whether DST is active or not) */
static char gmt_offsets[2][5+1] = { "", "" };

- int old_isdst = tm->tm_isdst;
char *gmt_offset;
-
- /* Pretend DST not active if its status is unknown, or strftime() will return an empty string for "%z" */
- if (tm->tm_isdst < 0) {
- tm->tm_isdst = 0;
- }
-
- /* Fetch the offset and initialize it if needed */
- gmt_offset = gmt_offsets[tm->tm_isdst & 0x01];
- if (unlikely(!*gmt_offset)) {
- strftime(gmt_offset, 5+1, "%z", tm);
- }
-
- /* Restore previous DST flag */
- tm->tm_isdst = old_isdst;
+ struct tm tm_gmt;
+ int diff;
+ int isdst = tm->tm_isdst;
+
+ /* Pretend DST not active if its status is unknown */
+ if (isdst < 0)
+ isdst = 0;
+
+ /* Fetch the offset and initialize it if needed */
+ gmt_offset = gmt_offsets[isdst & 0x01];
+ if (unlikely(!*gmt_offset)) {
+ get_gmtime(t, &tm_gmt);
+ diff = tm_diff(tm, &tm_gmt);
+ if (diff < 0) {
+ diff = -diff;
+ *gmt_offset = '-';
+ } else {
+ *gmt_offset = '+';
+ }
+ diff /= 60; /* Convert to minutes */
+ sprintf(gmt_offset+1, "%02d%02d", (diff/60)%100, diff%60);
+ }

return gmt_offset;
}
@@ -2616,16 +2651,17 @@ char *gmt2str_log(char *dst, struct tm *tm, size_t size)

/* localdate2str_log: write a date in the format :
* "%02d/%s/%04d:%02d:%02d:%02d +0000(local timezone)" without using snprintf
- * * return a pointer to the last char written (\0) or
- * * NULL if there isn't enough space.
+ * Both t and tm must represent the same time.
+ * return a pointer to the last char written (\0) or
+ * NULL if there isn't enough space.
*/
-char *localdate2str_log(char *dst, struct tm *tm, size_t size)
+char *localdate2str_log(char *dst, time_t t, struct tm *tm, size_t size)
{
const char *gmt_offset;
if (size < 27) /* the size is fixed: 26 chars + \0 */
return NULL;

- gmt_offset = get_gmt_offset(tm);
+ gmt_offset = get_gmt_offset(t, tm);

dst = utoa_pad((unsigned int)tm->tm_mday, dst, 3); // day
*dst++ = '/';
--
2.5.0
↧
Viewing all 11674 articles
Browse latest View live
Search