search for: res_init

Hello. I have some doubts about this commit: 09d60499af3acef2ba9bd7be15e8d1c44249f8d5 Always call res_init() before getaddrinfo(). Im not sure if this is really a good idea to call res_init() so often. In UNIX, resolv.conf does NOT really change.. and if it changes ever.. its not a problem to restart affected processes. Does anyone think about any ill-effects res_init() can do when called often? Leaks...

...ninitialized -I. -I.. -I. -I./.. -I/usr/local/openssl-0.9.7b/include -I/opt/zlib/include -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -DHAVE_CONFIG_H -c getrrsetbyname.c getrrsetbyname.c: In function `getrrsetbyname': getrrsetbyname.c:191: warning: implicit declaration of function `res_init' getrrsetbyname.c:207: warning: implicit declaration of function `res_query' getrrsetbyname.c:265: `T_SIG' undeclared (first use in this function) getrrsetbyname.c:265: (Each undeclared identifier is reported only once getrrsetbyname.c:265: for each function it appears in.) getrrsetbyna...

When the unprivileged child has chrooted it can no longer open /etc/resolv.conf, so if the resolver hasn't yet initialized itself then dns lookups will not be possible. This is unfortunately what normally happens, but sshd falls back gracefully. There are a couple of wrinkles: the resolver will typically try talking to a nameserver on the local host by default (using INADDR_ANY rather than

...v.conf is changed while a program is > running, glibc doesn't automatically notice this. Since tinc 1.0.25 and > 1.1pre11, if you send tincd the ALRM signal, it will force glibc to > reload /etc/resolv.conf. Considering how cheap that operation seems to be, would it make sense to call res_init() every time tinc retries a metaconnection? It's not doing that very often anyway... and it would solve the OP's problem.

William Kennington <william at wkennington.com> writes: > Agreed. > On Feb 1, 2015 4:21 AM, "Etienne Dechamps" <etienne at edechamps.fr> wrote: > >> Considering how cheap that operation seems to be, would it make sense >> to call res_init() every time tinc retries a metaconnection? It's not >> doing that very often anyway... and it would solve the OP's problem. +1 we were running a networkmanager dispatcher[^1] for cases like this :) [^1]: https://github.com/fauno/librevpn/blob/develop/lib/skel/50_tincd -- :>...

...fter bootup (or won't be able to reconnect when the network is > changed), which is really ugly. > > Having a local dns in front is somewhat hacky, I'd really love if tinc > would simply reload /etc/resolv.conf each time a new metaconnection is made. It's fixed in git now; res_init() is explicitly called before every call to getaddrinfo(). I hope some day the glibc maintainers will see the light that /etc/resolv.conf is not a static file. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A n...

.../usr/ports/net/bind8/work/src/bin/addr /var/tmp/usr/ports/net/bind8/work/src/bin/nslookup cc -O -pipe -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -W format -o nslookup main.o getinfo.o debug.o send.o skip.o list.o subr.o commands.o ../../lib/libbind.a -ll -lutil ../../lib/libbind.a(res_init.o): In function `__res_randomid': res_init.o(.text+0xf78): undefined reference to `isc__gettimeofday' ../../lib/libbind.a(ev_timers.o): In function `__evNowTime': ev_timers.o(.text+0xc8): undefined reference to `isc__gettimeofday' ../../lib/libbind.a(prandom.o): In function `__dst_s...

...{ ! nsid_state = res_randomid(); return (nsid_state); } diff -cNr ../bind-4.9.5-P1-rel/res/Makefile ./res/Makefile *** ../bind-4.9.5-P1-rel/res/Makefile Thu Aug 8 16:49:48 1996 - --- ./res/Makefile Wed Apr 9 00:32:13 1997 *************** *** 77,89 **** res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c OBJS= base64.o herror.o res_debug.o r...

...ad of the "real" _res (however that might be defined on various platforms). _res is used only in the getrrsetbyname function, which never initializes it in any way, but tries to act as if it's using the real _res. So it calls init_res every time: if ((_resp->options & RES_INIT) == 0 && res_init() == -1) { and it never turns on DNSSEC, even when RES_USE_EDNS0 is set, since it's checking for it in the wrong place: if (_resp->options & RES_USE_EDNS0) _resp->options |= RES_USE_DNSSEC; The fix is to remove the code that redefines _...

Hi, I have * running on a SuSE Email Server II, which uses an older libc-version. Calls to res_ninit et al. from enum.c prevent asterisk from building on that system. Could that possibly be changed to use res_init and res_search in order to provide backward compatibility with these systems ? Thanks, Holger von Ameln

Hi I have some trouble getting asterisk to compile on my system. I get unresolved external symbol in enum.c et srv.c on res_ninit, res_nsearch and res_nquery. I've looked through my /usr/include/resolv.h file, and endeed I didn't found any declaration of such functions. It seems to be some res_init, res_search, etc.. but the declarations are the same the res_nxxx ones. Does asterisk requires any specific version of the glibc or gcc ? Thanks for your help. John WALTER

