Where are logs of git-daemon saved? (Git on window

问题:

I am running git-daemon as a windows service. (using Create Process)
The command used in service is:

git daemon --reuseaddr --base-path=/data/test_work/ --export-all \
    --verbose --enable=receive-pack

Where do I see the logs of git daemon?

Note: there is no file at /var/logs.

回答1:

If you still need and want to do it, I have found a way to do that: just create a bash script with execution permissions and tell the daemon to log its stuff into one or two files (if you want to log stderr separately):

#!/bin/bash

# Git daemon launchd startup command.

GIT_RO_USER="git-ro" # The user which has read only access to the repositories.

GIT_REP_BASE_PATH="/path/to/GitRepositories" # The repositories base path.

GIT_LOG_FILE="/var/log/git.log" # The git daemon log file. The user which runs the script must have the right write permissions

/path/to/git daemon --reuseaddr --verbose --user=$GIT_RO_USER --base-path=$GIT_REP_BASE_PATH $GIT_REP_BASE_PATH >> $GIT_LOG_FILE 2>&1

# Or if you like to keep the error log separated, uncomment the following lines and comment the previous one:
#GIT_ERR_LOG_FILE="/var/log/git_err.log" # The error log file
#/path/to/git daemon --reuseaddr --verbose --user=$GIT_RO_USER --base-path=$GIT_REP_BASE_PATH $GIT_REP_BASE_PATH >> $GIT_LOG_FILE 2>> $GIT_ERR_LOG_FILE

Where /path/to/git is the path to the git command. I use it with launchd on my OS X machine cause I have noticed that you can't setup StandardOutPath and StandardErrorPath keys for the daemon using a .plist file.

Hope it helps you too!

回答2:

Where do I see the logs of git daemon?

Git 2.17 (Q1 2018) can help, since the log from "git daemon" can be redirected with a new option; one relevant use case is to send the log to standard error (instead of syslog) when running it from inetd.

See commit 0c591ca (04 Feb 2018) by Lucas Werkmeister (lucaswerkmeister).
Helped-by: Ævar Arnfjörð Bjarmason (avar), Junio C Hamano (gitster), and Eric Sunshine (sunshineco).
^{(Merged by Junio C Hamano -- gitster -- in commit c2bd43d, 21 Feb 2018)}

daemon: add --log-destination=(stderr|syslog|none)

This new option can be used to override the implicit --syslog of --inetd, or to disable all logging. (While --detach also implies --syslog, --log-destination=stderr with --detach is useless since --detach disassociates the process from the original stderr.) --syslog is retained as an alias for --log-destination=syslog.

--log-destination always overrides implicit --syslog regardless of option order.
This is different than the “last one wins” logic that applies to some implicit options elsewhere in Git, but should hopefully be less confusing.
(I also don’t know if all implicit options in Git follow “last one wins”.)

The combination of --inetd with --log-destination=stderr is useful, for instance, when running git daemon as an instanced systemd service (with associated socket unit).
In this case, log messages sent via syslog are received by the journal daemon, but run the risk of being processed at a time when the git daemon process has already exited (especially if the process was very short-lived, e.g. due to client error), so that the journal daemon can no longer read its cgroup and attach the message to the correct systemd unit (see systemd/systemd issue 2913). Logging to stderr instead can solve this problem, because systemd can connect stderr directly to the journal daemon, which then already knows which unit is associated with this stream.

---

Git 2.18 (Q2 2018) make things more robust, since the recent introduction of "--log-destination" option to "git daemon" did not work well when the daemon was run under "--inetd" mode.

daemon.c: fix condition for redirecting stderr

Since the --log-destination option was added in 0c591ca ("daemon: add --log-destination=(stderr|syslog|none)", 2018-02-04, Git 2.17) with the explicit goal of allowing logging to stderr when running in inetd mode, we should not always redirect stderr to /dev/null in inetd mode, but rather only when stderr is not being used for logging.