Date: Fri, 21 Dec 2012 22:33:26 -0700 From: Derek Wood <ddwood@highdensity.org> To: freebsd-doc@freebsd.org, doc@freebsd.org Subject: Re: [RFC] Q&A propose to add into FAQ Message-ID: <20121222053326.GA29111@yavin> In-Reply-To: <50CF471D.10407@rdtan.net> References: <50CF471D.10407@rdtan.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 18, 2012 at 12:23:57AM +0800, Edward wrote: > Hi, > > I wish to submit the below list of Q&A (Question & Answer) for addition > to current FreeBSD FAQ book. Before this can happen, I would like to > seek your comments & suggestion whether these Q&A are in correct facts, > writing style and/or suitable. These Q&A are : > > Q1: Boot up messages are missing from /var/log files. Where can I find them? > A1: Kernel log messages are recorded in /var/log/messages, > /var/log/dmesg.yesterday, and /var/log/dmesg.today. But boot time > messages can be found at /var/run/dmesg.boot. > > Q2: My xxx software only works on "some old version" of FreeBSD, where > can I get these? > A2: Older versions of FreeBSD can be obtain from > ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/ . You > should be aware that most of these versions are EoL (End of Life) and > can be extremely buggy, use at your own risk. > Can you expand on this to include older versions of software ported to FreeBSD? Ports trees distributed with release versions are available as a compressed tarball on the archive site, or can be obtained through SVN/CVS (with the warning that CVS is deprecated...). A warning would be needed that distfiles might be entirely unavailable for ancient versions of software, and the combination of an old ports tree and an old FreeBSD version will not be supported; but the port should work, and might save people the time and effort of redoing porting work that has already been done. > Q3: I have a piece of software that runs only on 64 bit processor. How > do I know my current processor is capable of 64 bit processing? > A3: Take a look at /var/run/dmesg.boot, search for the line with "AMD > Features". If CPU features flag "LM" exists, your processor supports 64 > bit processing. Otherwise, you are most likely to be using a 32 bit > processor. > Example of log to look for (64 bit processor) : > AMD Features=0x28100000<NX,RDTSCP,LM> > > Q4: I just started "xxx" service, how to find out what TCP/UDP port is > open/listening? > A4: Use the utility "sockstat". Usage example, > "sockstat -Ptcp" > "sockstat -Pudp" > > Q5: I'm living in "xxx" country, how can I change this server timezone? > A5: Use "tzsetup" utility. > > Q6: I'm troubleshooting a network link issue, how can I generate big > size file to test network transfer speed? > A6: Use the utility "dd". For example, "dd if=/dev/random > of=hugefile.txt bs=1m count=1k" would create a file named hugefile.txt > with the size of 1 gigabyte. > Can you expand on this question and add additional benchmarking/diagnostic tools from ports? For example, benchmarks/netperf, net/mtr, and net-mgmt/smokeping. > Q7: My server performance seems to be slow. How can I find out what's > the bottleneck? > A7: Use the utility "iostat". Example, "iostat -dw2" would display > device (-d) statistic refreshing the output every 2 second (-w2). > "iostat -Cw2" would display CPU (-C) statistic. > I would also include systat (as mentioned by Eitan) and top in the answer to this question, or rephrase the question to preclude the possibility of a slow CPU/network being the root cause. > Q8: This server of mine is a public DNS and it seems to be rejecting > connections because of too many TCP connections with "TIME_WAIT" status > (from "netstat -an"). How can I reduce the timeout? > A8: In short, tune the sysctl value "net.inet.tcp.msl" to something > modern and acceptable, such as 7500. > In detail, the default timeout value for TIME_WAIT status is set to 60 > seconds. This value is based on RFC 793. Since this RFC is drafted in > year 1981, equipments & bandwidth of that time wasn't as fast as what we > have now. A 60 seconds of waiting, for TCP session to terminate is a > long time. For a busy server opening & closing TCP connections, this > value should set to a fairly short time, such as 15 seconds. > The value of "net.inet.tcp.msl" is not the usual "literal" seconds > though. In order to reduce from the default 60 seconds to 15 seconds, > convert it to milliseconds and then divide it by 2. For example, > when 15 seconds is converted to 15,000 milliseconds, it then should > divide by 2, which sums up as "7500". This will be the value for > "net.inet.tcp.msl". > > Q9: I just updated /etc/newsyslog.conf. How do I check for syntax error? > A9: Use the parameter "-nvv" when executing "newsyslog". For example, > "newsyslog -nvv" would tell what are each of the lines in > /etc/newsyslog.conf would do when the time comes. > > Q10: The output of "ps" is truncated to the end of my terminal width and > I can't see the program name. > A10: Tell "ps" to disregard your terminal width. For example, "ps auxww". > Can this be made more explicit? "Include 'ww' to the options supplied to ps(1)" for example. > By the way, do you guys think is there any chance that this Q&A can > squeeze into the FAQ? > Q: My this cute little colleague/friend have very big fat fingers, how > can I punk him? > A: install port "games/sl" then try typing "sl" instead of "ls". > > Regards, > Edward. > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121222053326.GA29111>