...d of the "real" _res (however that might be defined on various platforms). _res is used only in the getrrsetbyname function, which never initializes it in any way, but tries to act as if it's using the real _res. So it calls init_res every time: if ((_resp->options & RES_INIT) == 0 && res_init() == -1) { and it never turns on DNSSEC, even when RES_USE_EDNS0 is set, since it's checking for it in the wrong place: if (_resp->options & RES_USE_EDNS0) _resp->options |= RES_USE_DNSSEC; So, what's the fix for this? The first thing th...

...======== > [..] > > error("setsockopt SO_KEEPALIVE: %.100s", > strerror(errno)); > > + > > + /* > > + * Initialize the resolver. This may not happen automatically > > + * before privsep chroot(). > > + */ > > + if ((_res.options & RES_INIT) == 0) { > > + debug("res_init()"); > > + res_init(); > > + } > > I won't claim to understand why it is necessary, but your patch fixes > the > "wait a minute" problem when logging into a FreeBSD 4.1.1-RELEASE > machine > with PrivSep a...

...gram is > > running, glibc doesn't automatically notice this. Since tinc 1.0.25 and > > 1.1pre11, if you send tincd the ALRM signal, it will force glibc to > > reload /etc/resolv.conf. > > Considering how cheap that operation seems to be, would it make sense > to call res_init() every time tinc retries a metaconnection? It's not > doing that very often anyway... and it would solve the OP's problem. > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc &gt...

...UfA at public.gmane.org> writes: > >> Agreed. >> On Feb 1, 2015 4:21 AM, "Etienne Dechamps" <etienne-ypMCQUleWbRvynnTyRI/EA at public.gmane.org> wrote: >> >>> Considering how cheap that operation seems to be, would it make sense >>> to call res_init() every time tinc retries a metaconnection? It's not >>> doing that very often anyway... and it would solve the OP's problem. > > +1 we were running a networkmanager dispatcher[^1] for cases like this :) > > > [^1]: https://github.com/fauno/librevpn/blob/develop/l...

...-crypto/gate Revision: ecd424d223eba74f36389e19f048782a9ce9142e Log message: 6274683 gcc and libresolv[2] don''t get along Files: update: usr/src/lib/libresolv/res_comp.c update: usr/src/lib/libresolv/res_debug.c update: usr/src/lib/libresolv/res_gethost.c update: usr/src/lib/libresolv/res_init.c update: usr/src/lib/libresolv/res_mkquery.c update: usr/src/lib/libresolv/res_query.c update: usr/src/lib/libresolv/res_send.c update: usr/src/lib/libresolv/res_sethost.c update: usr/src/lib/libresolv2/common/isc/eventlib_p.h update: usr/src/lib/libresolv2/include/port_after.h update: usr/...

...9;s) stderr, but delivered to the client (to the client's stderr). Verified with the FreeBSD version of sshd, and with sshd-3.7.1p2 --snip--server: # /usr/sbin/sshd -ddd debug1: sshd version OpenSSH_3.5p1 FreeBSD-20030924 ... debug1: Server will not fork when running in debugging mode. debug1: res_init() Connection from 127.0.0.1 port 2959 debug1: Client protocol version 1.5; client software version OpenSSH_3.5p1 FreeBSD-20030924 ... Found matching RSA1 key: 6e:b3:aa:3c:0a:8e:74:f3:de:da:f2:0c:39:d6:f0:19 Accepted rsa for martin from 127.0.0.1 port 2959 ... debug1: session_new: init debug1: sessi...

...ame.c getrrsetbyname.c:133: warning: static declaration for `_getshort' follows non-static getrrsetbyname.c:143: warning: static declaration for `_getlong' follows non-static getrrsetbyname.c: In function `getrrsetbyname': getrrsetbyname.c:183: warning: implicit declaration of function `res_init' getrrsetbyname.c:199: warning: implicit declaration of function `res_query' getrrsetbyname.c:238: structure has no member named `ad' getrrsetbyname.c: In function `parse_dns_qsection': getrrsetbyname.c:426: warning: implicit declaration of function `dn_expand' make[1]: *** [get...

If tincd is started before name resolution comes up, it keeps failing for ever to resolve domain names in Address= host configuration variable after name resolution becomes possible. I think tincd should succeed in resolving domain names after name resolution becomes available.

Hi ! I've been trying to improve NV50 shader generation a bit the last couple of weeks, so here is what I've produced. I don't know if it's usable for you or just a pile of horrible hacks, but at least it makes some mesa demos render more correcly, p.e. the teapot (aside from mip-mapping issues of the floor texture), arbfplight, and I think the gears also didn't appear as they