5193 what does this look like? [Archive] - The FreeBSD Forums
PDA

View Full Version : what does this look like?

graudeejs
April 27th, 2009, 07:23
Hi! today i woke up and my pc was rebooted in single user mode..
fs were damaged pretty ugly

I checked /var/log/all.log
and started to wonder what could the all be:
Apr 27 00:15:02 129 /usr/sbin/cron[76665]: (root) CMD (/usr/libexec/atrun)
Apr 27 00:15:07 129 kernel: TCP: [90.157.62.69]:23422 to [192.168.128.100]:51195 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 524 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:15:25 129 kernel: TCP: [86.100.222.61]:47568 to [192.168.128.100]:57700 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 115 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:16:33 129 kernel: TCP: [188.16.23.91]:14693 to [192.168.128.100]:56003 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 202 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:16:53 129 kernel: Connection attempt to UDP 192.168.128.100:53594 from 217.78.182.149:52090
Apr 27 00:17:35 129 kernel: TCP: [95.68.31.194]:51679 to [192.168.128.100]:63754 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 27 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:17:53 129 kernel: TCP: [82.131.30.140]:60901 to [192.168.128.100]:51219 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 236 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:18:26 129 kernel: TCP: [85.28.39.110]:45737 to [192.168.128.100]:62822 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 4 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:19:21 129 kernel: TCP: [76.119.3.142]:59945 to [192.168.128.100]:52286 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 4 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:19:33 129 kernel: TCP: [88.134.62.25]:18140 to [192.168.128.100]:63876 tcpflags 0x19<FIN,PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 14 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:20:02 129 /usr/sbin/cron[76764]: (root) CMD (/usr/libexec/atrun)
Apr 27 00:21:04 129 kernel: TCP: [71.226.89.96]:62159 to [192.168.128.100]:51668 tcpflags 0x12<SYN,ACK>; tcp_input: Connection attempt to closed port
Apr 27 00:21:07 129 kernel: TCP: [71.226.89.96]:62159 to [192.168.128.100]:51668 tcpflags 0x12<SYN,ACK>; tcp_input: Connection attempt to closed port
Apr 27 00:21:13 129 kernel: TCP: [71.226.89.96]:62159 to [192.168.128.100]:51668 tcpflags 0x12<SYN,ACK>; tcp_input: Connection attempt to closed port
Apr 27 00:21:27 129 kernel: TCP: [71.226.89.96]:62159 to [192.168.128.100]:51668 tcpflags 0x12<SYN,ACK>; tcp_input: Connection attempt to closed port
Apr 27 00:21:30 129 kernel: TCP: [71.226.89.96]:62159 to [192.168.128.100]:51668 tcpflags 0x12<SYN,ACK>; tcp_input: Connection attempt to closed port
Apr 27 00:21:34 129 kernel: TCP: [77.21.115.100]:54554 to [192.168.128.100]:59471 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 184 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:21:36 129 kernel: TCP: [71.226.89.96]:62159 to [192.168.128.100]:51668 tcpflags 0x12<SYN,ACK>; tcp_input: Connection attempt to closed port
Apr 27 00:22:01 129 /usr/sbin/cron[76792]: (operator) CMD (/usr/libexec/save-entropy)
Apr 27 00:22:47 129 kernel: TCP: [86.18.42.128]:62302 to [192.168.128.100]:64096 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 101 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:22:48 129 kernel: TCP: [77.120.203.130]:34138 to [192.168.128.100]:57949 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 17 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:23:27 129 kernel: TCP: [95.68.31.194]:51679 to [192.168.128.100]:61112 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 9 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:23:35 129 kernel: TCP: [76.119.3.142]:59945 to [192.168.128.100]:61099 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 4 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:23:35 129 kernel: TCP: [85.28.39.110]:45737 to [192.168.128.100]:55083 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 9 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:23:55 129 kernel: TCP: [85.238.107.18]:59954 to [192.168.128.100]:61641 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 18 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:23:59 129 kernel: TCP: [213.164.114.132]:59395 to [192.168.128.100]:49395 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 123 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:25:01 129 /usr/sbin/cron[76805]: (root) CMD (/usr/libexec/atrun)
Apr 27 00:25:11 129 kernel: TCP: [79.65.142.82]:55237 to [192.168.128.100]:61130 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_2: Received 62 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:25:29 129 kernel: TCP: [94.75.178.128]:34062 to [192.168.128.100]:62653 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 4 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:25:33 129 kernel: TCP: [188.16.23.91]:14693 to [192.168.128.100]:62125 tcpflags 0x18<PUSH,ACK>; tcp_do_segment: FIN_WAIT_1: Received 221 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:25:42 129 kernel: TCP: [92.241.162.121]:80 to [192.168.128.100]:63958 tcpflags 0x10<ACK>; tcp_do_segment: FIN_WAIT_1: Received 1460 bytes of data after socket was closed, sending RST and removing tcpcb
Apr 27 00:25:53 129 kernel: TCP: [212.150.34.64]:80 to [192.168.128.100]:54069 tcpflags 0x10<ACK>; tcp_do_segment: FIN_WAIT_2: Received 1460 bytes of data after socket was closed, sending RST and removing tcpcb

