Gitea: bug: warn or info loggin does not show errors when start

[mckaygerhard]

• Gitea version (or commit ref): 1.1.4
• Git version:1.8.3
• Operating system: Linux
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [ ] MSSQL
  
  
  • [x] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [X] No
  
  
  • [ ] Not relevant
  
  
• Log gist:

2017/09/14 15:32:06 [I] Run Mode: Production
panic: fail to set message file(en-US): open conf/locale/locale_en-US.ini: no such file or directory

goroutine 1 [running]:
code.gitea.io/gitea/vendor/github.com/go-macaron/i18n.initLocales(0x19733595, 0x0, 0x8a8d65d, 0xb, 0x19a6c860, 0x8aacd41, 0x21, 0x19724370, 0x15, 0x15, ...)
    /home/systemas/Devel/golang/gitea/gitea-1.1.4/obj-i586-linux-gnu/src/code.gitea.io/gitea/vendor/github.com/go-macaro

Description

I try to install and some files get off due a mistake.. nobody care and noted due when the service start does not notify of that errors, only warms (due the level are in info or warm, but ignore errors???)

so the missing files are only showed when the log info are changed to "trace"! or error"

If the mail service (externally) temporally fail, the complete gitea service crash! When gogs, this not happened

So i try to temporally disable the mail service and more problems, due gitea "exigence me" to have a valid email if others settings require it!

The problem here it's that there is no tolerant respect the external faults

[lafriks]

Have you compiled binary yourself?

[mckaygerhard]

yeah! i compiled to get more system-wide to distribute, the upstream gitea binary act's like a guindows program .. but i can see that if the mail service are set to "true" and get temporally down gitea does not start again...

[mckaygerhard]

also the log level its the other problem, if set to Warn i cannot see that errors... by example if a directory was deleted that important problem does not show in log levels like Warn or Info

[mckaygerhard]

to the 1.3 milestrone ????? what about stable users !!!! what kind of support are this?

each minor brand are not so "minor", i spected a solution in a "patched" brand and nor in the nex mayor/minor release, that for sure will be incompatilbe and must need migration performance from 1.1.4

in that gogs seems are more better?

[lafriks]

When it is fixed it will be backported to 1.2.1

[mckaygerhard]

now super happy! i wainting for...

[mckaygerhard]

was 1.3 now 1.4 .. then 1.4 was raised and released and still this issue are not resolved!

seems related to #3713

[mckaygerhard]

so then 1.6 and now 1.7.0 :flushed: :flushed: :flushed: :flushed:

i hope some day will be fixed my issues !

[lafriks]

It is not so common to use gitea built without bindata so feel free to work submit PR to fix this

[mckaygerhard]

It is not so common to use gitea built without bindata so feel free to work submit PR to fix this

ummm why this option of compilation are ofered so?

[lafriks]

Mostly for development purposes not to have recompile every time when changing template/javascript files

[mckaygerhard]

that also works for distributions, bindata not will be the best forever, size of the file now are 50MB aprox! so for distributions and packagers.. that are not so good and not so great!

[techknowlogick]

That’s right, bindata wont work forever, especially since  it is no
longer being developed. There has been discussions of switching to packr
(or a similar tool). There are no timelines planned. And as @lafriks
mentioned no one is paid for their work. Well that’s sorta true,
sometimes people get paid directly to implement specific features. If
you want to pay me I can focus time on this to implement packr before
end of year.

[mckaygerhard]

umm @techknowlogick seems youre i a confuse: pacakgin are not a way .. i'm taking about let normal unix way as gogs, in any case, so then why those very complicated formats of compresed "all in one", its obviously the only OS that need a "easy to deploy" due users are guindows.. in the rest great admins need a very granulated package.. and its better collaborate in this way with packageers.. so if are not developed so provide a better support for a normal distributed install way..

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[zeripath]

I think this is fixed. I suspect there was a log.Fatal that wasn't being logged - but this should be fixed in 1.9 by #6095. I appreciate this issue might surface in 1.8 but the pr fixing this is big and can't be backported.