Re: git-daemon: needs /root/.config/git/config?
On Sun, Jun 09, 2013 at 02:47:57PM +0200, Bernhard R. Link wrote: > * Ian Kumlien [130605 13:31]: > > Yes, i agree, it's suboptimal but I for one would use getpwuid to get > > the home directory of the executing user to avoid this - though i don't > > know how portable it is (or if there is any other issues) > > It's not only suboptimal but simply wrong. getpwuid gives at best the > initial home directory, and even there it is only a guess. (If you are > looking for some home directory of a different user it might be a good > guess). But using getpwuid(getuid())->pw_dir if HOME is set is a serious > mistake, as you throw out the good value for some almost but not quite > totally unrelated value. Well i never intended for it to replace the environment variable, it was more intended as a fallback - if there will be a "less strict" mode then perhaps a fallback would be a more controled way of doing it. > Bernhard R. Link -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-daemon: needs /root/.config/git/config?
On Tue, Jun 04, 2013 at 12:08:15PM -0400, Jeff King wrote: > On Tue, Jun 04, 2013 at 04:13:14PM +0200, Ian Kumlien wrote: > > > Due to the earlier problem I upgraded git on all machines > > and eneded up with a ubunut machine running in to problems. > > > > I started getting errors like: > > "fatal: protocol error: bad line length character: fata" > > > > Which after some head scratching caused me to tell xinetd to directly > > launch git-daemon, eventually it worked fine, but i did get this error > > message: > > Looks like your stderr was being redirected to your stdout; this > particular error aside, that is likely to cause weird protocol problems > for any error that git outputs. Yeah =) > > Jun 4 16:12:05 xyz git-daemon[10246]: unable to access > > '/root/.config/git/config': Permission denied > > > > It's not the first time i've seen it but i've been able to ignore it > > before. This is running as a local user (as in not root) and this user > > shouldn't have access to /root. But i eventually had to do chown o+x > > /root to workaround this error. > > The problem is that you have presumably dropped privileges in the daemon > instance, but your $HOME environment variable still points to /root. Git > cannot read all of its config files (nor even find out if they exist), > so it bails rather than continue. Yeah, assumed =P > Older versions of git silently ignored errors reading config files, but > it was tightened in v1.8.1.1, as there can be quite serious implications > to failing to read expected config (e.g., imagine transfer.fsckobjects, > or receive.deny* is ignored). Yes, i agree, it's suboptimal but I for one would use getpwuid to get the home directory of the executing user to avoid this - though i don't know how portable it is (or if there is any other issues) It's a bit hard to control this with xinetd doing it behind the scenes... > However, since changing user id and leaving $HOME is so common, there is > a patch under consideration to loosen the check only for the case of > EACCES on files in $HOME. That commit is 4698c8f (config: allow > inaccessible configuration under $HOME, 2013-04-12); it's not yet in any > released version of git, though. Ah, ok, thanks, I'll have a look - maybe i can actually contribute something for once =) > In the meantime, the suggested workaround is to set $HOME for the > git-daemon user, rather than loosening /root. Well, I have no idea of how to control HOME in xinetd - access to the machine is limited and x doesn't give that much access (nothing really important is actually stored in /root) For now, this is the workaround we have =P > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-daemon: needs /root/.config/git/config?
Hi again, Due to the earlier problem I upgraded git on all machines and eneded up with a ubunut machine running in to problems. I started getting errors like: "fatal: protocol error: bad line length character: fata" Which after some head scratching caused me to tell xinetd to directly launch git-daemon, eventually it worked fine, but i did get this error message: Jun 4 16:12:05 xyz git-daemon[10246]: unable to access '/root/.config/git/config': Permission denied It's not the first time i've seen it but i've been able to ignore it before. This is running as a local user (as in not root) and this user shouldn't have access to /root. But i eventually had to do chown o+x /root to workaround this error. Now, this must be wrong somehow? Or does --user work in inetd mode now? So... comments, ideas? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git hangs on pthread_join
On Tue, May 28, 2013 at 01:51:09PM -0400, Jeff King wrote: > On Thu, May 23, 2013 at 03:01:43PM +0200, Ian Kumlien wrote: > > > git 1.8.2.1 is started by xinetd > > [...] > > I have found "git receive-pack"s that has been running for days/weeks > > without terminating > > > > Attaching gdb and doing a trace results in: > > #0 0x003261207b35 in pthread_join () from /lib64/libpthread.so.0 > > #1 0x004ce58b in finish_async () > > #2 0x0045744b in cmd_receive_pack () > > #3 0x00404851 in handle_internal_command () > > #4 0x00404c9d in main () > > I recently fixed a deadlock that could happen in receive-pack when > clients hung up before sending a valid pack header. The fix is commit > 49ecfa1, and it's in git v1.8.2.2. With dodgy connections this could easily happen =) Really nice catch! > The stack trace for the deadlock fixed by 49ecfa1 would have > unpack_with_sideband between #1 and #2 above, but it is entirely > possible that it is simply inlined in your build of git, depending on > the -O level of your build (it is a static function that is only called > from one place). So it seems likely that it is the culprit. Yeah, since it's a RHEL 5 machine i don't even get a debug rpm package =P I will upgrade all machines and keep monitoring, thanks! > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git hangs on pthread_join
I forgot to reply to the mailing list and now something went wrong with the messages in mutt =P Recap:ing: On Thursday, May 23, 2013 07:01:43 am you wrote: > I'm running a rather special configuration, basically i > > > have a gerrit server pushing > > ... > I have found "git receive-pack"s that has been running > > > for days/weeks without terminating > > > > > ... > Anyone that has any clues about what could be going > > > wrong? -- > > Have you narrowed down whether this is a git client problem, or a server problem (gerrit in your case). Is this a repeatable issue. Try the same operation against a clone of the repo using just git. Check on the server side for .noz files in you repo (a jgit thing), --- This happens both using gerrit and using git directly... My thought is more that git doesn't handle dodgy connections over openvpn (udp) that goes over dodgy international vpn links. I conclusion has always been that it ends up in a unpredictable state, like a blocking read
git hangs on pthread_join
Hi, I'm running a rather special configuration, basically i have a gerrit server pushing git data over openvpn connections (company regulations n' stuff)... git 1.8.2.1 is started by xinetd ... port= 9418 socket_type = stream wait= no user= gerrit2 server = /usr/bin/git server_args = daemon --inetd --syslog --export-all --enable=receive-pack --init-timeout=3 --timeout=180 --base-path= ... nice= 10 per_source = UNLIMITED instances = UNLIMITED flags = KEEPALIVE NODELAY --- Keepalive and nodelay has been added post fact, the same goes for the timeouts. I have found "git receive-pack"s that has been running for days/weeks without terminating Attaching gdb and doing a trace results in: #0 0x003261207b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x004ce58b in finish_async () #2 0x0045744b in cmd_receive_pack () #3 0x00404851 in handle_internal_command () #4 0x00404c9d in main () (sorry don't have any debug data for the binary packages apparenlty (rpms was built from the official source)) (RHEL 5 machine with glibc 2.5-65.el5_7.1) Anyone that has any clues about what could be going wrong? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
