I installed Redis version 4.0.9 in a Ubuntu Linux Subsystem on Windows 10 by following these instructions (i.e. sudo apt-get install redis-server).
I am following this tutorial on Django channels, and I ran the following code:
>>> import channels.layers
>>> channel_layer = channels.layers.get_channel_layer()
>>> from asgiref.sync import async_to_sync
>>> async_to_sync(channel_layer.send)('test_channel', {'type': 'hello'})
>>> async_to_sync(channel_layer.receive)('test_channel')
When the last line above is executed, I get this error:
Traceback (most recent call last):
File "<input>", line 1, in <module>
File "C:\Users\xyz\Anaconda3\envs\django\lib\site-packages\asgiref\sync.py", line 120, in __call__
return call_result.result()
File "C:\Users\xyz\Anaconda3\envs\django\lib\concurrent\futures\_base.py", line 425, in result
return self.__get_result()
File "C:\Users\xyz\Anaconda3\envs\django\lib\concurrent\futures\_base.py", line 384, in __get_result
raise self._exception
File "C:\Users\xyz\Anaconda3\envs\django\lib\site-packages\asgiref\sync.py", line 180, in main_wrap
result = await self.awaitable(*args, **kwargs)
File "C:\Users\xyz\Anaconda3\envs\django\lib\site-packages\channels_redis\core.py", line 485, in receive
return (await self.receive_single(channel))[1]
File "C:\Users\xyz\Anaconda3\envs\django\lib\site-packages\channels_redis\core.py", line 508, in receive_single
index, channel_key, timeout=self.brpop_timeout
File "C:\Users\xyz\Anaconda3\envs\django\lib\site-packages\channels_redis\core.py", line 345, in _brpop_with_clean
result = await connection.bzpopmin(channel, timeout=timeout)
aioredis.errors.ReplyError: ERR unknown command 'BZPOPMIN'
On this page, someone suggested using Redis version 5. How do I install Redis version 5 on Windows 10? Any other ideas on how to solve this issue?
I think the problem is in the compatibility with version of the channels-redis package! I had already tested channels some time ago and it worked beautifully with channels-redis version 2.4.2, recently they are in version 3.0.1 and this version doesn't work properly yet I don't know why.
Try install the version 2.4.2 with pip:
pip install channels-redis==2.4.2
Use redis 5.0.9. It worked for for the same error.
Get it from github.com/tporadowski/redis/releases
There is no official support for Redis in Windows OS.
However, Microsoft develops and maintains microsoftarchive/redis. Also it is no longer supported (older versions are availble). I had long search on this about installing version 5 in windows 10. But no luck.
Better you can go for Memurai. Memurai is 100% compatible with the Redis protocol (also supported version 5 too). It is free for development and testing.
EDIT : From Itamar comment, u can also use this as alternative for Memurai
Just download the latest version of Redis for Windows https://github.com/tporadowski/redis/releases from here it will work.
you don't need to downgrade the version of your channels-redis etc. This problem with Redis not with any python packages at all.
You need to install the latest version(6+) of redis:
$ sudo add-apt-repository ppa:redislabs/redis
$ sudo apt-get update
$ sudo apt-get install redis
then restart the redis-server.
This is how i resolve this issue.
Ubuntu 18 installs redis 4 but ubuntu 20 installs redis 5. You can find your redis version by typing redis-cli -v. So i uninstall ubuntu 18 from my windows subsystem for linux (WSL) and reinstall ubuntu 20. It worked just fine.
Same problem on Ubuntu 16.04
Similarly, I was following the chat application tutorial on Django Channels website and had the same error:
aioredis.errors.ReplyError: ERR unknown command 'BZPOPMIN'
The problem occurred when I used these versions:
redis-server==3.0.6
channels==3.0.3
channels-redis==3.2.0
Thanks to #marvin-correia for his answer I figured out the problem's reason is the version of the channels-redis package! So as he suggested, I installed channel-redis version 2.4.2 and the error has gone.
pip install channels-redis==2.4.2
Also, I've to note that channels package downgraded to channels==2.4.0 automatically.
Problem is with the version.
Try older one
I found "2,3,4" any version with it stable and properly working.
https://github.com/tporadowski/redis/releases
To add to #Marvin answer, for me it was similar (some versioning problem probably), I reinstalled django_channels and django to the exact version as specified in the tutorial (3.0, 2.2) and it worked. Not sure what exactly worked but recommend checking it:)
I will also confirm Marvins answer. Hopefully this will help someone out but also leaving this here for notes.
Development:
(this setup works) considering data is sent to and form http://localhost:8000
Setup
Windows 10 Running WSL with Ubuntu 20.04
Python==3.10
Django==4.0
Redis==5.0.7
channels-redis==3.3.1
Production
setup
Python==3.8
Ubuntu==16.04
Redis-server==3.0.6
chanels-redis==2.4.2
channels==3.0.3
When I downgraded, channels-redis, it automcatically downgraded channels as well. Then you can force the upgrade to channels==3.0.3, but it will raise an incompatibility error. Also, if 2 files will most likely to be updated to run Django 4.0
1 being here
https://github.com/django/channels/issues/1609
I was getting this error on a Windows machine, I would suggest you to use Redis on a docker image instead of using Redis server on a windows machine.
One of the way to run a redis server via a docker image and map the port 6379 is to:
start docker desktop
In your terminal type the below command.
docker run -p 6379:6379 -d redis:5
I'm trying to get unison working after upgrading to Mac OS X Catalina. Unfortunately, macports installs a more recent version of ocaml (4.08.1), which means that the unison 2.51.2 release won't compile.
Well, that's no problem, I just update to git master on unison, and recompile. Unfortunately, this fails at sync time because the version of ocaml used to compile on the mac (4.08.1) is different from the one used to compile on the other machine (4.07.1). Sigh. Okay, use opam magic to install 4.07.1 on my machine. Everything should be fine, right? No!
Here's the error:
Connected [//zzzmyhost//home/clements/unison-home -> //zzzmyotherhost//Users/clements/clements]
Looking for changes
Uncaught exception Failure("input_value: ill-formed message")
Raised at file "/private/tmp/unison/src/lwt/lwt.ml", line 126, characters 16-23
Called from file "/private/tmp/unison/src/lwt/generic/lwt_unix_impl.ml", line 102, characters 8-23
Called from file "/private/tmp/unison/src/update.ml" (inlined), line 2105, characters 2-69
Called from file "/private/tmp/unison/src/uitext.ml", line 978, characters 16-56
Called from file "/private/tmp/unison/src/uitext.ml", line 1066, characters 6-90
Called from file "/private/tmp/unison/src/uitext.ml", line 1088, characters 19-66
Called from file "/private/tmp/unison/src/uitext.ml", line 1144, characters 21-43
What's going on?
Sigh... the problem here (very non-obvious) is actually with a corrupted/wrong-format syncronization file, created when doing the failed sync in the earlier test.
The solution is just to go into ~/Library/Application Support/Unison (on a UNIX machine this path would presumably live in ~/.unison and delete the archive file that's causing the problem (probably the most recent one). In a pinch, just delete all of the archive files and start over.
I've got the same problem between Windows and Ubuntu 20.04 after upgrading from Ubuntu 18.04. I tried the binary from Ubuntu 18.04 in 20.04, which still fails, so the incompatibility is likely inside one of the dependencies.
As a workaround I created a Docker image based on Ubuntu 18.04:
FROM ubuntu:18.04
RUN apt-get update && apt-get dist-upgrade -y
RUN apt-get install unison -y
RUN useradd martin --home /home/martin
WORKDIR /home/martin
USER martin
Building it with docker build -t unison:18.04 .
And then I added a wrapper to ~/bin/unison-2.48.4-docker:
#!/bin/bash
docker run --rm -i \
-v /home/martin/dirtosync:/home/martin/dirtosync \
-v /home/martin/.unison:/home/martin/.unison \
--hostname $(hostname) \
unison:18.04 unison "$#"
Setting the --hostname is important, since the hostname is part of the archive file.
Inside the profile on my Windows machine I configured:
servercmd = ~/bin/unison-2.48.4-docker
In my setup with two windows clients and one Ubuntu 18.04 server, connected by ssh, the problem startet with a second server running on Ubuntu 20.04. Neither the old server nor the windows clients could sync with the new machine.
My solution: Copying the binary from Ubuntu 18.04 to a new directory in the Ubuntu 20.04 machine. This new file is referenced in the "authorized_keys" file of ssh on the new machine.
So far, everything works great with unison 2.48.4.
Host OS: Windows 10
Vagrant: 2.2.4
VirtualBox: 6.0.6 r130049
When I run vagrant up, it prints this error message:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
setup
Stdout from the command:
Stderr from the command:
bash: line 4: setup: command not found
The machine can be booted normally and SSH from my host to Virtual machine is OK but the synced folder is not working. I know this may not be a critical issue but still feel frustrated as I use my host machine to develop codes and "sync" these codes so that they can be loaded in my virtual machine.
Any advice is highly appreciated.
ps: When I boot a full UI virtual machine (different from my above mentioned) from my VirtualBox directly, it seems OK to have a "sync" directory and the VBGuestAdditions can be installed without errors.
It is a bug in VirtualBox 6.0.6 and it still exists in 6.0.8. The solution is to downgrade your VirtualBox itself and the Guest Extensions to 6.0.4.
As a person working on a Windows machine but enjoying Ubuntu as a working environment I'd like to use ddev in WSL. Is there a way to do that?
2021 Update: DDEV has WSL2 install instructions.
(2018-11-15: Updated for ddev v1.4.0)
It's pretty tweaky, but it can be done. Note that there are no tests or performance results on this, and it's not a supported technique.
Note that WSL actually behaves like linux and uses linux binaries, so you'll use the linux version of ddev.
The biggest problem is that the docker daemon is running under native Windows and WSL has a different filesystem layout, so you have to kind of trick everything on the WSL side to use paths that the Docker daemon will be able to find in native windows.
Start by setting up your WSL/Docker environment as described in this excellent article: https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly#ensure-volume-mounts-work - BUT use DOCKER_HOST=tcp://127.0.0.1:2375 instead of using "localhost" in there.
Install ddev using the Linux instructions.
Make sure all projects are already rm'd with ddev rm -a; projects already running or stopped in native Windows can't be accessed by ddev from WSL-land.
You're probably going to use the web browser on your windows side of the machine, so add the hostname of your project on the Windows side with ddev hostname <yourproject.ddev.local> 127.0.0.1
cd /c/Users//path/to/project (This is a path docker understands.)
ddev start
Visit the project with your browser.
Basically, with this technique you're using paths that the Docker daemon knows how to follow in native windows.
Anyway, it seems to work with a trivial example. Your comments are welcome and we may be able to improve support in the future if people like it.
I have it working (current 1.5.1) inside of WSL. I'm using Docker Toolbox so Docker4Windows may be different.
General setup inside of WSL (I'm using ubuntu)
install docker (apt-get install docker.io)
copy default docker machine certificates to WSL via
cp /mnt/c/Users/[YOUR WINDOWS USER]/.docker/machine/machines/default/*.pem ~/.docker
setup your environment variable inside of WSL (eg. in ~/.bashrc)
export DOCKER_HOST=tcp://192.168.99.100:2376
export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=~/.docker
The actual values to use can be determined via docker-machine.exe env from the docker toolbox!
At this point you should get a complete output from docker version (don't forget to restart your shell to actually load the modified environment)
Client:
Version: 18.06.1-ce
API version: 1.38
Go version: go1.10.4
Git commit: e68fc7a
Built: Fri Oct 19 19:43:14 2018
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 18.06.1-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.3
Git commit: e68fc7a
Built: Tue Aug 21 17:28:38 2018
OS/Arch: linux/amd64
Experimental: false
Containers can't be started yet as the mount of file systems will fail!
With Docker Toolbox the docker server has the host file system available under /c/. But running from WSL the expected path is /mnt/c/
Generating a symlink is sufficient to make it available docker-machine.exe ssh default 'sudo ln -s /c /mnt/c'
This command has to be rerun after reboot or you have to make the changes permanent via the bootlocal.sh mechanism.
Test your mapping with docker run --rm -i -t -v ${PWD}:/mnt ubuntu bash from WSL.
Install docker-compose, depending on your distribution it is outdated and needs to be replaced with a current version.
Enjoy ddev
I am using the default Apache installation that comes with Snow Leopard and I have some things installed like MySQL, Rudix (Unix ports and packages) and Xcode.
When I type:
$ sudo apachectl start
I receive this output:
dyld: Symbol not found: _apr_dir_open$INODE64
Referenced from: /usr/local/sbin/httpd
Expected in: /usr/local/lib/libapr-1.0.dylib
in /usr/local/sbin/httpd
/usr/local/sbin/apachectl: line 78: 2023 Trace/BPT trap $HTTPD -k $ARGV
I don't know if it's related but my .bash_profile has this line (I typed it because import MySQLdb was not working in Python):
export DYLD_LIBRARY_PATH="/usr/local/mysql/lib/:$DYLD_LIBRARY_PATH"
If I tick Web Sharing using System Preferences the Apache starts and work, but I wan't to start it using the terminal, maybe I am forgot to pass important arguments to the apachectl command.
The Web Sharing option of System Preferences enables the Apple-supplied Apache. Its apachectl is /usr/sbin/apachectl. You appear to have installed another version of Apache in /usr/local; note the /usr/local/sbin/apachectl path. So you are not using the Apple-supplied Apache installation when you are running from the terminal and the version you are using appears to not have been installed correctly. One way to ensure you are using the Apple-supplied Apache is to specify the full path:
$ sudo /usr/sbin/apachectl start