very stupid mistake: a part of /usr is deleted
Hi all, vor 2 hours i made a very stupid mistake: i have deleted (as root naturally) a part of /usr-directory. I have definitely deleted .snap and presumably 100-150 files in /usr/bin. If my attempt with backup-restore failed, can i get the binaries, that was deleted, with sysinstall/distributions/base ? uname -a -> FreeBSD (XX).uni-tuebingen.de 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 thanks, -- Zara Kanaeva. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Stuck processes in unkillable (STOP) state, listen queue overflow
dle the incoming connections). I'm not sure it matters, but some of the machines (and the above) runs on an ESX hypervisor (but as far as I can remember, I could see this on physical machines too, but I'm not sure about that). Also -so far- I could only see this where some "exotic" stuff ran, like a java or erlang based server (opendj, elasticsearch and rabbitmq). Also not sure about which triggers this. I've never seen this after some hours of uptime, at least some days or a week must've been passed to get stuck like the above. Any ideas about this? Thanks, ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Dipl.-Inf. Zara Kanaeva Heidelberger Akademie der Wissenschaften Forschungsstelle "The role of culture in early expansions of humans" an der Universität Tübingen Geographisches Institut Universität Tübingen Ruemelinstr. 19-23 72070 Tuebingen Tel.: +49-(0)7071-2972132 e-mail: zara.kana...@geographie.uni-tuebingen.de --- - Theory is when you know something but it doesn't work. - Practice is when something works but you don't know why. - Usually we combine theory and practice: Nothing works and we don't know why. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Stuck processes in unkillable (STOP) state, listen queue overflow
Hello Дмитрий,
thank you very much for your message.
First of all: I like FreeBSD (the installation logic, the good
documentation etc.), this is why I use FreeBSD as Server OS. But in my
case I must desagree your strong theoretical probability
consideration. In my case I have one machine (7 years old), that had
1-2 spontaneous rebootes in a year. In my case I got a lot of "already
in queue awaiting acceptance"-Errors and the machine rebootes
immediately after this.
I will get soon a new replacement for this old machine with at least
32 GB RAM and (of course) new power supply. So I will see if my
problem (perhaps it is only my problem) still persist.
Greetings, Z. Kanaeva.
Zitat von Дмитрий Долбнин :
Good day everyone !
From my point of view it seems like you're experiencing the
"downgraded" hardware performance which causes you the problems you
meet.
Try to switch for the "new-one" power supply at least.
Why I think so ? Because the bad power supplies are met much more
often than the bad source code for FreeBSD. Of course I can't tell
you you're completely wrong.
Best regards, Dimitry.
Среда, 28 октября 2015, 12:00 UTC от freebsd-stable-requ...@freebsd.org:
Send freebsd-stable mailing list submissions to
freebsd-stable@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-stable-requ...@freebsd.org
You can reach the person managing the list at
freebsd-stable-ow...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. Re: Stuck processes in unkillable (STOP) state, listen queue
overflow (Zara Kanaeva)
2. Re: Stuck processes in unkillable (STOP) state, listen queue
overflow (Nagy, Attila)
------
Message: 1
Date: Tue, 27 Oct 2015 14:42:42 +0100
From: Zara Kanaeva < zara.kana...@ggi.uni-tuebingen.de >
To: freebsd-stable@freebsd.org
Subject: Re: Stuck processes in unkillable (STOP) state, listen queue
overflow
Message-ID:
< 20151027144242.horde.3xc1_rqzavmaz12x6opx...@webmail.uni-tuebingen.de >
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Hello,
I have the same experience with apache and mapserver. It happens on
physical machine and ends with spontaneous reboot. This machine is
updated from FREEBSD 9.0 RELEASE to FREEBSD 10.2-PRERELEASE. Perhaps
this machine doesn't have enough RAM (only 8GB), but I think that must
not be a reason for a spontaneous reboot.
I had no such behavior with the same machine and FREEBSD 9.0 RELEASE
on it (I am not 100% sure, I have yet no possibility to test it).
Regards, Z. Kanaeva.
Zitat von "Nagy, Attila" < b...@fsn.hu >:
Hi,
Recently I've started to see a lot of cases, where the log is full
with "listen queue overflow" messages and the process behind the
network socket is unavailable.
When I open a TCP to it, it opens but nothing happens (for example I
get no SMTP banner from postfix, nor I get a log entry about the new
connection).
I've seen this with Java programs, postfix and redis, basically
everything which opens a TCP and listens on the machine.
For example, I have a redis process, which listens on 6381. When I
telnet into it, the TCP opens, but the program doesn't respond.
When I kill it, nothing happens. Even with kill -9 yields only this state:
PID USERNAME THR PRI NICE SIZERES STATE C TIME
WCPU COMMAN
776 redis2 200 24112K 2256K STOP3 16:56
0.00% redis-
When I tcpdrop the connections of the process, tcpdrop reports
success for the first time and failure for the second (No such
process), but the connections remain:
# sockstat -4 | grep 776
redisredis-serv 776 6 tcp4 *:6381 *:*
redisredis-serv 776 9 tcp4 *:16381 *:*
redisredis-serv 776 10 tcp4 127.0.0.1:16381 127.0.0.1:10460
redisredis-serv 776 11 tcp4 127.0.0.1:16381 127.0.0.1:35795
redisredis-serv 776 13 tcp4 127.0.0.1:30027 127.0.0.1:16379
redisredis-serv 776 14 tcp4 127.0.0.1:58802 127.0.0.1:16384
redisredis-serv 776 17 tcp4 127.0.0.1:16381 127.0.0.1:24354
redisredis-serv 776 18 tcp4 127.0.0.1:16381 127.0.0.1:56999
redisredis-serv 776 19 tcp4 127.0.0.1:16381 127.0.0.1:39488
redisredis-serv 776 20 tcp4 127.0.0.1:6381 127.0.0.1:39491
# sockstat -4 | grep 776 | awk '{print "tcpdrop "$6" "$7}' | /bin/sh
tcpdrop: getaddrinfo: * port 6381: hostname nor servname provided,
or not known
tcpdrop: getaddrinfo: * port 16381: hostname nor servname provided,
or not known
tcpdrop: 127.0.0.1 16381 127.0.0.1 10460: No such process
tcpdrop: 127.0.0.1 1638
LSI SAS 3108 RAID Controller
Dear list, I have one Fujitsu server with LSI SAS 3108 RAID Controller. These LSI SAS 3108 RAID Controller is supported by the mpr driver (https://www.freebsd.org/relnotes/CURRENT/hardware/support.html). If I try to install the FreeBSD-stable 10.0 or FreeBSD-current 11.0 on this server I can make partitions, but I can not write install files on the disks (better to say RAID5 virtual drive) without errors. The erorrs are: mfi0 failed to get command mfi0: COMMAND ... TIMEOUT AFTER ... SECONDS By the installations I see my virtual drive as device with mfi0 as identifier. My questions are: 1) Why I see the virtual drive as device with mfi0 as identifier. I would expect that my virtual drive has identifier mpr0 or something like this. 2) Why I can install FreeBSD on one of the disks connected to LSI SAS 3108 RAID Controller, if the disks do not build any virtual drive (no matter which RAID level). Is that possible because mpr driver supports the LSI SAS 3108 RAID Controller as SCSI Controller and not as RAID Controller (see Kernel configuration)? Thanks in advance, Z. Kanaeva. -- Dipl.-Inf. Zara Kanaeva Heidelberger Akademie der Wissenschaften Forschungsstelle "The role of culture in early expansions of humans" an der Universität Tübingen Geographisches Institut Universität Tübingen Ruemelinstr. 19-23 72070 Tuebingen Tel.: +49-(0)7071-2972132 e-mail: zara.kana...@geographie.uni-tuebingen.de --- - Theory is when you know something but it doesn't work. - Practice is when something works but you don't know why. - Usually we combine theory and practice: Nothing works and we don't know why. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LSI SAS 3108 RAID Controller
Thank you for all responds. set hw.mfi.mrsas_enable=1 in Loader prompt did the work. The useful information for this problem can be found here: http://lists.dragonflybsd.org/pipermail/users/2014-July/128703.html Regards, Z.K. Zitat von Zara Kanaeva : Dear list, I have one Fujitsu server with LSI SAS 3108 RAID Controller. These LSI SAS 3108 RAID Controller is supported by the mpr driver (https://www.freebsd.org/relnotes/CURRENT/hardware/support.html). If I try to install the FreeBSD-stable 10.0 or FreeBSD-current 11.0 on this server I can make partitions, but I can not write install files on the disks (better to say RAID5 virtual drive) without errors. The erorrs are: mfi0 failed to get command mfi0: COMMAND ... TIMEOUT AFTER ... SECONDS By the installations I see my virtual drive as device with mfi0 as identifier. My questions are: 1) Why I see the virtual drive as device with mfi0 as identifier. I would expect that my virtual drive has identifier mpr0 or something like this. 2) Why I can install FreeBSD on one of the disks connected to LSI SAS 3108 RAID Controller, if the disks do not build any virtual drive (no matter which RAID level). Is that possible because mpr driver supports the LSI SAS 3108 RAID Controller as SCSI Controller and not as RAID Controller (see Kernel configuration)? Thanks in advance, Z. Kanaeva. -- Dipl.-Inf. Zara Kanaeva Heidelberger Akademie der Wissenschaften Forschungsstelle "The role of culture in early expansions of humans" an der Universität Tübingen Geographisches Institut Universität Tübingen Ruemelinstr. 19-23 72070 Tuebingen Tel.: +49-(0)7071-2972132 e-mail: zara.kana...@geographie.uni-tuebingen.de --- - Theory is when you know something but it doesn't work. - Practice is when something works but you don't know why. - Usually we combine theory and practice: Nothing works and we don't know why. -- Dipl.-Inf. Zara Kanaeva Heidelberger Akademie der Wissenschaften Forschungsstelle "The role of culture in early expansions of humans" an der Universität Tübingen Geographisches Institut Universität Tübingen Ruemelinstr. 19-23 72070 Tuebingen Tel.: +49-(0)7071-2972132 e-mail: zara.kana...@geographie.uni-tuebingen.de --- - Theory is when you know something but it doesn't work. - Practice is when something works but you don't know why. - Usually we combine theory and practice: Nothing works and we don't know why. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
