Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1135071 - git-daemon does not start under systemd because git.service needs to be a template unit
Summary: git-daemon does not start under systemd because git.service needs to be a tem...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: git
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Petr Stodulka
QA Contact: Lukáš Zachar
Miroslav Svoboda
URL:
Whiteboard:
: 1246735 (view as bug list)
Depends On: 980574 1246735
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-28 19:02 UTC by David Shea
Modified: 2019-08-15 03:57 UTC (History)
16 users (show)

Fixed In Version: git-1.8.3.1-5
Doc Type: Bug Fix
Doc Text:
Because the file git.service was not a template unit, it was not possible to start git-daemon in systemd. git.socket failed to queue the service startup job, and the "Invalid argument" error was displayed. With this update, the template unit has been created by renaming the file git.service to git@.service. Also, "-" has been added before the path in the ExecStart command to prevent hanging of instance units. As a result, git.socket now works as expected, and git-daemon can be started in this situation.
Clone Of: 980574
Environment:
Last Closed: 2015-08-06 10:28:16 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1573 0 normal SHIPPED_LIVE git bug fix update 2015-08-06 14:28:07 UTC

Description David Shea 2014-08-28 19:02:40 UTC 
This bug also affects RHEL-7. Any attempt to use git-daemon results in something like this:

Aug 28 14:57:51 banshee systemd: Starting Git Activation Socket.
Aug 28 14:57:51 banshee systemd: Listening on Git Activation Socket.
Aug 28 14:58:56 banshee systemd: git.socket failed to queue service startup job (Maybe the service file is missing or not a template unit?): Invalid argument
Aug 28 14:58:56 banshee systemd: Unit git.socket entered failed state.

The fix is to rename the service file git.service to git@.service. That's it.


+++ This bug was initially created as a clone of Bug #980574 +++

Description of problem:
Using the systemd unit files for git-daemon, the git service fails to start on connections to port 9418. This is because "Accept=true" in the .socket file expects a template unit for the service file, so this can be fixed by renaming git.service to git@.service.

Version-Release number of selected component (if applicable):
git-daemon-1.8.3.1-1.fc19.x86_64

How reproducible:
Always

Steps to Reproduce:
1. systemctl enable git.socket
2. Connect to 9418

Actual results:
git.socket failed to queue service startup job (Maybe the service file is missing or not a template unit?): Invalid argument

Additional info:
It would also be helpful to add a - to the ExecStart command in the .service to prevent non-zero exit statuses from tripping things up.

Attached a patch that renames git.service and adds a - to ExecStart.
Comment 2 Jan Kundrát 2014-11-26 16:52:50 UTC 
Is there a workaround? The bugreport mentions an attached patch, but I don's see anything in here.
Comment 3 Pierre-YvesChibon 2014-11-28 15:41:26 UTC 
Part of the work advised here has been done in http://pkgs.fedoraproject.org/cgit/git.git/commit/?id=906d8479f79ee89ec399fa5988b11fa037f18d38
Comment 4 Jan Kundrát 2014-11-28 15:57:43 UTC 
(In reply to Pierre-YvesChibon from comment #3)
> Part of the work advised here has been done in
> http://pkgs.fedoraproject.org/cgit/git.git/commit/
> ?id=906d8479f79ee89ec399fa5988b11fa037f18d38

That's a Fedora package, not an RHEL7 one.

I have no systemd knowledge, and therefore I don't know how much of a problem a mere existence of a git.system below /usr is, in addition to a properly renamed git@.service under /etc. I'm using Apache for now.
Comment 5 Pierre-YvesChibon 2014-11-28 16:13:01 UTC 
> That's a Fedora package, not an RHEL7 one.

Which as you have noticed this bug originates from.

> in addition to a properly renamed git@.service under /etc.

Why would you want to put a .service file in /etc ? That's not quite where they belong.
Comment 6 Jan Kundrát 2014-11-28 16:16:03 UTC 
> Which as you have noticed this bug originates from.

Yes, the bug's been indeed fixed in latest Fedora.

> Why would you want to put a .service file in /etc ? That's not quite where
> they belong.

Because the systemd documentation [1] tells me to do it:

Q: I want to change a service file, but rpm keeps overwriting it in /usr/lib/systemd/system all the time, how should I handle this?

A: The recommended way is to copy the service file from /usr/lib/systemd/system to /etc/systemd/system and edit it there. The latter directory takes precedence over the former, and rpm will never overwrite it. If you want to use the distributed service file again you can simply delete (or rename) the service file in /etc/systemd/system again.

[1] http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/

What I have no idea about is whether it's safe to have a "git@.service" under /etc and "git.service" under /usr. Not "directly" under /etc and /usr, sure, sorry for not being clear enough.
Comment 7 Pierre-YvesChibon 2014-11-28 16:21:44 UTC 
Thanks for the explanation, I see what you mean now.

I am not sure how systemd would handle such situation since you would not be overriding the file in /usr with the one in /etc as the two files have two different names.
So safe, I would it is, but I am not sure it would work.

/me will try to find someone more knowledgeable
Comment 8 Zbigniew Jędrzejewski-Szmek 2014-11-28 16:35:22 UTC 
git.service would not cause any problem, whether in /usr or in /etc, except that its presence might be misleading. OTOH, it is totally useless under this name. With current configuration of git.socket, systemd cares only about git@.service.

The fix is trivial: rename /usr/lib/systemd/system/git.service to /usr/lib/systemd/system/git@.service.

Please don't put any service files under /etc.
Comment 9 Petr Stodulka 2014-12-01 09:02:38 UTC 
Zbigniew: Hi, I suppose that you mean - do not put any service files under /etc/* in rpm package. IMHO user should add own service files to /etc because it's his own configuration of system. It's better than modify defult behaviour inside /lib/*. Right?
Comment 10 Zbigniew Jędrzejewski-Szmek 2014-12-01 12:51:43 UTC 
(In reply to pstodulk from comment #9)
> Zbigniew: Hi, I suppose that you mean - do not put any service files under
> /etc/* in rpm package. IMHO user should add own service files to /etc
> because it's his own configuration of system. It's better than modify defult
> behaviour inside /lib/*. Right?
Yes to all three.
Comment 13 Petr Stodulka 2015-06-19 18:50:03 UTC 
used solution from patch above
Comment 15 Jim Minter 2015-07-25 08:44:14 UTC 
*** Bug 1246735 has been marked as a duplicate of this bug. ***
Comment 18 errata-xmlrpc 2015-08-06 10:28:16 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1573.html
Note You need to log in before you can comment on or make changes to this bug.