After upgrade from version 1.1.4 to 1.2.1 gitea doesnt starts via 'service gitea start'. Nothing written to log files. After downgrade to 1.1.4 with pkg everything works fine.
Please check your configuration and compare with app.ini.sample. Gitea 1.2.0 introduced a new required config parameter. Instructions are in app.ini.sample. Gitea doesn't seem to have a "config check" command; I'll open an issue at github and will include it in the start script as soon as possible. I've disabled logging in the start script since Gitea is quite verbose on it's stdout, including logging every HTTP access. Unfortunately, this also suppressed the log message about the missing config option.
Thanks for a fast answer! After some search about new config parameter I found https://www.mail-archive.com/freebsd-ports@freebsd.org/msg76210.html in mailing list and it works for me(I gave write permission to gitea user).
I think this issue can be closed; I don't think I have sufficient BugZilla access to do that myself.
I have the same issue I added the new parameter INTERNL_TOKEN and generated the 64 byte number and still not starting. Is there anything else I should check or enable? Thanks
(In reply to Rami from comment #4) Try running gitea in the foreground: # /usr/bin/env -i 'GITEA_WORK_DIR=/usr/local/share/gitea' 'GITEA_CUSTOM=/usr/local/etc/gitea' 'HOME=/usr/local/git' 'PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin' 'USER=git' /usr/local/sbin/gitea web This should give you a better idea of why the startup is failing. The next version of the port will log gitea console output to syslog (through daemon).
(In reply to stb from comment #5) Thanks a lot for this.... funnily the command you gave me worked, while service gitea start did not. Having your command working, means there is no issues in the update handling the data in the db from previous version and the new updated configuration file is Okay. But I would like to have it working as a service as before.... is there anything else you can think of that might help?
Well I figured out what was happening... well the port has been updated to 1.2.2 and once you fix the configuration file and you start it as service it complains about parameter -l for the daemon. I changed the /usr/local/etc/rc.d/gitea section below gitea_start() { /usr/sbin/daemon -l ${gitea_facility} -s ${gitea_priority} \ -u ${gitea_user} -p ${pidfile} -t "${command}" \ /usr/bin/env -i \ "GITEA_WORK_DIR=${gitea_shared}" \ "GITEA_CUSTOM=/usr/local/etc/${name}" \ "HOME=${githome}" \ "PATH=/usr/local/bin:${PATH}" \ "USER=git" \ $command } with the section from the old versions and it worked .... gitea_start() { /usr/sbin/daemon -f -u ${gitea_user} -p ${pidfile} /usr/bin/env -i \ "GITEA_WORK_DIR=${gitea_shared}" \ "GITEA_CUSTOM=/usr/local/etc/${name}" \ "HOME=${githome}" \ "PATH=/usr/local/bin:${PATH}" \ "USER=git" \ $command } I guess this might be a bug
(In reply to Rami from comment #7) what version of FreeBSD are you using?
(In reply to stb from comment #8) # uname -a FreeBSD git.jail 11.1-RELEASE-p1 FreeBSD 11.1-RELEASE-p1 #0: Wed Aug 9 11:55:48 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
Created attachment 187534 [details] /usr/local/etc/rc.d/gitea proposed version for 1.2.2_1
(In reply to Rami from comment #9) That's surprising. daemon(8) should have the syslog options from FreeBSD 11.1 onwards. I'm currently updating the port to only use the syslog options on FreeBSD 11.1-RELEASE and later. Can you try the attached start script?
(In reply to stb from comment #11) It is now complaining about the --S as below root@git:~ # service gitea start daemon: illegal option -- S usage: daemon [-cfr] [-p child_pidfile] [-P supervisor_pidfile] [-t title] [-u user] command arguments ... root@git:~ #
(In reply to Rami from comment #12) What version is freebsd-version reporting? From your hostname, I'm guessing that you're inside a jail; where did you take the userland from?
(In reply to stb from comment #13) not sure I understood your question, but yes I am in jail and I am using ezjail. my host machine also running freebsd 11.1 FreeBSD server-linode-1-git 11.1-RELEASE-p1 FreeBSD 11.1-RELEASE-p1 #0: Wed Aug 9 11:55:48 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 it is a VM on linode
Can you post the output from $ freebsd-version That should give the version of the userland (instead of the kernel version). From inside the jail (or wherever you're trying to run gitea).
(In reply to stb from comment #15) The jail where the gitea is running # freebsd-version 11.1-RELEASE-p2 The host ~ % freebsd-version 11.1-RELEASE-p2
(In reply to Rami from comment #16) Then /usr/sbin/daemon should understand -S, -s, and -l. Here's what I got on a fresh install: [vagrant@default-freebsd11 ~/gitea]$ freebsd-version 11.1-RELEASE-p1 [vagrant@default-freebsd11 ~/gitea]$ sha256 /usr/sbin/daemon SHA256 (/usr/sbin/daemon) = 2b029a5c274c6292870caf35470041c2553b768346bb001c97d447877bc9caf5
(In reply to stb from comment #17) well the server has same value as users % sha256 /usr/sbin/daemon SHA256 (/usr/sbin/daemon) = 2b029a5c274c6292870caf35470041c2553b768346bb001c97d447877bc9caf5 yet the jail seems to have different one... (gitea lives in the jail) # sha256 /usr/sbin/daemon SHA256 (/usr/sbin/daemon) = 2f1d9b434cae89c67aefa9798b87fd97bcde2f70b2ba0140b7052ae6536aaf8a
(In reply to Rami from comment #18) While it's not a problem to run older binaries on newer kernels (mostly), you should make sure that the binaries are all from the same release. There are a number of ports and packages that do rely on detecting the OS release to decide which features to use. If one part says 11.1, but other binaries are in fact older, you will run into hard to debug issues.
Well the jail was created from a newly install 11.1 p0 release. Then when I updated the host and I did update the jail # ezjail-admin update -u, which I do all the time. So I am under the impression that both should be sharing the same binaries
(In reply to stb from comment #5) Also valid when upgrading to gitea 1.3.1. (side note: indexer folder needs to be deleted, if the indexer is also upgraded)