We are running into the situation, that when we shutdown the virtual ECS, we are afterwards no longer able to login to the web gui.
First I thought this could be the case when this is done shorty (minutes) after the install. But now that single node and multinode installation was running for days.
A search in the ECS admin guide for "shutdown" does not result in a search result.
What is the procedure to shutdown these ECS environments properly?
There isn't a necessary "safe" procedure to shut down ECS Community Edition; sounds like an issue with your install. Does it appear to be timing out or rejecting your credentials fairly immediately, and is this on a specific installation or both?
Within the container, you can check for login issues in /opt/storageos/logs/authsvc.log; depending on what you find, we can determine how to approach troubleshooting.
2016-04-29 07:50:08,171 [TaskScheduler-AuthService-DefaultScheduler-004] INFO TaskScheduler.java (line 437) Thread stats - total threads in application 248, total tasks 0
2016-04-29 07:50:14,460 [ZkConnection-17] INFO ZkConnection.java (line 216) check for changes in /data/vnest/vnest-main/configuration/coord-client
2016-04-29 07:50:18,172 [TaskScheduler-AuthService-DefaultScheduler-004] INFO TaskScheduler.java (line 430) Thread stats - total in thread pools: the active thread 1, pool size 210, queued tasks 0
2016-04-29 07:50:18,172 [TaskScheduler-AuthService-DefaultScheduler-004] INFO TaskScheduler.java (line 437) Thread stats - total threads in application 248, total tasks 0
2016-04-29 07:50:18,243 [client-heart-beat-monitor-000] INFO ClientHeartBeatImpl.java (line 66) start hb run
2016-04-29 07:50:24,460 [ZkConnection-17] INFO ZkConnection.java (line 216) check for changes in /data/vnest/vnest-main/configuration/coord-client
2016-04-29 07:50:28,172 [TaskScheduler-AuthService-DefaultScheduler-004] INFO TaskScheduler.java (line 430) Thread stats - total in thread pools: the active thread 1, pool size 210, queued tasks 0
2016-04-29 07:50:28,172 [TaskScheduler-AuthService-DefaultScheduler-004] INFO TaskScheduler.java (line 437) Thread stats - total threads in application 248, total tasks 0
[root@ecssinglenode /]#
Nothing regarding my login attempt from just now, may second.
What are the steps required to startup the whole ECS stuff on the single node installation?
Maybe just the startup of these are not done automatically.
Are there any ps | grep commands to find out of the necessary processes are running? Service status commands?
I don't see any docker processes with ecs or docker in their command.
The fact that you're missing the entirety of your /opt directory is concerning - it contains a big chunk of your configuration files, so you're likely to see more issues stem from this. Depending on how much data you've already written and the relative simplicity of teardown/rebuild, it might pay to reinstall the node in this case.
The installation should set docker to start itself and the container on restart (service docker start and docker start ecsstandalone), which is all that should be necessary to bring the container up. You can verify these with service docker status and docker ps -a (adding the -a flag will make the output show non-running containers).
In the container itself, you can use service -s to get all services; there should be a list near the bottom that tells you all of the running services. I believe the full list should be
Could it be that the minimal edition is the problem? I can try a server with gui version if you think it makes a difference. It is just that in one of the responses I saw that a minimal edition should be fine.
Sorry, I should have been more specific: from the VM on which the docker container is running, you can enter the container using the command nsenter -i -m -p -u -t `pidof blobsvc` and from there use the service --status-all command to get the list of services running on the ECS.
A minimal installation of CentOS should be absolutely fine for ECSCE; it's what we mostly use for testing.
Thanks for your continued help. But this stuff really s***.
Initial install works, I can connect. But run in to internal errors when creating users and buckets.
Then no reconnect is possible anymore. Rebooting leads to the same issue not being able to connect.
Is there anybody out there who has really gotten this to work? I'm happy to pay up to one day for the guy who gets a virtual ecs single node up and running with a user and bucket configuration. The environment will have to survive reboots of the vm and the installation steps have to be documented and repeatable.
See above for what I've don on my ESX Server. Access via Webex or Teamviewer possible.
In case it helps anybody. Issued a service docker status after the reboot of the VM: Guess what, docker was not running. It really looks like EMC still needs to work quite a bit on these install and other scripts. Reinstalled today with the latest online EMCECS version.
Aaron_Peterson
1 Rookie
•
26 Posts
4880
0
Posted May 19th, 2016 11:00
Jakob,
After a VM shutdown, if your docker container doesn't come back up automatically you can start it with
docker start ecsstandalone
(or docker start ecsmultinode if you're using a multi-node installation)
- Aaron