I have 3 long logfiles (this is just a small peace of it) with this


1) transmission crashed and theses are attempts to connect to it
2) DOS?
3) something else

I'm thinking perhaps i should put firewall (I have never used one, and this might become good reason to do)

EDIT:
Also computer did not reboot because of power fluctuation, because then it would stay shut down
SirDice
April 27th, 2009, 10:11
You're using rfc-1918 (private) addresses, are you using some NAT gateway? What's running on that? Have you forwarded all your ports to your machine? Why?

As long as the NAT gateway doesn't forward any ports you don't really need a firewall on your machine.

Are you running some kind of P2P perhaps?
vivek
April 27th, 2009, 10:57
Cron is running something check out your cron -u user -l and /etc/crontab file.
SirDice
April 27th, 2009, 11:02
I did a dig -x on a few of those addresses. Most, if not all, are just clients. Looks like P2P to me.
DutchDaemon
April 27th, 2009, 11:05
Looks like P2P to me.

Hmm, yes ;)

transmission crashed

That's a bittorrent client..
DutchDaemon
April 27th, 2009, 11:10
What you see (connections to closed ports) is absolutely typical behaviour for p2p traffic. Most BT clients switch torrents on and off depending on queue rules, completion (ratio), removing torrents, etc. Some trackers update their peer information using long intervals, which means that torrents you removed days ago can still be shown as active on the tracker you were using -- causing peers to connect to you, even though you ditched the torrents days ago.

All of this shouldn't cause a shutdown/reboot, unless either your RAM/swap filled up, or your disk can't take the thrashing of all those file/disk accesses caused by multiple torrents.
graudeejs
April 27th, 2009, 11:12
i wonder why and how it chashed, and was transmission the one that crashed (perhaps it was X)
All i know that My FS was looking pretty ugly i had to run fsck -y 3 times
graudeejs
April 27th, 2009, 11:17
All of this shouldn't cause a shutdown/reboot, unless either your RAM/swap filled up, or your disk can't take the thrashing of all those file/disk accesses caused by multiple torrents.

It's 220GB SATA disk with geli aes256 encryption. UFS on top.

I have 2GB ram and 18GB swap
I have 14BG swap based tmp, so at any time there is at least 4GB swap accessible, so i don't believe i ran out of ram/swap
Not to mention that /tmp is pretty empty most of time

EDIT:
also system disk is separate IDE disk
and swap is striped among bough disks
each have 9GB swap
DutchDaemon
April 27th, 2009, 11:22
If your fsck had a really hard time of cleaning up, it means that a lot of file descriptors were open/in use when your system halted. Which is also typical of a lot of torrents being open.

That in itself doesn't mean much -- it just means that the server probably crashed when transmission was active and had a lot of files open.

There's no cause <-> effect implied there. It could be, though.
DutchDaemon
April 27th, 2009, 11:25
It's 220GB SATA disk with geli aes256 encryption. UFS on top.

I don't have enough experience with GELI to comment on the overhead/added stress of having a lot of continuous and simultaneous disk activity (torrents) on an encrypted filesystem. It could be a factor, though.
graudeejs
April 27th, 2009, 11:34
My HDD (with encrypted fs) can handle 2x-3x my bandwidth
So far i had no problem with geli even when i was downloading/uploading at top speed (~12.5M/s)

and i didn't have new torrents that would cause such a speed, it should be max 2M/s (but more likely some 800K/s)


EDIT:
btw i use geli since i wrote how to on daemonforums... ( a pretty long time)


