Seafile CE 11.0.13 to 12.0.11 Upgrade "Cannot find JWT_PRIVATE_KEY value from environment"

Seafile Server
1

I am trying to upgrade a Seafile CE server v.11.0.13 to v.12.0.11 running on Ubuntu 24.04 using the standard binaries. Following instructions in the Manual, including the Clean Database notes, the upgrade completes without an error.

When Seafile is started, however, the following error is reported on screen:

Cannot find JWT_PRIVATE_KEY value from environment, try to read .env file.
[seaf-server] is running, pid 1136. You can stop it by: 

        kill 1136

Stop it and try again.

Killing the pid and retrying results in the same error message. Rebooting does not help.

The .env file is prepared and saved to /config/.env as described in the Manual for binary installations. It includes a JWT_PRIVATE_KEY generated by pwgen as described in the same section of the Manual.

SDOC is not running and Notification server has not been upgraded. OnlyOffice is running (Docker) from the previous installation. Nginx is also running from the previous version of Seafile.

Does anyone have any suggestions on how to fix this?

-Thank you

2

This is not an error but an information.

Here is the messages on a working Seafile instance:

企äøšå¾®äæ”ęˆŖ图_17435628542797
企äøšå¾®äæ”ęˆŖ图_17435628542797925Ɨ157 5.38 KB

What make you think your Seafile instance does not work?

3

I get the same error after doing the same upgrade. Except my seafile wonā€™t start now.

Cannot find JWT_PRIVATE_KEY value from environment, try to read .env file.
Starting seafile server, please wait ā€¦
Failed to start seafile server
seafile@seafile:~/seafile-server-latest$ ./seafile.sh start

4

I managed to get the services started. Have a new issue. will start a new thread.

5

Can you explain more? -Thank you

6

Seafile Status: active
Seahub Status: failed

For Seafile:

seafile.service - Seafile
     Loaded: loaded (/etc/systemd/system/seafile.service; enabled; vendor preset: enabled)
     Active: active (exited) since Mon 2025-06-30 17:45:28 MDT; 8min ago
   Main PID: 1553 (code=exited, status=0/SUCCESS)
        CPU: 36ms

Jun 30 17:45:28 seaf-server systemd[1]: Starting Seafile...
Jun 30 17:45:28 seaf-server seafile.sh[1553]: Cannot find JWT_PRIVATE_KEY value from environment, try to read .env file.
Jun 30 17:45:28 seaf-server seafile.sh[1553]: [seaf-server] is running, pid 1055. You can stop it by:
Jun 30 17:45:28 seaf-server seafile.sh[1553]:         kill 1055
Jun 30 17:45:28 seaf-server seafile.sh[1553]: Stop it and try again.
Jun 30 17:45:28 seaf-server systemd[1]: Finished Seafile.

For Seahub:

