Error the store is configured for another project

√ SEO продвижение: поиск новых точек роста, экспертный аудит сайтов ( http://akazansky.ru/audit-sajtov ), внедрение эффективных решений цифрового маркетинга. Обстоятельно, ответственно, доступно.

Для скромного,бюджетного,экономного варианта может пойти

на тильде очень много ошибок и рваного кода. И это уже существенный минус при ранжировании

Когда-то здесь будет реклама.

Производство жести методом непрерывного отжига

POST http://localhost:5000/account/deposit HTTP/1.1
Content-Type: application/json

{ 
    "id": "17", 
    "amount": 12 
}

HTTP/1.1 500 Internal Server Error
Connection: close
Date: Thu, 07 May 2020 05:38:36 GMT
Content-Type: text/plain
Server: Kestrel
Transfer-Encoding: chunked

Grpc.Core.RpcException: Status(StatusCode=Unknown, Detail="ERR_STATE_STORE_NOT_CONFIGURED")
   at Dapr.Client.DaprClientGrpc.MakeGrpcCallHandleError[TResponse](Func`2 callFunc, CancellationToken cancellationToken)
   at Dapr.Client.DaprClientGrpc.GetStateAndETagAsync[TValue](String storeName, String key, Nullable`1 consistencyMode, CancellationToken cancellationToken)
   at Dapr.Client.DaprClient.GetStateEntryAsync[TValue](String storeName, String key, Nullable`1 consistencyMode, CancellationToken cancellationToken)
   at DaprPoc.BankingApi.Controllers.AccountController.Deposit(Transaction transaction, DaprClient daprClient) in /home/tda/git/dapr.poc/src/DaprPoc.BankingApi/Controllers/AccountController.cs:line 61
   at lambda_method(Closure , Object )
   at Microsoft.Extensions.Internal.ObjectMethodExecutorAwaitable.Awaiter.GetResult()
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.AwaitableObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

HEADERS
=======
Connection: close
Content-Type: application/json
Accept-Encoding: gzip, deflate
Host: localhost:5000
User-Agent: vscode-restclient
Content-Length: 39

### 
POST http://localhost:5000/account/deposit HTTP/1.1
Content-Type: application/json

{ 
    "id": "17", 
    "amount": 12 
}

Be The First To Get Support Updates

Want to know about the latest technical content and software updates?

In some instances, services cannot be deleted, started, or stopped, and a «Stopping…» (or «Starting…») message is displayed in ArcGIS Server Manager. When an attempt is made to delete, start, or stop the service, the following message displays:

Error:   
Service is currently being configured by another administrative operation.

The error occurs due to the following reasons:

• The service has a corrupt lock file.
• The service shows a different status for the real-time state and the configured state. (The status of a service can be viewed in the ArcGIS Server Administrator Directory from services > [service name] > status.)
• There is a change in permissions of the ArcGIS Server account for the following folders: arcgisserver, C:Program FilesArcGISServer, or Python27.

To resolve the error, run the Configure ArcGIS Server Account utility (for Windows), and restart the ArcGIS Server Windows service. If the site has multiple ArcGIS Server machines, ensure that the process is done on all machines. This verifies the required permissions are set and clears out any corrupt lock files. Follow the steps below to run the Configure ArcGIS Server Account utility.

Note:
Running the Configure ArcGIS Server Account utility requires the user name and password of the account that is used to run ArcGIS Server. The account can be either a domain account or a local account. If the account is not known, find the account by looking in the Windows Services console. For more information, refer to ArcGIS Enterprise: Installation Guides - The ArcGIS Server account

1. Identify the config-store, directories, and logs locations. By default, they are stored in C:arcgisserver and can also be viewed in ArcGIS Server Manager.

Note:
Note down the locations if necessary as the locations are required in a later step. 

1. On the ArcGIS Server Manager main menu, click Site > Configuration Store to view the locations of the config-store and directories.

1. Click Logs > Settings to view the logs location.

1. Open the Configure ArcGIS Server Account utility from the Windows Start menu (All Programs > ArcGIS > ArcGIS Server > Configure ArcGIS Server Account), type in the user name and password of the ArcGIS Server Account, and click Next.

1. Enter the paths for the directories, config-store, and logs, and click Next. 

1. Select whether to export a configuration file to use on other machines in the site (if applicable), and click Next.

1. Click Configure in the next window to begin the configuration process.
2. Restart the ArcGIS Server Windows service when the configuration completes. If there are other machines in the site, repeat the same workflow on each machine.

Note:
For Linux users, set file permissions manually for the config-store and directories because the Configure ArcGIS Server Account utility is not supported in Linux, and then, restart the ArcGIS Server Linux service.

• Error: ArcGIS Server site is currently being configured by another administrative operation. Please try again later
• Error: Invalid password specified for arcgis

Last Published: 9/10/2019

Article ID: 000015549

Software: ArcGIS GeoAnalytics Server 10.7.1, 10.7, 10.6.1, 10.6, 10.5.1, 10.5

During writes to Redis ( SET foo bar ) I am getting the following error:

MISCONF Redis is configured to save RDB snapshots, but is currently
not able to persist on disk. Commands that may modify the data set are
disabled. Please check Redis logs for details about the error.

Basically I understand that the problem is that redis is not able to save data on the disk, but have no idea how to get rid of the problem.

Also the following question has the same problem, it is abandoned long time ago with no answers and most probably no attempts to solve the problem.

In case you encounter the error and some important data cannot be discarded on the running redis instance (problems with permissions for the rdb file or its directory incorrectly, or running out of disk space), you can always redirect the rdb file to be written somewhere else.

Using redis-cli, you can do something like this:

CONFIG SET dir /tmp/some/directory/other/than/var
CONFIG SET dbfilename temp.rdb

After this, you might want to execute a BGSAVE command to make sure that the data will be written to the rdb file. Make sure that when you execute INFO persistence, bgsave_in_progress is already 0 and rdb_last_bgsave_status is ok. After that, you can now start backing up the generated rdb file somewhere safe.

Using redis-cli, you can stop it trying to save the snapshot:

config set stop-writes-on-bgsave-error no

This is a quick workaround, but if you care about the data you are using it for, you should check to make sure why bgsave failed in first place.

Restart your redis server.

• macOS (brew): brew services restart redis.
• Linux: sudo service redis restart / sudo systemctl restart redis
• Windows: Windows + R -> Type services.msc, Enter -> Search for Redis then click on restart.

I personally had this issue after upgrading redis with Brew (brew upgrade).
After rebooting the laptop, it immediately worked.

There might be errors during the bgsave process due to low memory. Try this (from redis background save FAQ)

echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1

This error occurs because of BGSAVE being failed. During BGSAVE, Redis forks a child process to save the data on disk. Although exact reason for failure of BGSAVE can be checked from logs (usually at /var/log/redis/redis-server.log on linux machines) but a lot of the times BGAVE fails because the fork can’t allocate memory. Many times the fork fails to allocate memory (although the machine has enough RAM available) because of a conflicting optimization by the OS.

As can be read from Redis FAQ:

Redis background saving schema relies on the copy-on-write semantic of fork in modern operating systems: Redis forks (creates a child process) that is an exact copy of the parent. The child process dumps the DB on disk and finally exits. In theory the child should use as much memory as the parent being a copy, but actually thanks to the copy-on-write semantic implemented by most modern operating systems the parent and child process will share the common memory pages. A page will be duplicated only when it changes in the child or in the parent. Since in theory all the pages may change while the child process is saving, Linux can’t tell in advance how much memory the child will take, so if the overcommit_memory setting is set to zero fork will fail unless there is as much free RAM as required to really duplicate all the parent memory pages, with the result that if you have a Redis dataset of 3 GB and just 2 GB of free memory it will fail.

Setting overcommit_memory to 1 says Linux to relax and perform the fork in a more optimistic allocation fashion, and this is indeed what you want for Redis.

Redis doesn’t need as much memory as the OS thinks it does to write to disk, so may pre-emptively fail the fork.

To Resolve this, you can:

Modify /etc/sysctl.conf and add:

vm.overcommit_memory=1

Then restart sysctl with:

On FreeBSD:

sudo /etc/rc.d/sysctl reload

On Linux:

sudo sysctl -p /etc/sysctl.conf

in case you are working on a linux machine, also recheck the file and folder permissions of the database.

The db and the path to it can be obtained via:

in redis-cli:

CONFIG GET dir

CONFIG GET dbfilename

and in the commandline ls -l. The permissions for the directory should be 755, and those for the file should be 644. Also, normally redis-server executes as the user redis, therefore its also nice to give the user redis the ownership of the folder by executing sudo chown -R redis:redis /path/to/rdb/folder. This has been elaborated in the answer here.

Thanks everyone for checking the problem, apparently the error was produced during bgsave.

For me, typing config set stop-writes-on-bgsave-error no in a shell and restarting Redis solved the problem.

Start Redis Server in a directory where Redis has write permissions

The answers above will definitely solve your problem, but here’s what’s actually going on:

The default location for storing the rdb.dump file is ./ (denoting current directory). You can verify this in your redis.conf file. Therefore, the directory from where you start the redis server is where a dump.rdb file will be created and updated.

It seems you have started running the redis server in a directory where redis does not have the correct permissions to create the dump.rdb file.

To make matters worse, redis will also probably not allow you to shut down the server either until it is able to create the rdb file to ensure the proper saving of data.

To solve this problem, you must go into the active redis client environment using redis-cli and update the dir key and set its value to your project folder or any folder where non-root has permissions to save. Then run BGSAVE to invoke the creation of the dump.rdb file.

CONFIG SET dir "/hardcoded/path/to/your/project/folder"
BGSAVE

(Now, if you need to save the dump.rdb file in the directory that you started the server in, then you will need to change permissions for the directory so that redis can write to it. You can search stackoverflow for how to do that).

You should now be able to shut down the redis server. Note that we hardcoded the path. Hardcoding is rarely a good practice and I highly recommend starting the redis server from your project directory and changing the dir key back to./`.

CONFIG SET dir "./"
BGSAVE

That way when you need redis for another project, the dump file will be created in your current project’s directory and not in the hardcoded path’s project directory.

If you’re running MacOS and have recently upgraded to Catalina, you may need to run brew services restart redis as suggested in this issue.

Had encountered this error and was able to figure out from log that the error is because of the disk space not being enough. All the data that was inserted in my case was not needed any longer. So I tried to FLUSHALL. Since redis-rdb-bgsave process was running, it was not allowing to FLUSH the data also. I followed below steps and was able to continue.

1. Login to redis client
2. Execute config set stop-writes-on-bgsave-error no
3. Execute FLUSHALL (Data stored was not needed)
4. Execute config set stop-writes-on-bgsave-error yes

The process redis-rdb-bgsave was no longer running after the above steps.

A more permanent fix might be to look in /etc/redis/redis.conf around lines 200-250 there are settings for the rdb features, that were not a part of redis back in the 2.x days.

notably

dir ./

can be changed to

dir /home/someuser/redislogfiledirectory

or you could comment out all the save lines, and not worry about persistence. (See the comments in /etc/redis/redis.conf)

Also, don’t forget

service redis-server stop
service redis-server start

I faced the similar issue, the main reason behind this was the memory(RAM) consumption by redis.
My EC2 machine had 8GB RAM(arounf 7.4 available for consumption)

When my program was running the RAM usage went upto 7.2 GB leaving hardly ~100MB in RAM , this generally triggers the MISCONF Redis error ...

You can determine the RAM consumption using the htop command. Look for the Mem attribute after running htop command. If it shows high consumtion (like in my case it was 7.2GB/7.4GB) It’s better to upgrade the instance’s with larger Memory.
In this scenario using config set stop-writes-on-bgsave-error no will be a disaster for the server and may result in disrupting other services running on the server(if any). So, it better to avoid the config command and UPGRADE YOUR REDIS MACHINE.

FYI: You may need to install htop to make this work : sudo apt-get install htop

One more solution to this can be some other RAM heavy service running on your system, check for other service running on your server/machine/instance and stop it if its not necessary. To check all the services running on your machine use service --status-all

And a suggestion for people directly pasting the config command , please do reasearch a bit and atleast warn the user before using such commands. And as @Rodrigo mentioned in his comment : «It does not look cool to ignore the errors.»

—UPDATE—

YOu can also configure maxmemory and maxmemory-policy to define the behavior of Redis when a specific limit of memory is reached.
For example, if I want to keep the memory limit of 6GB and delete the least recently used keys from the DB to make sure that redis mem usage do not exceed 6GB, then we can set these two parameters (in redis.conf or CONFIG SET command):

maxmemory 6gb
maxmemory-policy allkeys-lru

There are a lot of other values which you can set for these two parameters you can read about this from here: https://redis.io/topics/lru-cache

all of those answers do not explain the reason why the rdb save failed.

as my case, I checked the redis log and found:

14975:M 18 Jun 13:23:07.354 # Background saving terminated by signal 9

run the following command in terminal:

sudo egrep -i -r 'killed process' /var/log/

it display:

/var/log/kern.log.1:Jun 18 13:23:07 10-10-88-16 kernel: [28152358.208108] Killed process 28416 (redis-server) total-vm:7660204kB, anon-rss:2285492kB, file-rss:0kB

that is it! this process(redis save rdb) is killed by OOM killer

refers:

https://github.com/antirez/redis/issues/1886

Finding which process was killed by Linux OOM killer

Nowadays the Redis write-access problems that give this error message to the client re-emerged in the official redis docker containers.

Redis from the official redis image tries to write the .rdb file in the containers /data folder, which is rather unfortunate, as it is a root-owned folder and it is a non-persistent location too (data written there will disappear if your container/pod crashes).

So after an hour of inactivity, if you have run your redis container as a non-root user (e.g. docker run -u 1007 rather than default docker run -u 0), you will get a nicely detailed error msg in your server log (see docker logs redis):

1:M 29 Jun 2019 21:11:22.014 * 1 changes in 3600 seconds. Saving...
1:M 29 Jun 2019 21:11:22.015 * Background saving started by pid 499
499:C 29 Jun 2019 21:11:22.015 # Failed opening the RDB file dump.rdb (in server root dir /data) for saving: Permission denied
1:M 29 Jun 2019 21:11:22.115 # Background saving error

So what you need to do is to map container’s /data folder to an external location (where the non-root user, here: 1007, has write access, such as /tmp on the host machine), e.g:

docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis

So it is a misconfiguration of the official docker image (which should write to /tmp not /data) that produces this «time bomb» that you will most likely encounter only in production… overnight over some particularly quiet holiday weekend :/

for me

config set stop-writes-on-bgsave-error no

and I reload my mac, it works

$ redis-cli

config set stop-writes-on-bgsave-error no

According to Redis documentation, this is recommended only if you don’t have RDB snapshots enabled or if you don’t care about data persistence in the snapshots.

«By default Redis will stop accepting writes if RDB snapshots are enabled (at least one save point) and the latest background save failed. This will make the user aware (in a hard way) that data is not persisting on disk properly, otherwise,strong text chances are that no one will notice and some disaster will happen.»

What u should be doing is :

redis-cli

127.0.0.1:6379> CONFIG SET dir /data/tmp
OK
127.0.0.1:6379> CONFIG SET dbfilename temp.rdb
OK
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379>
Please Make sure /data/tmp has enough disk space.

I too was facing the same issue. Both the answers (the most upvoted one and the accepted one) just give a temporary fix for the same.

Moreover, the config set stop-writes-on-bgsave-error no is a horrible way to over look this error, since what this option does is stop redis from notifying that writes have been stopped and to move on without writing the data in a snapshot. This is simply ignoring this error.
Refer this

As for setting dir in config in redis-cli, once you restart the redis service, this shall get cleared too and the same error shall pop up again. The default value of dir in redis.conf is ./ , and if you start redis as root user, then ./ is / to which write permissions aren’t granted, and hence the error.

The best way is to set the dir parameter in redis.conf file and set proper permissions to that directory. Most of the debian distributions shall have it in /etc/redis/redis.conf

After banging my head through so many SO questions finally —
for me @Axel Advento’ s answer worked but with few extra steps —
I was still facing the permission issues.
I had to switch user to redis, create a new dir in it’s home dir and then set it as redis’s dir.

sudo su - redis -s /bin/bash
mkdir redis_dir
redis-cli CONFIG SET dir $(realpath redis_dir)
exit # to logout from redis user (optional)

I know this thread is slightly older, but here’s what worked for me when I got this error earlier, knowing I was nowhere near memory limit- both answers were found above.

Hopefully this could help someone in the future if they need it.

1. Checked CHMOD on dir folder… found somehow the symbolic notation was different. CHMOD dir folder to 755
2. dbfilename permissions were good, no changes needed
3. Restarted redis-server
4. (Should’ve done this first, but ah well) Referenced the redis-server.log and found that the error was the result of access being denied.

Again- unsure how the permissions on the DIR folder got changed, but I’m assuming CHMOD back to 755 and restarting redis-server took care of it as I was able to ping redis server afterwards.

Also- to note, redis did have ownership of the dbfilename and DIR folder.

On redis.conf line ~235 let’s try to change config like this

- stop-writes-on-bgsave-error yes
+ stop-writes-on-bgsave-error no

I hit this problem while working on a server with AFS disk space because my authentication token had expired, which yielded Permission Denied responses when the redis-server tried to save. I solved this by refreshing my token:

kinit USERNAME_HERE -l 30d && aklog

In case you are using docker/docker-compose and want to prevent redis from writing to file, you can create a redis config and mount into a container

docker.compose.override.yml

  redis:¬
      volumes:¬
        - ./redis.conf:/usr/local/etc/redis/redis.conf¬
      ports:¬
        - 6379:6379¬

You can download the default config from here

in the redis.conf file make sure you comment out these 3 lines

save 900 1
save 300 10
save 60 10000

myou can view more solutions for removing the persistent data here

In my case it happened because I just installed redis using the quick way. So redis is not running as root.
I was able to solve this problem by following the instructions under the Installing Redis more properly section of their Quick Start Guide. After doing so, the problem was solved and redis is now running as root. Check it out.

Check your Redis log before taking any action. Some of the solutions in this thread may erase your Redis data, so be careful about what you are doing.

In my case, the machine was running out of RAM. This also can happen when there is no more free disk space on the host.

In my case it was related to disk free space. (you can check it with df -h bash command) when I free some space this error disappeared.

If you are running Redis locally on a windows machine, try to «run as administrator» and see if it works. With me, the problem was that Redis was located in the «Program Files» folder, which restricts permissions by default. As it should.

However, do not automatically run Redis as an administrator You don’t want to grant it more rights that it is supposed to have. You want to solve this by the book.

So, we have been able to quickly identify the problem by running it as an administrator, but this is not the cure. A likely scenario is that you have put Redis in a folder that doesn’t have write rights and as a consequence the DB file is stored in that same location.

You can solve this by opening the redis.windows.conf and to search for the following configuration:

    # The working directory.
    #
    # The DB will be written inside this directory, with the filename specified
    # above using the 'dbfilename' configuration directive.
    #
    # The Append Only File will also be created inside this directory.
    #
    # Note that you must specify a directory here, not a file name.
    dir ./

Change dir ./ to a path you have regular read/write permissions for

You could also just move the Redis folder in it’s entirety to a folder you know has the right permissions.

Please, be aware, that this error appears when your server is under attack. Just found that redis fails to write to ‘/etc/cron.d/web’ where after correcting of permissions, new file consisting of mining algorithm with some hiding options was added.

# on redis 6.0.4 
# if show error 'MISCONF Redis is configured to save RDB snapshots'
# Because redis doesn't have permissions to create dump.rdb file
sudo redis/bin/redis-server 
sudo redis/bin/redis-cli

check the permission in dir : var/lib/redis it should be redis:redis