EDIT:
OK, thanks for your help....
I hope next time i will have more information (well i hope it won't come to next time)

btw it's not a server it's a desktop :D
DutchDaemon
April 27th, 2009, 12:05
I don't think it's an issue of bandwidth (as in: sustained uploads/downloads), but it may be an issue of scores of very small disk accesses caused by reading, writing and serving small blocks of data to/from torrent containers.

Depending on how you configure your torrent client, you can have dozens of connected peers per torrent, all causing numerous small disk transactions at the same time, 24x7.

I guess you could try /var/crash/vmcore.* for crash info. It may be something completely different, of course.
graudeejs
April 27th, 2009, 12:11
I have nothing in /var/crash

I have turned of kernel dumps btw
roddierod
April 27th, 2009, 15:25
Just my $0.02, when I used transmission as a client I would sometimes wake up to find my workstation had rebooted or just froze up.

I started to notice that if I was seeding a lot or downloading a lot (maybe 20 or 30 torrents at a time) this would happen. It would also happen with huge torrent say 5+ GB that were popular.

I stopped using tranmission. I think there is something wrong with the coding of tranmission. I switched to deluge and haven't had the problem since. I download and upload close to 150GB per month via torrents. I've had to watch since I'm being capped by my ISP now.
richardpl
April 27th, 2009, 15:53
I have nothing in /var/crash

I have turned of kernel dumps btw
Thats is bad idea, now crash remains mystery.
graudeejs
April 27th, 2009, 16:15
Thats is bad idea, now crash remains mystery.

I will turn it on if you or anyone else want to dig my dumps....
For now i haven't seen such a person....

perhaps in FreeBSD 8 i will enable dumps again, because as i understand they are being redesigned.
phoenix
April 27th, 2009, 16:16
Hi! today i woke up and my pc was rebooted in single user mode..
fs were damaged pretty ugly

I checked /var/log/all.log
and started to wonder what could the all be:

You also (most likely) have net.inet.tcp.log_in_vain enabled in /etc/sysctl.conf, which causes the kernel to log any connections to closed ports. That's why you are getting all those log messages.
graudeejs
April 27th, 2009, 16:21
Just my $0.02, when I used transmission as a client I would sometimes wake up to find my workstation had rebooted or just froze up.

I started to notice that if I was seeding a lot or downloading a lot (maybe 20 or 30 torrents at a time) this would happen. It would also happen with huge torrent say 5+ GB that were popular.

I stopped using tranmission. I think there is something wrong with the coding of tranmission. I switched to deluge and haven't had the problem since. I download and upload close to 150GB per month via torrents. I've had to watch since I'm being capped by my ISP now.

That's sad.... because there were only 2 torrent clients that i like (atm):
a) rtorrent
b) transmission
and bough have issues

dam... well will think of switching to deluge.
p.s. i did notice my pc crash much to much recently and i'm seeding some 30-50 torrents all the time
:(
graudeejs
April 27th, 2009, 16:25
You also (most likely) have net.inet.tcp.log_in_vain enabled in /etc/sysctl.conf, which causes the kernel to log any connections to closed ports. That's why you are getting all those log messages.

That is very correct
SirDice
April 27th, 2009, 17:26
That's sad.... because there were only 2 torrent clients that i like (atm):
a) rtorrent
b) transmission
and bough have issues

dam... well will think of switching to deluge.
FWIW I use mldonkey for torrents. Works like a charm. Actually I run mldonkey-core on my server and use Sancho from a Windows client to control it.
richardpl
May 6th, 2009, 15:34
I will turn it on if you or anyone else want to dig my dumps....
For now i haven't seen such a person....

perhaps in FreeBSD 8 i will enable dumps again, because as i understand they are being redesigned.

In FreeBSD >= 7.X dumps are enabled by default and when panic happens thay are dumped to swap partition(you should have real swap partition, not file). Upon next reboot crash dump is saved into /var/crash/ via savecore script.

Normal way to debug panic is providing backtrace, one way to provide backtrace is to have crash dump saved into /var/crash/ directory.

If you care to fix bug, help FreeBSD project, etc. you write PR with backtrace, and bunch of others usefull information(including known way how to reproduce crash, hardware explanation etc....)
graudeejs
May 6th, 2009, 16:39
The reason i turned it of was: because on FreeBSD 6.2 with dumps enabled firefox2 crashed much frequently then with dumps off.....
he he he, well that was past... i have enable mem dumps again.....
richardpl
May 6th, 2009, 23:23
Are you sure that we are talking about same thing.
I dont see how enabling crash dumps(dumpdev/dumpdir) could make firefox crashing.(kernel vs userspace)
graudeejs
May 7th, 2009, 00:12
ye, i'm not sure why it did as well, but the moment i turned it off, ff2 stopped crashing that much....

Before i discovered this, I didn't migrate to FreeBSD from Linux... because it was VERY annoying....

That's history now
0