seahub.service - Seafile Hub
     Loaded: loaded (/etc/systemd/system/seahub.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2025-06-30 17:45:28 MDT; 9min ago
   Main PID: 1563 (code=exited, status=1/FAILURE)
        CPU: 23ms

Jun 30 17:45:28 seaf-server systemd[1]: Starting Seafile Hub...
Jun 30 17:45:28 seaf-server seahub.sh[1563]: Cannot find JWT_PRIVATE_KEY value from environment, try to read .env file.
Jun 30 17:45:28 seaf-server seahub.sh[1563]: Warning: seafile server not running. Have you run "./seafile.sh start" ?
Jun 30 17:45:28 seaf-server systemd[1]: seahub.service: Main process exited, code=exited, status=1/FAILURE
Jun 30 17:45:28 seaf-server systemd[1]: seahub.service: Failed with result 'exit-code'.
Jun 30 17:45:28 seaf-server systemd[1]: Failed to start Seafile Hub.

Not seeing anything in the logs. The only apparent error message is related to

Cannot find JWT_PRIVATE_KEY value from environment, try to read .env file.

7

I think you are misunderstanding what those messages are trying to say. First it is saying that it didnā€™t find the JWT_PRIVATE_KEY in the environment variables (as would be expected when running in docker), so it is going to look for it in the .env file. Not a problem, just information about whatā€™s going on.

The next line is the problem. The startup script is setup to not allow you to run more that one copy of seafile at a time. While checking for that, it found that there is already a program called ā€œseaf-serverā€ running. The rest of the message is just trying to helpfully tell you that the already running seaf-server has process id 1055, and that normally you should be able to stop that already running one with the command ā€œkill 1055ā€.

Programs that arenā€™t working properly donā€™t always end when killed this way, so it would be a good idea to check the status of that program after killing it. So try starting seafile to get the current number (it wonā€™t always be the same, especially if you rebooted or something), then kill it ā€œkill 1055ā€, then check the programā€™s status with ā€œps u -p 1055ā€.

What I think is happening is that when you kill 1055 it does die (which will be confirmed by getting an empty list of info from that ps command). But then when you try to start seafile you get the same message (with a new pid number) because something else already restarted it. Normally if you have configured an init system to start seafile on boot, it will be configured to restart it if it dies. So if this is happening for you, you will need to stop the service, something like ā€œsudo systemctl stop seafileā€ and then ā€œsudo systemctl stop seahubā€. Then you should be able to manually start it like you are trying to do.

8

Hello @tomservo and thank you for getting back so quickly.

I think you hit the nail on the head! The server (which is quite old) is apparently installed/upgraded correctly. I say that because I got it to work exactly once but since then, no luck.

I found that the server was running systemd services for both seafile and seahub, as described in the Admin Manual, which I have now disabled for the time being.

This is whatā€™s happening: Upon reboot, web browser displays 502 Bad Gateway, pretty much as expected.

When I try to start the seafile server manually:

$ ./seafile.sh start

Cannot find JWT_PRIVATE_KEY value from environment, try to read .env file.
[seaf-server] is running, pid 1045. You can stop it by: 

        kill 1045

Stop it and try again.

If I go ahead and try to run Seahub manually I get:

$ ./seahub.sh start

Cannot find JWT_PRIVATE_KEY value from environment, try to read .env file.

Warning: seafile server not running. Have you run "./seafile.sh start" ?

When I issue:

sudo ps u -p 1045

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
avahi       1045  0.0  0.0   9708  4748 ?        Ss   17:50   0:00 avahi-daemon: running [seaf-server.local]

When I kill the process 1045 it does indeed die but another appears in its place:


[seaf-server] is running, pid 16939. You can stop it by: 

        kill 16939

Stop it and try again.

$ sudo ps u -p 16939
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
avahi      16939  0.0  0.0   9692  5124 ?        Ss   17:58   0:00 avahi-daemon: running [seaf-server.local]

And itā€™s always avahi, no matter how many times I kill and try to start Seafile.

As I said above, I did mange to start the server once, and logged-in to check files and folders, but since then I have not been successful in doing so.

Art this point Iā€™m a little lost and would greatly appreciate any ideas you can pass my way.

-Thank you again

9

Oh, there we go! I see whatā€™s happening. It looks like you accidentally found a bit of a bug in that startup script. Iā€™m going to explain here how itā€™s getting confused, but if you arenā€™t interested in that, you can skip down to the bottom to find my suggested work arounds.

Whatā€™s happening?

To make sure you arenā€™t accidentally starting 2 copies of any seafile component as the same time, this script runs the function check_component_running before starting a component. That look like this:

check_component_running "seaf-server" "seaf-server"

That sets name and cmd variables to seaf-server, and then runs:

if pid=$(pgrep -f "$cmd" 2>/dev/null); then
      echo "[$name] is running, pid $pid. You can stop it by: "
        echo
        echo "        kill $pid"
        echo
        echo "Stop it and try again."
        echo
        exit
    fi
}

So it is using the pgrep command to search all running programs for one with a command containing the string ā€œseaf-serverā€, and when it finds one it tells you how to kill it. But in your case, it is finding one that isnā€™t seafile, itā€™s another program that happens to match.

In this case, it is matching that avahi program instead of a real seaf-server process. What is avahi? Well avahi provides mDNS, which is a protocol that announces services to the network so other computers can automatically configure themselves to use it without the user needing to know what IP to find it on. Have you ever told a chromecast what to do without needing to type its IP into your phone? Or had your new printer just show up in the list of printers without needing to type in the IP on your computer? Thatā€™s the magic of mDNS.

For some reason avahi puts the computer hostname in its process name like ā€œavahi-daemon: running [seaf-server.local]ā€, and your hostname happens to match the string that the seafile script is looking for!

Suggested work-around 1

Thereā€™s 2 things you can do to pretty easily work around this bug. Option 1, stop running avahi. I donā€™t know if you have this server doing anything that needs avahi, but probably not. So you can stop avahi with ā€œsudo systemctl stop avahi-daemon.serviceā€ and then keep it from starting again with ā€œsudo systemctl disable avahi-daemon.serviceā€. If you find that broke something and want to undo, just ā€œsudo systemctl enable avahi-daemon.serviceā€ and then ā€œsudo systemctl start avahi-daemon.serviceā€

Suggested work-around 2

Change the name of you seafile server from seaf-server.local to something else, like seafile.local. Different linux distributions have different ways of doing this. On most debian-based systems you can just edit /etc/hostname to have the new name and reboot. For most redhat-based systems itā€™s something a bit more complicated that I canā€™t remember anymore.

10

Thank you again @tomservo for your timely and thoughtful analysis. After futzing with it again today for several hours I opted for Work-around 2 and changed the host name (in /etc/hosts and /etc/hostname; see here for reference) and the server started again (manually) without a problem.

Next Iā€™ll restore the systemd services for seafile and seahub and continue checking v.12.

Thank you again for your very helpful assistance with this. It made all the difference in the world.

1 Like