drolbr / Overpass-API

A database engine to query the OpenStreetMap data.
http://overpass-api.de
GNU Affero General Public License v3.0
709 stars 90 forks source link

Make logfile dest configurable #432

Open RoPP opened 6 years ago

RoPP commented 6 years ago

All logfile paths seems to be hardcoded, unfortunately theses paths don't match our needs.

An option or an environment variable for all scripts and binaries would help to improve integration of overpass-api in different infras.

/dev/stdout have to be a valid option

RoPP commented 6 years ago

It would be nice if socket path could be configurable as well.

mmd-osm commented 6 years ago

Can you elaborate a bit more on this requirement, e.g. mention the binaries and scripts where you encounter an issue, and what exactly the issue is with the current way?

I don't quite get the requirement to use /dev/stdout: in the context of interpreter binary, this would interfere with providing the response to the user.

RoPP commented 6 years ago

Our main need is to centralized log files (usually /var/log or journald) instead of keeping them in the database directory. It is more convenient (no need to look for them) and probably better for our ssd as well :)

On our installation, we launch 4 daemons : dispatcher --osm-base, dispatcher --areas, fetch_osc_and_apply.sh and rules_loop.sh, so I expect to have 4 differents logs.

/dev/stdout is usefull when daemon are managed by systemd. In this case, systemd pushes messages received on stdout (and stderr) to journald.

Sep 15 18:57:55 osm147 fetch_osc_and_apply.sh[20426]: 2017-09-15 18:57:55 URL:https://planet.osm.org/replication/minute/002/623/710.osc.gz [33975/33975] -> "/tmp/osm-3s_update_PTYsKB/002623710.osc.gz" [1]
Sep 15 18:57:55 osm147 fetch_osc_and_apply.sh[20426]: 2017-09-15 18:57:55 URL:https://planet.osm.org/replication/minute/002/623/711.state.txt [168/168] -> "/tmp/osm-3s_update_PTYsKB/002623711.state.txt" [1]
Sep 15 18:57:55 osm147 fetch_osc_and_apply.sh[20426]: 2017-09-15 18:57:55 URL:https://planet.osm.org/replication/minute/002/623/711.osc.gz [52503/52503] -> "/tmp/osm-3s_update_PTYsKB/002623711.osc.gz" [1]
Sep 15 19:11:23 osm147 fetch_osc_and_apply.sh[20426]: Reading XML file ... finished reading nodes. Flushing to database ...... done.

It's a simple and convenient way to log basic script or prog.

Systemd can manage messages sent to syslog as well. And logger can be used in shell scripts to submit msg to syslog.

More info on journal and systemd for app developpers: http://0pointer.de/blog/projects/journal-submit.html

AstroTom commented 6 years ago

I also like this request. In my case I am trying to run a fleet of overpass servers to balance the load. I would like to set up NFS for the DB directory. But, since all servers write the log to the same directory this is a problem. Even worse, since the socket files are also hard coded to the same dir the service will refuse to start on a 2nd machine.

mmd-osm commented 6 years ago

@AstroTom : what you're describing doesn't work anyway today, especially if you plan to run (minutely) updates on your db. You can't share the same db directory across multiple servers, even if the socket files were different. That would only be possible with one central dispatcher and one single update process across all servers, and every process talking to the central dispatcher via TCP rather than locally via unix domain socket. All of which is currently not implemented.

Marc-marc-marc commented 6 years ago

I have a commit available to fix this issue. to witch branch may I submit it ? minor_issue to fix the last uptodate branch ? or new_features but some script aren't uptodate ? or both ?