+++ This bug was initially created as a clone of Bug #289178 +++ I am sorry to clone a closed bug, but it has just happened to me and there was no explanation as for the "INVALID" resolution status. The bug has happened to me right now, Reproducible: Always Steps to Reproduce: 1. USE="daemon" emerge net-p2p/rtorrent 2. /etc/init.d/rtorrentd start 3. /etc/init.d/rtorrentd status Actual Results: Dynamic Runlevel: manual rtorrentd [ crashed ] Expected Results: Dynamic Runlevel: manual rtorrentd [ started ]
Portage 2.1.7.16 (default/linux/x86/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-gentoo-r6 i686) ================================================================= System uname: Linux-2.6.31-gentoo-r6-i686-Intel-R-_Pentium-R-_4_CPU_2.40GHz-with-gentoo-2.0.1 Timestamp of tree: Fri, 05 Feb 2010 18:35:01 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0-r1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA dlj-1.1" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--ask" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 modules mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl ssl sysfs threads unicode vhosts x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth auth_basic auth_digest authn_file authn_default authz_host authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="worker" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I made some changes to the init script as mentioned in bug 294435, can you please re-emerge rtorrent and test again?
*** Bug 342517 has been marked as a duplicate of this bug. ***
I believe ive hit this exact same bug. can you uncomment "rc_start_wait=100" in /etc/rc.conf and see what it says? If it is indeed the same bug as im getting it will return "/usr/bin/screen died" but the screen session will actually be created and it will let you connect to it using the user listed in /etc/conf.d/rtorrentd.
My opinion is that screen's forking breaks the init script. Hence i came up with the following solution: --- /usr/portage/net-p2p/rtorrent/files/rtorrentd.init 2010-03-18 21:37:05.000000000 +0100 +++ /etc/init.d/rtorrentd 2010-11-07 00:11:00.160338651 +0100 @@ -15,10 +15,11 @@ env TERM="xterm" \ start-stop-daemon \ --start \ + --background \ --user $USER \ --env HOME="${PWHOME:-/home/$USER}" \ --name rtorrent \ - --exec /usr/bin/screen -- -dmS rtorrentd /usr/bin/rtorrent + --exec /usr/bin/screen -- -DmS rtorrentd /usr/bin/rtorrent eend $? } As a sidenote: Apart from that, please update the sample .rtorrent.rc in /usr/share/doc/rtorrent. "stop_on_ratio" is no longer supported.
I was a little hasty with my earlier post. This also handles the creation and deletion of the pid-file, without which start-stop-daemon thinks the whole party crashed. --- /usr/portage/net-p2p/rtorrent/files/rtorrentd.init 2010-03-18 21:37:05.000000000 +0100 +++ /etc/init.d/rtorrentd 2010-11-07 00:45:28.526336971 +0100 @@ -15,10 +15,12 @@ env TERM="xterm" \ start-stop-daemon \ --start \ + --background \ + --pidfile /var/tmp/rtorrentd.pid --make-pidfile \ --user $USER \ --env HOME="${PWHOME:-/home/$USER}" \ --name rtorrent \ - --exec /usr/bin/screen -- -dmS rtorrentd /usr/bin/rtorrent + --exec /usr/bin/screen -- -DmS rtorrentd /usr/bin/rtorrent eend $? }
I changed: --name rtorrent to: --name Storrent i checked htop when i had started rtorrentd with --name rtorrent and then the proccess was named Storrent. I think screen may be causing this. So start-stop-daemon could not find the daemon so it marked it crashed. I think. hope this was usefull.
I believe latest versions (rtorrent-0.8.6-r3, rtorrent-0.8.7-r1) could have fixed this. Could you please try to re-emerge and verify? I am not able to reproduce this (but I couldn't even before the update so who knows...)
I'm still seeing this in net-p2p/rtorrent-0.8.7-r2 on a testing system. It is not fixed.
(In reply to comment #9) > I'm still seeing this in net-p2p/rtorrent-0.8.7-r2 on a testing system. It is > not fixed. Have you used etc-update/dispatch-conf after update? If so, please attach contents of your: * /etc/init.d/rtorrentd * /etc/conf.d/rtorrentd * rtorrent.rc of user that rtorrent is supposed to run as
(In reply to comment #10) > (In reply to comment #9) > > I'm still seeing this in net-p2p/rtorrent-0.8.7-r2 on a testing system. It is > > not fixed. > > Have you used etc-update/dispatch-conf after update? If so, please attach > contents of your: > * /etc/init.d/rtorrentd > * /etc/conf.d/rtorrentd > * rtorrent.rc of user that rtorrent is supposed to run as Nevermind, no need to attach these files. This happens with openrc/baselayout-2. Will look into it
rtorrent-0.8.6-r4 and rtorrent-0.8.7-r2 should fix the issue once and for all hopefully. Please let me know. My testing showed this to be working with baselayout-2
I assume you mean net-p2p/rtorrent-0.8.7-r3, but yes, it now works for me.
Yes, sorry for the typo. Closing as fixed thanks for reporting and patience.
I've just upgraded to baselayout-2.0.2, openrc-0.8.2-r1 and emerged net-p2p/rtorrent-0.8.6-r4. However, it is still crashed: # /etc/init.d/rtorrentd start * Starting rtorrent ... [ ok ] # /etc/init.d/rtorrentd status * status: crashed # ps ax|grep rtorrent 17913 pts/0 S+ 0:00 grep --colour=auto rtorrent #less /var/log/messages ... May 11 19:22:12 ddd /etc/init.d/rtorrentd[17905]: status: crashed ...
Reopened again
What data can I provide to help with this bug? This is my USE-flags: [I] net-p2p/rtorrent Installed versions: 0.8.6-r4(19:02:05 11.05.2011)(daemon ipv6 xmlrpc -debug) This is my /etc/rc.conf: rc_interactive="YES" rc_shell=/sbin/sulogin unicode="YES" rc_sys="" rc_tty_number=12 This is my /etc/init.d/rtorrentd: #!/sbin/runscript depend() { use net ypbind nis after slapd mysqld postgresql } start() { PWHOME="$(getent passwd $USER | awk -F: '{ print $6 }')" ebegin "Starting rtorrent" env TERM="xterm" \ start-stop-daemon \ --start \ --make-pidfile \ --pidfile /var/run/rtorrentd.pid \ --background \ --user $USER \ --chuid $USER \ --env HOME="${PWHOME:-/home/$USER}" \ --name rtorrent \ --exec /usr/bin/screen -- -D -m -S rtorrentd /usr/bin/rtorrent eend $? } stop() { ebegin "Stopping rtorrent" start-stop-daemon --stop --signal 15 \ --pidfile /var/run/rtorrentd.pid eend $? } This is my /etc/conf.d/rtorrentd: USER="hex" This is my ~/.rtorrent.rc: scgi_port = localhost:5000 encoding_list = UTF-8 handshake_log = yes min_peers = 128 max_peers = 500 min_peers_seed = 128 max_peers_seed = 500 max_uploads = 64 download_rate = 0 upload_rate = 0 directory = /home/inc/torr/ session = ~/.config/rtorrent/session session_save = yes schedule = low_diskspace,5,60,close_low_diskspace=100M port_range = 51412-51412 port_random = no use_udp_trackers = yes encryption = allow_incoming,enable_retry,prefer_plaintext dht = off peer_exchange = no hash_read_ahead = 10 hash_interval = 100 hash_max_tries = 10 This is my free space in this directory: cd /home/inc/torr/ df -h ./ Filesystem Size Used Avail Use% Mounted on /dev/sdb3 427G 387G 20G 96% /mnt/d What data can I additionally provide? This bug is critical for me.
I assume you can run rtorrent without daemon mode? Also user "hex" is your user correct? I.e. $HOME of user "hex" has to have .rtorrent.rc and user "hex" has to have all rights to directories with torrents and places where it's saving things.
Yeah. It starts well if I run it in console without daemon script /etc/init.d/rtorrentd. $ rtorrent $ ps ax|grep rtorrent 13749 pts/2 R+ 2:22 rtorrent 14004 pts/0 S+ 0:00 grep --colour=auto rtorrent And It works fine. rtorrentd also worked well without any problems before update to baselayout-2 and openrc. Yep, hex is my user and all rights are fine. I use rutorrent to control rtorrent. hex have all the rights to directories a and .rtorrent.rc is in a correct place: $ ls -l ~/.rtorrent.rc -rw-r--r-- 1 hex hex 4017 Фев 26 2010 /home/hex/.rtorrent.rc
LOL. I just started rtorrent in a console without daemon then I stopped it with CTRL^q then I tried to start it from root with /etc/init.d/rtorrentd start and it worked!!! I will try to observe the behaviour of this daemon in the future and report to you. # /etc/init.d/rtorrentd start * Starting rtorrent ... [ ok ] # /etc/init.d/rtorrentd status * status: started # /etc/init.d/rtorrentd status * status: started
I've just tried to stop and start rtorrent with it's daemon (/etc/init.d/rtorrentd) several times and it still works fine without any problems.I will watch it's behaviour in the future after reboots of system and report to you there.
sorry for my english.....try to run from the local user /usr/bin/screen...... similar problem /var/run/screen/S-user belongs to the root.....but belong to user....At least I have a problem this...
I've just restarted my PC and rtorrent daemon restarted fine too without any problems and it works also fine. I think you may close this bug. (In reply to comment #22) > sorry for my english.....try to run from the local user /usr/bin/screen...... > similar problem /var/run/screen/S-user belongs to the root.....but belong > to user....At least I have a problem this... I think you should restart your system daemons under root rather then under your local user.
Not so much a problem but more of an observation. Should we really be sending SIGTERM (signal 15) on stop? In the past it was SIGINT (signal 2). That changed with the last update of the init script. I also noticed that all other init scripts for rtorrent (no matter the distrobution) use SIGINT, signal 2 or kill -s INT ${pid}. Which all amount to the same thing. Even the sample scripts on the rtorrent website use this and the documentation states to use a SIGINT to stop.
(In reply to comment #24) > Not so much a problem but more of an observation. Should we really be sending > SIGTERM (signal 15) on stop? In the past it was SIGINT (signal 2). That changed > with the last update of the init script. I also noticed that all other init > scripts for rtorrent (no matter the distrobution) use SIGINT, signal 2 or kill > -s INT ${pid}. Which all amount to the same thing. Even the sample scripts on > the rtorrent website use this and the documentation states to use a SIGINT to > stop. Try replacing 15 with 2 in the initscript and see what happens: # /etc/init.d/rtorrentd stop * Caching service dependencies ... [ ok ] * Stopping rtorrent ... * start-stop-daemon: 1 process refused to stop [ !! ] * ERROR: rtorrentd failed to stop My guess what's happening: we are storing pid file of screen process, not rtorrent process so we send SIGINT to screen, not rtorrent. This obviously doesn't work. SIGTERM solves this. For the record I don't think this will cause real problems unless you are using some interesting configuration that doesn't flush very often. Worst case scenario you will lose a few chunks that you'll have to re-download. Best way to do it properly would be for rtorrent to have a real daemon mode with no need to use screen. Until such time, I am open to suggestions. As per comment 20: closing
FYI I looked at those init examples and they try to find ~/.rtorrent/session/rtorrent.lock and figure out rtorrent pid from there. It's...not that nice because init script has to parse rtorrent config first (ugh!). I'd rather keep the init simple. It's enough of a hack as it is...
I'm sorry for the lack of feedback (account disabled & such). I confirm 0.8.6-r4 works fine, 0.8.7 fires up but dies as soon as i connect via XMLRPC (but this is for another bug...)
