mdadm --create /dev/md0 --level 1 --raid-devices 2 /dev/sdb1 missing --metadata=0.90
mdadm: super0.90 cannot open /dev/sdb1: Device or resource busy
mdadm: /dev/sdb1 is not suitable for this array.
mdadm: create aborted
Sometimes running "partprobe" can fix this. Other times it requires a reboot.
One other manual thing that can be done is the following to fix it (if dm is using and blocking it):........
This is a gotcha but be aware sometimes iptables may be active and loaded by default.
Also make sure you don't just disable firewalld but also stop it otherwise it will still block stuff:
systemctl stop firewalld
If the above is not the issue then it is possible iptables is running and blocking stuff too, so you'll need to stop iptables.
So in addition to opening firewalld or disabling it, you would need to disable iptables........
Idid a systemctl restart networking and it broke Proxmox VM connectivity!
#proxmox is the problem after restarting the network the tap devices go to disabled state
[2230884.919905] vmbr0: port 7(tap118i0) entered disabled state
[2230884.948864] vmbr0: port 8(tap122i0) entered disabled state
[2230884.972748] vmbr0: port 6(tap119i0) entered disabled state
[2230885.004745] vmbr0: port 5(tap117i0) entered disabled state
The Linux Kernel interpretated a very high volume of real traffic as a DDOS attack so it basically ends up blocking your web server.
possible SYN flooding on ctid 42131, port 80. Sending cookies.
Simple fix edit sysctl values for max_syn_backlog
sysctl -w net.ipv4.tcp_max_syn_backlog=5000
To make them permanent edit /etc/sysctl.conf
Sep 12 18:16:25 vps pluto: ERROR: asynchronous network error report on eth0 (sport=500) for message to 188.8.131.52 port 20640, complainant 184.108.40.206: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
Some say changing the "leftprotoport=17/%any" will fix this but I have not found this to be the case.
Essentially it means at least one end is blocking the ipsec packets. Sometimes the %any allows an alt........
This is a real pain because I had to manually unplug ethernet cables for network testing or to use an alternate network or guarantee physical access to one network segment is cut off.
For some reason this happened after Ikilled dbus because it was confused and blocking packets thinking they were coming from the wrong interface since eth0 and eth1 both had the same subnet and gateway.
I eventually did a "service network-manager restart" but the option was........
relay=alt4.gmail-smtp-in.l.google.com. [220.127.116.11], dsn=4.0.0, stat=Deferred: 421-4.7.0 [ 10] Our system has detected an unusual rate of
This is strange because the mail server IP is not blacklisted anywhere and the IP itself has not been used for years and this server is clean and has only sent a few e-mails to gmail.com in its entire time.
I wonder if this is a legacy block on a whole range of IPs as punishment for others in the block........
Here is a quick script that works on most Centos versions to disable the virus/SELinux from blocking basic functionality.
The first echo 0 statement disables SELinux instantly but it will still be enabled on reboot.
The second line disables it permanently.
#disable SELinux Immediately
echo 0 > /selinux/enforce
#disable SELinux Permanently
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config........
dd if=/dev/sda of=/dev/null creates ever increasing load every second.
After minutes the load has moved up to 4.79
I've tried with two different discs in my system.
I wonder if it's a delay or problem with the SATA bus because one drive I have connected has recently failed.
I notice when drives fail that you get some IO/blocking issue when they don't respond properly.
Yes I believe it was, because here's the same disc after removing the dead........
This has stumped me a few times because I keep forgetting that Centos 5.5 comes with a default iptables configuration that ends up blocking DRBD traffic,I tried all the normal things and couldn't understand why I couldn't make my normal DRBD config work. So if you have WFConnection problems and have tried the normal "mailing list" fixes, check your firewall status first!
Both Nodes Say the Following:
version: 8.3.8 (api:88/prot........