4

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Mudassir Razvi
  • 1,783
  • 12
  • 33
  • I would like to know that too, did you find where are the logs? – tonix Aug 17 '15 at 15:01
  • I moved ahead and did not use this atall. So didnt bother finding a solution later. I guess we have to manually redirect the log into a file, both input and error stream. I couldn't think of anything now. – Mudassir Razvi Aug 19 '15 at 03:49
  • All right, I understood. Thank you for answering! – tonix Aug 19 '15 at 10:30
  • More than 3 years later, there is a new option with Git 2.17: see [my answer below](https://stackoverflow.com/a/48977619/6309). – VonC Feb 25 '18 at 19:37

2 Answers2

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!

tonix
  • 6,671
  • 13
  • 75
  • 136
  • One question! If its for more than 3-4 people and will be your mode of sharing for a longer time, do consider sharing over ssh. I dont like daemon that much. – Mudassir Razvi Aug 19 '15 at 14:46
  • Yeah, you are right, this is just for read only repositories, you know maybe you have many teams where each team works on a project: each team uses SSH to access and push on its own project but each one can clone a project on which another team is working on using `git://`, in order to have just a bit of transparency in the company. But anyway, I agree with you, SSH is the right way to go if you need to grant write access to the repo too. :) – tonix Aug 19 '15 at 14:53
  • Even in my architecture everyone has visibility to others repositories. I manage write permission at folder level. A person is allowed to access the system over ssh but he cant write to a repository unless it is shared at file level. That way write access is restricted to people I want and everyone else has read only access. – Mudassir Razvi Aug 19 '15 at 14:55
  • I didn't understand you, `A person is allowed to access the system over ssh but he cant write to a repository unless it is shared at file level`, do you mean that you create a shared repo, as with `git init --bare --shared`, and then you add the users with push access to the group which has write access to the repo, or something like that? – tonix Aug 19 '15 at 15:03
  • Sorry for late response. Yes! I do exactly that! – Mudassir Razvi Nov 27 '15 at 04:12
1

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250