Each new tmux session or new pseudo terminal results in external DNS queries info: sending query: tmux(PID).%PTS. A IN See https://forums.freebsd.org/threads/tmux-problems-with-dns-queries.53872/ for a full description, that can be confirmed.
Is this problem specific to FreeBSD ?
Unfortunately the recent port upgrade to version 2.1 did not solve the problem.
(In reply to p5B2E9A8F from comment #2) > Unfortunately the recent port upgrade to version 2.1 did not solve the > problem. Sure, could you answer my question ?
Look like it is specific to FreeBSD. see again https://forums.freebsd.org/threads/tmux-problems-with-dns-queries.53872/ for new comments.
(In reply to p5B2E9A8F from comment #4) > Look like it is specific to FreeBSD. > see again > https://forums.freebsd.org/threads/tmux-problems-with-dns-queries.53872/ > for new comments. Well, I've tried on about half a dozen boxes tonight, I can't reproduce. I have a feeling it is not a problem with tmux, but some other application, like the terminal emulator, the shell...
Could you try to run: ktrace -i tmux new reproduce the problem, and attach a compressed version of what kdump produces ?
ktrace -i is to intrusive for posting public. suggest more specific options and I will send it to you by mail.
(In reply to p5B2E9A8F from comment #7) > ktrace -i > is to intrusive for posting public. > suggest more specific options and I will send it to you by mail. If you can reproduce it easily, create an empty jail with only the bits needed, and run ktrace from it. Or send the dump directly to me. Or run kdump and le me know the context around which tmux runs the dns queries.
I think this is a problem caused by using tmux and tcsh/csh together. Somehow other shells don't have this problem. Also, I notice that if using tcsh/csh, there is alway a 2-second delay before creating a new tcsh/csh shell. A solution was suggested here in the following link (a Chinese FreeBSD forum): https://www.freebsdchina.org/forum/viewtopic.php?t=70120&sid=c598fc15f6ef9ca3543c61f019bcbfd4 By adding a patch called 'patch-configure.1' in sysutils/tmux/files/, I was able to eliminate the problems. But I am not sure if this is the right way to solve these problems. The version of the Makefile I am using is $FreeBSD: head/sysutils/tmux/Makefile 385629 2015-05-07 14:18:24Z mat $ The following is the patch (patch-configure.1): --- configure.orig +++ configure @@ -5050,11 +5050,11 @@ fi -if test "x$have_utempter" = xyes; then - $as_echo "#define HAVE_UTEMPTER 1" >>confdefs.h - - LIBS="$LIBS -lutempter" -fi +#if test "x$have_utempter" = xyes; then +# $as_echo "#define HAVE_UTEMPTER 1" >>confdefs.h +# +# LIBS="$LIBS -lutempter" +#fi # Check for b64_ntop. { $as_echo "$as_me:${as_lineno-$LINENO}: checking for b64_ntop" >&5
Maintainer feedback?
Problem still occurs. Can this PR be reopened? Or should I create a new PR? Workaround: remove "--enable-utempter" from CONFIGURE_ARGS.
reopen - see comment 11.
The problem is in tcsh(1) and not tmux. Here is ktrace -i tmux new tcsh output that shows it in action (look for connect to port 53): 58552 tcsh CALL connect(0x3,0x800718fbc,0x10) 58552 tcsh STRU struct sockaddr { AF_INET, 192.168.0.1:53 } 58552 tcsh RET connect 0 58552 tcsh CALL sendto(0x3,0x800dd3540,0x20,0,0,0) 58552 tcsh GIO fd 3 wrote 32 bytes 0x0000 1071 0100 0001 0000 0000 0000 0b74 6d75 |.q...........tmu| 0x0010 7828 3538 3533 3829 0225 3000 0001 0001 |x(58538).%0.....| 58552 tcsh RET sendto 32/0x20 Try editing /usr/src/contrib/tcsh/config_f.h and change -#define REMOTEHOST +#undef REMOTEHOST and rebuild the shell in /usr/src/bin/csh. I don't think that disabling utempter support in tmux is the right solution since tmux sessions then no longer appear in w(1) output etc.
Oh, that is why I could not reproduce the problem, it is not tmux's fault :-) Closing this.
*** Bug 265306 has been marked as a duplicate of this bug. ***