kstyrc/embedded-redis

Unable to run on macOS Sonoma

Opened this issue ยท 18 comments

This worked before I upgraded to macOS Sonoma. Now I get this error message:

java.lang.RuntimeException: Can't start redis server. Check logs for details. Redis process log: 

	at redis.embedded.AbstractRedisInstance.awaitRedisServerReady(AbstractRedisInstance.java:70)
	at redis.embedded.AbstractRedisInstance.start(AbstractRedisInstance.java:42)
	at redis.embedded.RedisServer.start(RedisServer.java:9)

have the same problem

have the same problem

#127 (comment)
I follow the comment to set up local redisExecProvider when create redis server, then solve the problem.

same problem with you

having the same problem

I have the same problem. I have modified the code in this repository https://github.com/vjsantojaca/embedded-redis and now the tests pass without error (I have not upload it to a maven repository)

I am trying to update the redis version to a new one.

Anyway, I think that the correct way would be change the dependencies that we have with this library in our repository and use testcontainers.

    redis = new GenericContainer(DockerImageName.parse("redis:7.0.0").toString()).withExposedPorts(6379);
    redis.start();

    String host =  redis.getContainerIpAddress();
    Integer port = redis.getMappedPort(6379);

    System.out.println("Redis -> " + host + ":" + port);

@codemonstur's build with maven repo worked to fix for me.

https://mvnrepository.com/artifact/com.github.codemonstur/embedded-redis/1.0.0

Unfortunately this works in Intel macs but not on M1 macs

Unfortunately this works in Intel macs but not on M1 Macs

Yeah, that's kinda sad. Luckily the customised Redis version by @vjsantojaca does work on my m2 Mac ๐Ÿ’ช๐Ÿป!

Most likely security policies forbid the Redis binary from starting. The security policies seems to have been tightened in Sonoma. You can confirm that yourself with the Console app. Learn a bit more about it over here. In a nutshell, you start recording messages, filter for redis and run whatever code uses embedded-redis. Eventually you might see something like this:

ASP: Security policy would not allow process <pid>

One way to get past this policy is to grant permission to certain programs in the Developer Tools settings. We've been successful in granting java permissions.

yes-java

You will have to point at your java binary. Depending on how you install it, it will be in different places. which java can help. SDKman and brew put binaries in special locations.

Once you grant java with permissions, run your things again but make sure that there are new PIDs. For example, when you use gradle, say --no-daemon to not reuse an existing daemon which might not have elevated permissions yet.

โ— Disclaimer: this is potentially unsafe. zero warranty. you have been warned. yak yak.

finally it works for me @mamachanko appreciate for your help

Another option is to move to a maintained fork that has addressed this issue:
https://github.com/codemonstur/embedded-redis

This worked for me MacOS Sonoma 14.1.1 (23B81) M1.

Another option is to move to a maintained fork that has addressed this issue: https://github.com/codemonstur/embedded-redis

This worked for me MacOS Sonoma 14.1.1 (23B81) M1.

Thanks, that repo worked for me with 14.1.1 (23B81), 2019 mac.
The only difference between these repos was that RedisServer.builder() had to be replaced with RedisServer.newRedisServer()

Another option is to move to a maintained fork that has addressed this issue: https://github.com/codemonstur/embedded-redis

This worked for me MacOS Sonoma 14.1.1 (23B81) M1.

Thanks, the same has worked for me with 14.1.1 (23B81) M2 as well

@codemonstur's build with maven repo worked to fix for me.

https://mvnrepository.com/artifact/com.github.codemonstur/embedded-redis/1.0.0

Thanks! This works on me (mac M2 pro 14.2.1)

I am on Mac M2 Pro Sonoma. But unfortunately it does not work for me. I get the following error while running the builds. I am using latest version 1.4.1. I have also tried 1.0.0 as well.

Caused by: java.io.IOException: Ready pattern not found in log. Startup log:
at redis.embedded.RedisInstance.awaitServerReady(RedisInstance.java:59)
at redis.embedded.RedisInstance.start(RedisInstance.java:45)
... 92 more

@Bean("EmbeddedRedisConfig") public EmbeddedRedisConfig embeddedRedisConfig() throws IOException { int redisPort = 6381; redisServer = RedisServer.newRedisServer().port(redisPort).build(); redisServer.start(); log.info("Started redis server on port {}", redisPort); return new EmbeddedRedisConfig(redisServer, redisPort); }

@mamachanko's option worked for me on M1 Airbook, 14.3.1. I had to enable this for both Java and IntelliJ also -- the screenshot hints at IntelliJ but has it turned off. Also, which java misled me, it did not show brew's installation path, but echo $JAVA_HOME and then /bin/java did.

I wasn't able to use the codemunster fork because it broke in our Jenkins pipeline running on Linux with java.io.IOException: Ready pattern not found in log. Startup log.

@mamachanko's option worked for me on M1 Airbook, 14.3.1. I had to enable this for both Java and IntelliJ also -- the screenshot hints at IntelliJ but has it turned off. Also, which java misled me, it did not show brew's installation path, but echo $JAVA_HOME and then /bin/java did.

I wasn't able to use the codemunster fork because it broke in our Jenkins pipeline running on Linux with java.io.IOException: Ready pattern not found in log. Startup log.

it works for me.

@michellemillerh

I wasn't able to use the codemunster fork because it broke in our Jenkins pipeline running on Linux with java.io.IOException: Ready pattern not found in log. Startup log.

This is the error that you get when the Redis binary doesn't start up at all. Theoretically it could be anything but lots of people appear to have trouble because they run the binary on a host that doesn't have libssl.so installed. If you run the latest version of the library it should give you a more detailed error message that says as much. Installing libssl on the host is the solution most people go for.