So after patching having issue with disk reattaching to sdb1. used "drbdadm attach r1" and getting this error.
I try using drbdadm create-md r1 and then bring it down and back up since the metadata is internal. That doesn't seem to work. This is the secondary node the primary is up and running without issue.
Related
I’m trying to install eventstore on ubuntu 20.04 but everytime I run evenstored --what-if (as root or as simple user, or as sudo) I get the following error message : Couldn't acquire exclusive lock on DB at '/eventstore/db'..
I tried many things :
I tried ensuring that eventstore user and group were owner of the folder.
reinstalling eventstore
rebooting server
stop process with systemctl stop eventstore and starting it back again
I also tried launching service first (as root / sudo or simple user) before using eventstored --what-if.
I can’t figure out why I keep getting this message as if many instance of eventstore where launched at the same time.
EDIT :
Here is my config file (/etc/eventstore/eventstore.conf)
# Paths
Db: /eventstore/db
Index: /eventstore/index
Log: /eventstore/logs
# Certificates configuration
CertificateFile: /etc/eventstore/certs/cert.crt
CertificatePrivateKeyFile: /etc/eventstore/certs/privkey.key
TrustedRootCertificatesPath: /etc/ssl/certs
CertificateReservedNodeCommonName: "*.mathob-jehanno.com"
# Network configuration
IntIp: 37.187.2.103
ExtIp: 37.187.2.103
IntHostAdvertiseAs: mathob-jehanno.com
ExtHostAdvertiseAs: mathob-jehanno.com
HttpPort: 2113
IntTcpPort: 1112
EnableExternalTcp: false
EnableAtomPubOverHTTP: false
# Projections configuration
RunProjections: None
It happened to me previously. I was running v20 without supplying the necessary settings like the certificates were missing. The server crashed because of this, but the last message you see is this Couldn't acquire exclusive lock on DB at '/eventstore/db'. You might look close and see if it's a warning, and the real reason for the crash is mentioned earlier in the stack trace of the original error.
Ok so
First of all, comments helped a lot :
this error message is following another one which give more detail about what the problem is.
One thing to know is that eventstored --what-if is supposed to be run while service is not running so user need to stop the service before (systemctl stop eventstore).
I then changed the path to db, index and logs file to match the default value (it prevented me some permissions error).
A rubber deployment as per quick start instruction using the latest 3.1.0 version reaches the stage of fetching and installing the gems (the last one loaded is pg), for an m1.small instance. I see no mention of therubyracer in the scroll of gems...
The process successfully completes deploy:setup, rubber:collectd:bootstrap, deploy:setup, deploy:update_code, but upon deploy:finalize_update the callback being triggered is bundle:install
Invariably, the process stalls at this point. The /etc/hosts/ file does refer to the proper configurations (52.25.135.252 production.foo.com ec2-52-25-135-252.us-west-2.compute.amazonaws.com ip-172-[...]).
One oddity is that trying to ssh into the the instance
ssh -i aws-eb production.foo.com
or via the ec-2 user
ssh -i aws-eb ec2-user#ec2-52-25-135-252.us-west-2.compute.amazonaws.com
the access is
Permission denied (publickey).
for a key that I was using with elastic beanstalk until a few days ago and had inserted into the confg/rubber/rubber.yml file.
I will attempt with a new key pair, but how can a key be now deemed public and unusable?
update
setting up a new keypair does not alter any behaviour. Process stuck at same point, cannot ssh into the instance. The production.foo.com does properly return, what is configured to this point, the nginx on ubuntu welcome page
As far as I can tell, having iterated about 10 times over this, memory of the instance is the issue.
The smallest instance that has not choked at this point is image_type: m3.medium. AMIs per instance type can be found here
The automatic suggestion of an m1.small in the vulcanization of the application is optimistic in my opinion.
I just delete a whole table in production... How could I perform a recovery or undo that delete ?
There is no backup
That sucks! Unfortunately RethinkDB doesn't keep data around after you delete it. Sometimes deleted data is still on disk somewhere if it hasn't been overwritten yet. If you google "{NAME OF YOUR OPERATING SYSTEM} recover deleted data" you should be able to find instructions on how to get everything salvageable. I'd recommend trying to keep write load as low as possible on the disk until you manage to recover whatever you can.
I need to start and stop a local infinispan cache programmatically. To start the cache initially, all I have to do is:
defaultcachemanager.getCache("local");
This happens when the system (karaf in this case) is coming up and works perfectly. To stop the cache, I do:
defaultcachemanager.stop();
Then when I try to start the same cache using:
defaultcachemanager.getCache("local");
it fails. I tried to do:
defaultcachemanager.startCache("local");
This fails with an exception
"Cache container has been stopped and cannot be reused. Recreate the cache container."
I guess the cache container is not started by then. But isn't
defaultcachemanager.startCache("local");
supposed to create and start the cache as well. I am not sure what I am missing. Do I need to create a new instance of
defaultcachemanager
again? I looked at the code for defaultcachemanager, I see only the cache entries being stopped, I do not see the instance itself being destroyed.
Pardon my ignorance as I started working on Infinispan just last week. Any pointers are greatly appreciated.
thanks,
Asha
By calling defaultcachemanager.stop(); you stopped the "whole" cache manager. Therefore, for now, there is no running instance of cache manager here.
All what you need is to stop cache itself, instead of stopping "whole" cache manager.
defaultcachemanager.getCache(cacheName).stop();
Stops a cache of given name.
defaultcachemanager.getCache(cacheName).start();
This is how you can re-start your local cache after stop.
defaultcachemanager.startCache(cacheName);
By this you can create another cache with given name using default configuration set by configuration builders during cache manager instantiation.
I messed up this.
Installed ZoneMinder and now I cannot connect to my VPS via Remote Desktop, it must probably have blocked connections. Didnt know it will start blocking right away and let me configure it before.
How can I solve this?
Note: My answer is under the assumption this is a Windows instance due to the use of 'Remote Desktop', even though ZoneMinder is primarily Linux-based.
Short answer is you probably can't and will likely be forced to terminate the instance.
But at the very least you can take a snapshot of the hard drive (EBS volume) attached to the machine, so you don't lose any data or configuration settings.
Without network connectivity your server can't be accessed at all, and unless you've installed other services on the machine that are still accessible (e.g. ssh, telnet) that could be used to reverse the firewall settings, you can't make any changes.
I would attempt the following in this order (although they're longshots):
Restart your instance using the AWS Console (maybe the firewall won't be enabled by default on reboot and you'll be able to connect).
If this doesn't work (which it shouldn't), you're going to need to stop your crippled instance, detach the volume, spin up another ec2 instance running Windows, and attach the old volume to the new instance.
Here's the procedure with screenshots of the exact steps, except your specific steps to disable the new firewall will be different.
After this is done, you need to find instructions on manually uninstalling your new firewall -
Take a snapshot of the EBS volume attached to it to preserve your data (essentially the C:), this appears on the EC2 console page under the 'volumes' menu item. This way you don't lose any data at least.
Start another Windows EC2 instance, and attach the EBS volume from the old one to this one. RDP into the new instance and attempt to manually uninstall the firewall.
At a minimum at this point you should be able to recover your files and service settings very easily into the new instance, which is the approach I would expect you to have more success with.