LibrePhotos / librephotos

A self-hosted open source photo management service. This is the repository of the backend.
MIT License
7.01k stars 309 forks source link

Can't login #86

Closed Suleman-Elahi closed 3 years ago

Suleman-Elahi commented 3 years ago

image

Installed with default parameters on my PC.

OS: Artix Method: docker-compose Docker and docker-compose version: Latest

Can't log in. Nothing happens after pressing the login button. Doesn't seem to be doing anything even after entering wrong credentials.

SchoofsEbert commented 3 years ago

What do your docker-compose logs say?

You can ask them through: docker-compose logs backend and
docker-compose logs frontend

Suleman-Elahi commented 3 years ago

docker-compose logs backend: https://paste.ee/p/zCqjR docker-compose logs frontend: https://paste.ee/p/dUNl7 docker-compose.yml: https://paste.ee/p/pLDWh

derneuere commented 3 years ago

The backend crashes because it says it is a illegal instruction to create the admin user. That's a new one.

derneuere commented 3 years ago

I can't seem to reproduce the error. It works fine when I start with a fresh database. I am also kind of confused why the migration isn't shown in the backend. Does this error happen on every startup?

Suleman-Elahi commented 3 years ago

Yes it happens every time. I don't know if I am missing anything .... or hardware configuration is a problem... i have 4gb ram and intel dual core processor...its quite old PC though.

derneuere commented 3 years ago

Okay, could you maybe start librephotos just with sudo docker-compose up. Without the -d? Maybe then it logs more information. It should not be a resource issue yet.

Suleman-Elahi commented 3 years ago

Here: https://paste.ee/p/fOt6W

derneuere commented 3 years ago

It seems like the original docker container never got shut down. Could you run docker-compose down and then docker-compose up and then send me the log?

greenship24 commented 3 years ago

I had this issue as well. FF dev tools said /api/auth/token/obtain was not found (ns bad URI maybe? Should've saved that snippet). Didn't see much useful in the logs. Had brought the stack down, back up, blew it away a few times entirely, etc. Nothing seemed to help.

I went into the backend container, ran (from /code) /miniconda/bin/python manage.py migrate and received the following:

root@e7d0d435a2bf:/code# /miniconda/bin/python manage.py migrate
Operations to perform:                                           
  Apply all migrations: admin, api, auth, contenttypes, database, sessions
Running migrations:                                                            
  No migrations to apply. 

Brought the stack down and back up- working. If I have time I'll attempt the same fresh (this is just a demo install for me) and see if it is the same issue. Don't know why it wouldn't be correctly applying the db migrations though.

turnbeutelvergesser commented 3 years ago

I could reproduce this on a fresh install. Seems like the Python interpreter in the backend container uses SSE 4.1 instructions which fails on some older CPUs (like my good old Phenom 1090T). Thank you very much, throwaway876, with your comment I was able to dig down. I got the same illegal instruction, installed gdb inside the backend container and got:

(gdb) run manage.py migrate
Starting program: /miniconda/bin/python manage.py migrate
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 18153]
[New Thread 0x7f22f9577640 (LWP 18184)]
[New Thread 0x7f22f8d76640 (LWP 18185)]
[New Thread 0x7f22f0575640 (LWP 18186)]
[New Thread 0x7f22dfd74640 (LWP 18187)]
[New Thread 0x7f22df573640 (LWP 18188)]

Thread 1 "python" received signal SIGILL, Illegal instruction.
0x00007f22fc602cf7 in ?? ()
   from /miniconda/lib/python3.8/site-packages/dlib-19.21.99-py3.8-linux-x86_64.egg/_dlib_pybind11.cpython-38-x86_64-linux-gnu.so
(gdb) x/i 0x7f22fc602cf7
=> 0x7f22fc602cf7:  pinsrq $0x1,%rax,%xmm0

pinsrqis a SSE 4.1 instruction, cat /proc/cpuinfo only reports sse4a for my machine.

derneuere commented 3 years ago

@turnbeutelvergesser I have added a parameter to disable sse4 instructions. The build should be ready in a hour or so. Could you please do a docker-compose down, docker-compose pull and docker-compose up, to try if it works then?

turnbeutelvergesser commented 3 years ago

Now it works, I can see a fresh install. need to have a look around then.

I don't think you'd need to support old CPUs indefinitely, but maybe there could be a better error message. What I don't know is how much SSE4.1 will buy in Python in this case tough...

Thank you very much!

derneuere commented 3 years ago

@Suleman-Elahi We moved the admin creation to a django command. It should work now for you. Could you test it?

Suleman-Elahi commented 3 years ago

@derneuere I tried it today on a new PC. This is i5 and has 6 GB ram and it doesn't seem to be working here as well. Tried with default config and admin/admin as login credentials.

Terminal: https://paste.ee/p/NEEiA Fronted: https://paste.ee/p/g93uE Backend: https://paste.ee/p/Iqxlr

image

derneuere commented 3 years ago

What OS are you using? How does your docker-compose.yml file look like? How did you configure you .env file?

Suleman-Elahi commented 3 years ago

@derneuere I just started with the default parameters. Didn't change anything in docker-compose or env file. I am using Xubuntu 20.04 for now.