Open RoPP opened 6 years ago
It would be nice if socket path could be configurable as well.
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.
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
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.
@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.
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 ?
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