Schlagwort-Archive: timeout

Vagrant issue Timed out while waiting for the machine to boot

Veröffentlicht am von
Antworten

vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/xenial64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: Setting the name of the VM: vagrant_default_1516452195026_53624
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 5000 (guest) => 5000 (host) (adapter 1)
default: 7474 (guest) => 7474 (host) (adapter 1)
default: 7687 (guest) => 7687 (host) (adapter 1)
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Resized disk: old 10240 MB, req 51200 MB, new 51200 MB
==> default: You may need to resize the filesystem from within the guest.
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

Run
vagrant destroy

Upgrade Virtualbox and do the vagrant up again

a better wp security plugin problem

Veröffentlicht am von
Antworten

Das WordPress Security plugin „A better wp security“ ist sehr wertvoll, bei manchen Webhostern können einzelne Funktionen jedoch dazu führen, dass der WordPress blog nicht mehr erreichbar ist.

Z.b. führt das nutzen der Funktion „Dateiänderungen tracken / File change detection“ auf einem shared hoster unter Umständen zu einem Timeout, weil nicht genug CPU / RAM vorhanden ist um alle Files zu checken.

Hier muss das plugin „A better WP security“ zurück gesetzt werden.

Mit dem folgenden SQL command werden alle options rückgesetzt:


SELECT *
FROM `wp_options`
WHERE option_name LIKE '%bwps%'

Alternativ lohnt sich ein Blick in die htaccess, welche durch das plugin ggf. auch angepasst wird.

Die default WordPress htaccess Datei sieht wie folgt aus:

# BEGIN WordPress


RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Für Einsteiger noch eine Buchempfehlung zu dem Thema:

Für Profis:

Apple OSX Maveric QNAP TimeMachine Probleme

Veröffentlicht am von
3

Wer mit OSX 10.9 Probleme hat ein TimeMachine backup zu erstellen und den folgenden Fehler bekommt:

com.apple.prefs.backup.remoteservice[602]: Error while confirming network destination: Error Domain=NSOSStatusErrorDomain Code=64 "Der Vorgang konnte nicht abgeschlossen werden. (OSStatus-Fehler 64.)" (kOTSerialFramingErr / EHOSTDOWN: / Host is down)

bzw


NetAuthSysAgent[1071]: ERROR: AFP_GetServerInfo - connect failed 64

Kann mal versuchen den AFP Server manuell als TimeMachine Destination zu nutzen mit dem folgenden Kommando:


sudo tmutil setdestination afp://$QNAPTIMEMACHINEUSER:$QNAPTIMEMACHINEPASSWORD@$QNAPIPADRESS/TMBackup