Product: net-p2p/gift version 0.11.8.1 Installed gift and made a minimal configuration. #/etc/init.d/gift status * status: stopped # /etc/init.d/gift start * Starting giFTd ... * Failed to start gift. Check /var/log/giftd.log for more information (/var/log/giftd.log remains empty. According to 'ps', giftd us now running.) # /etc/init.d/gift stop * ERROR: "gift" has not yet been started. # /etc/init.d/gift start * Starting giFTd ... [ ok ] # /etc/init.d/gift stop * Stopping giFTd - please wait ... [ ok ] As can be seen above, giftd is started on the first trial, but doesn't enter "Started" state, so cannot be stopped but can still be (re-)started. # emerge info Portage 2.0.51.22-r3 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r2-embla x86_64) ================================================================= System uname: 2.6.14-gentoo-r2-embla x86_64 AMD Athlon(tm) 64 Processor 4000+ Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon64 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sfperms strict" GENTOO_MIRRORS=" http://mir1.ovh.net/gentoo-distfiles http://mirror.switch.ch/mirror/gentoo/ http://gentoo.oregonstate.edu http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/ " MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://gentoo-portage.yggdrasil.home/gentoo-portage" USE="amd64 X acpi alsa apache2 audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cups curl dbus dvd dvdr eds emacs emboss encode esd exif expat fam foomaticdb fortran gd gdbm gif glut gnome gpm gstreamer gtk gtk2 hal idn imagemagick imlib ipv6 java jpeg junit kde lcms libwww lzw lzw-tiff mad mbox mhash mikmod mng motif mozcalendar mozilla mp3 mpeg ncurses new-login nls nptl nvidia ogg opengl oss pam pcre pdflib perl plugin png ppds python qt quicktime readline recode scanner sdl spell ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev usb userlocales vorbis wmf xine xml xml2 xmms xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
The service startup appears to fail when attempting to detect the PID, after the call to start-stop-daemon. I can only suspect that this is a race condition, whereby the process is either started asynchronously by start-stop-daemon, or is started as root and then "changes ownership". However, with insufficient knowledge of *nix processes and\or the start-stop-daemon program.... Adding a sleep before the process detection makes the problem go away, although whether it counts as a fix or not is doubtful; all it does is provide a handicap to one half of the race. I've attached a patch file to the bug.
Created attachment 80071 [details, diff] Patch for gift init.d script See previous post
Thank you for the patch. I agree, there seems to be something odd with the way this works upstream; however, it does not appear to cause any vulnerabilities, and by sleeping, we give the process ample time to start correctly on slower systems. I only seem to experience this on my machine and slow processor. As such, this is fixed in portage without a r-bump, as very few people seem to be having trouble. Re-merge gift with and the fix will be applied. In the next revision of gift, the upgrade will be applied to everyone else.
