Arch Linux User Repository

@almanac, Because of how open-webui is structured, and the docker-first approach upstream, it requires a fair bit of manual setup when starting the application, what with the environment variables and everything.

So basically, in order to un-dockerise and make it so that open-webui runs as applications are supposed to on Arch, and so that everyone doesn't need to fiddle with environment variables and such, we use a systemd service, so to start open-webui, you should run: sudo systemctl start open-webui.service

Starting the service above replaces the command "open-webui serve" to "start the Open WebUI server, which you can access at http://localhost:8080". Restart the service by using sudo systemctl restart open-webui.service or by stopping and starting the service, if the aforementioned URL shows "Unable to connect" while systemctl status open-webui.service shows the service as active. If neither of those resolve the "Unable to connect" issue, rebooting your system might help. (thanks to arsCynic for bringing up how people might be confused by the unclear instructions, so making them more clear.)

Secondly, the reason why you can't do a simple open-webui serve, and can't find open-webui in the PATH anywhere is due to the way this package is currently structured.

We're using a virtual environment to manage the Python dependencies required to run the application, because that was the way this was set up since before I was maintaining this PKGBUILD (open-webui-git is the original PKGBUILD, I just yoinked and un-git-ified it).

In my personal opinion, this is an ugly way, hence I tried to un-virtualenv it, but a few dependencies fail in the check() portion, so it was decided to keep the current approach to reduce user friction.

You can find the non-virtualenv package at open-webui-no-venv, which does work, apart from needing to comment out the check() portions of the PKGBUILD of the dependencies that are failing.

You can do a open-webui serve when using open-webui-no-venv, but the aforementioned environment variables still need to be set, so even then it's still recommended to use the systemd service, but it is technically possible to do it.

Hope this lengthy explanation helps.

Edit: I should probably pin this, so I'll do that.

Due to failing build dependencies, the rework has been reverted, as of 0.5.3-3. As suggested by @Davidyz, I've created a separate package, open-webui-no-venv, that uses the reworked PKGBUILD.

PSA everyone, I intend to rework major parts of the PKGBUILD and the way open-webui is installed on the system so that we can get rid of the virtualenv and the long time it takes to build on every install. Also, it should make it so that you don't need to do the things that I mentioned in the first pinned note.

I've tested the changes on my end, and you don't need to do anything when updating from the old way to the new way, it should work just fine as it is, but still, this is a major change. I'll be moving installing the python dependencies from inside a virtualenv to installing the python dependencies system-wide.

If there are any bugs after the rework, which will be updated as 0.5.3-2 pkgrel bump, which are related to open-webui itself, rather than it's dependencies, please add a comment, and I'll fix them, and if there are too many, or some are unfixable, I'll revert the rework.

Note to all existing users (those who will be upgrading the package, not installing it anew, people installing anew should be fine):

When major Python versions switch (as just happened with Python 3.12 -> 3.13), I believe it would be prudent to delete the virtual environment created by the backend, done so manually by doing a sudo rm -r /opt/open-webui/backend/venv, and then reinstalling the open-webui package, thus rebuilding the virtual environment with the new Python major version.

Just reinstalling the open-webui package without removing or uninstalling makes sure that your user data, that is used in openwebui, for e.g., your admin password, remains as it is.

As an addendum, this might be applicable when the python package itself is changed due to dependency mismatches (again, as just happened when I changed the dependency from python to python312, and would happen again once python 3.13 is supported upstream back to python from python312), I'm not so sure about this, so testing might be needed, but just to be safe, please do so as well.

This is so that any mismatches between the Python version that created the virtualenv and the Python version in use, and any problems that might arise from that, can be avoided.

@Sproid, you can change the port in the config file, /etc/open-webui.conf. If that doesn't work, then changing the port in /opt/open-webui/backend/start.sh should work.

As for open-webui serve not working, check out the pinned comments above as to why.

@mistersmee If you could help me, How can I change the environment variables to change the default port 8080 to something like 9999? I ask because open-webui serve --port 9999 didn't worked nor do I find the WEBUI_URL Persistence environment variable on the /opt/open-webui/env.py file.

@arsCynic, while I get your point, I don't think that what I wrote makes it look like one should do open-webui serve to start the application. The very next line after the one you quoted, I mention that you can't do an open-webui serve. But, I'll add the bits you mentioned about it replacing `open-webui serve in the pinned post itself, thanks for that.

FYI to avoid confusion, because the following makes it look like one should be able to launch "open-webui" in the terminal, it doesn't.

"…so that open-webui runs as applications are supposed to on Arch…we use a systemd service, so to start open-webui, you should run: sudo systemctl start open-webui.service" —mistersmee

Starting the service above replaces the command "open-webui serve" to "start the Open WebUI server, which you can access at http://localhost:8080". Reboot if the aforementioned URL shows "Unable to connect" while systemctl status open-webui.service shows the service as active.

@Bureaucrat, can you post the output of journalctl -xeu open-webui.service? Also, fair warning, I can see that you're using Manjaro, and there is a possibility that this is Manjaro doing Manjaro things.

Kinda limpers out immediately:

sudo systemctl start open-webui.service
[sudo] password for [user]:
sudo systemctl status open-webui.service
○ open-webui.service - Open Web UI for LLMs
    Loaded: loaded (/usr/lib/systemd/system/open-webui.service; disabled; preset: disabled)
    Active: inactive (dead)

Mar 17 14:17:18 [hostname] systemd[1]: Started Open Web UI for LLMs.
Mar 17 14:17:18 [hostname] bash[8394]: start.sh: line 68: /opt/open-webui/backend/venv/bin/uvicorn: Success
Mar 17 14:17:18 [hostname] systemd[1]: open-webui.service: Deactivated successfully.
journalctl -xeu open-webui.service
Mar 17 14:17:18 [hostname] systemd[1]: Started Open Web UI for LLMs.
Subject: A start job for unit open-webui.service has finished successfully
Defined-By: systemd
Support: https://forum.manjaro.org/c/support
A start job for unit open-webui.service has finished successfully.
The job identifier is 3378.
Mar 17 14:17:18 [hostname] bash[8394]: start.sh: line 68: /opt/open-webui/backend/venv/bin/uvicorn: Success
Mar 17 14:17:18 [hostname] systemd[1]: open-webui.service: Deactivated successfully.
Subject: Unit succeeded
Defined-By: systemd
Support: https://forum.manjaro.org/c/support
The unit open-webui.service has successfully entered the 'dead' state.

http://localhost:8080/ is empty the same.

@mistersmee: i overcame from the issue just by increased the size of my disk /opt ;[

thanks

@cherkaba, can you post the output of journalctl -xeu open-webui.service?

@mistersmee that is what i get with the systemctl .service:

open-webui.service: Scheduled restart job, restart counter is at 5.
 systemd[1]: open-webui.service: Start request repeated too quickly.
 systemd[1]: open-webui.service: Failed with result 'resources'.
 systemd[1]: Failed to start Open Web UI for LLMs.

open-webui ollama 0.5.7-1