Thanks, I thought this is not mandatory. Can this be the same URL as my instance URL or would I have to setup an new subdomain incl. SSL for this?
please read the release post
I did just switch from /media to subdomain media. and also put it in prod.secret.exs Works fine, with significant performance improvement in * Akkoma 3.11.0.
However I still get the same error after upgrading. Also tried database config migration before, but without effect.
Apr 09 17:21:21 debian-4gb-fsn1-2 mix[9022]: 17:21:21.442 [notice] Application pleroma exited: exited in: Pleroma.Application.start(:no>
Apr 09 17:21:21 debian-4gb-fsn1-2 mix[9022]: ** (EXIT) an exception was raised:
Apr 09 17:21:21 debian-4gb-fsn1-2 mix[9022]: ** (ArgumentError) No base_url set for uploads - please set one in your config!
Apr 09 17:21:21 debian-4gb-fsn1-2 mix[9022]: (pleroma 3.12.2) lib/pleroma/config/deprecation_warnings.ex:360: Pleroma.Confi>
Apr 09 17:21:21 debian-4gb-fsn1-2 mix[9022]: (pleroma 3.12.2) lib/pleroma/config/deprecation_warnings.ex:186: Pleroma.Confi>
Apr 09 17:21:21 debian-4gb-fsn1-2 mix[9022]: (pleroma 3.12.2) lib/pleroma/application.ex:53: Pleroma.Application.start/2
Apr 09 17:21:21 debian-4gb-fsn1-2 mix[9022]: (kernel 8.5.3) application_master.erl:293: :application_master.start_it_old/4
Apr 09 17:21:21 debian-4gb-fsn1-2 mix[9086]: [os_mon] memory supervisor port (memsup): Erlang has closed
Apr 09 17:21:21 debian-4gb-fsn1-2 mix[9087]: [os_mon] cpu supervisor port (cpu_sup): Erlang has closed
Apr 09 17:21:23 debian-4gb-fsn1-2 mix[9022]: {"Kernel pid terminated",application_controller,"{application_start_failure,pleroma,{bad_r>
Apr 09 17:21:23 debian-4gb-fsn1-2 mix[9022]: Kernel pid terminated (application_controller) ({application_start_failure,pleroma,{bad_re>
Apr 09 17:21:23 debian-4gb-fsn1-2 mix[9022]:
Apr 09 17:21:23 debian-4gb-fsn1-2 mix[9022]: Crash dump is being written to: erl_crash.dump...done
Apr 09 17:21:23 debian-4gb-fsn1-2 systemd[1]: pleroma.service: Main process exited, code=exited, status=1/FAILURE
Apr 09 17:21:23 debian-4gb-fsn1-2 systemd[1]: pleroma.service: Failed with result 'exit-code'.
Apr 09 17:21:23 debian-4gb-fsn1-2 systemd[1]: pleroma.service: Consumed 3.700s CPU time.
Apr 09 17:21:23 debian-4gb-fsn1-2 systemd[1]: pleroma.service: Scheduled restart job, restart counter is at 7.
Apr 09 17:21:23 debian-4gb-fsn1-2 systemd[1]: Stopped pleroma.service - Pleroma social network.
Apr 09 17:21:23 debian-4gb-fsn1-2 systemd[1]: pleroma.service: Consumed 3.700s CPU time.
Apr 09 17:21:23 debian-4gb-fsn1-2 systemd[1]: Started pleroma.service - Pleroma social network.
lines 95120-95151/95151 (END)
it would not be throwing that error if a media base URL was set
are you sure you are using the prod env? and if so, can you provide the exact config line where you think you set it?
Thank, you. I will write a DM.
Just upgraded to 3.12.2, one thing I noticed is the new release will refuse to start if your media upload path is in the database and not the config file even though mix pleroma.config migrate_to_db will migrate it; either akkoma should check for that entry in the db or the migration script shouldn’t touch it and the config file requirement should be written down somewhere.
the thing is that once the database config sync comes online, the application has started up on the supervision tree and people will get confused when their uploads don’t work
to hard exit and not get overwhelmed by “why uploads no work” support messages they need to blow up the application early
also, the error message gives you the config file format, and does not tell you to put anything in the database, which I think is as clear as it could be
I know the error message/upgrade notes don’t say to put the config item in the db, but I don’t think I’m making too much of a leap when mix pleroma.config migrate_to_db says it moved the upload base url successfully leads me to think “this is a config entry that can be stored in the db and removed from my config file without causing some unforeseen issue”, the job doesn’t try to migrate other parts of my config file so I know they have to stay.
If it makes more sense to say “this config can’t be in the db to keep people from being confused” I’m cool with that, I just want the migration job to not migrate the config and some piece of documentation that says “this has to stay in the config file”, I’d even update the docs myself if I knew where to put the update.
1 Like