Re: screen(1) on boot
Hi Nick, you've gotten some good advice already, so maybe this is overkill, but here's how I do it (added to /etc/rc.local on my machine at work) : /usr/bin/su pawe -c cd /home/pawe; ksh -lic '/usr/local/bin/screen -d -m /usr/local/bin/irssi' Starting a shell to start your screen ensures your environment is set up correctly (using the -l and -i options). This means you'll have a proper PATH etc when starting. On Wed, Apr 08, 2009 at 04:58:38PM -0400, Nick Guenther wrote: | I'd still like to know what's going on here. Running things from boot | scripts appearently works on Linux, and a guy I asked last night | seemed to think my method should work on FreeBSD, so what is OpenBSD | doing that's upsetting screen? I think OpenBSD is doing the sane thing here, not processing your login scripts when you're not asking for a login shell. If that is what you want, that's what you should configure. My 0.02 cents says FreeBSD acts the same as OpenBSD in this regard. Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: screen(1) on boot
Nick Guenther wrote: Yeah, it's there, that's why I said I don't have to bother with sudo -u to switch from root to my user. I still want to know what's killing screen. With that I can't help you either, but I run it with the following syntax successfully from rc.local: su -l $USER -c '/usr/local/bin/screen -l -d -m /usr/local/bin/rtorrent' Note that the -c already is parsed as the shell argument. Took me some time to figure it out, the crontab @reboot entry is much cleaner and less error prone. Kind regards, Markus
screen(1) on boot
I'm trying to make my torrents get started with my server. A script is at http://ubuntuforums.org/archive/index.php/t-859543.html that starts it up in a detached screen session, but obviously the linux-ism of that script won't work here. I pulled out the important bits and just to start off wrote this script which I placed in ~/bin/scr: #!/bin/sh TAG=TAG=`date +%H%M%S` sudo -u kousu -H /usr/local/bin/screen -d -m -S $TAG If I run this script as myself or as root (to simulate running as /etc/rc) it works: $ sh bin/scr $ screen -ls There is a screen on: 21423.152001(Detached) 1 Socket in /tmp/uscreens/S-kousu. $ sudo su # cd / # sh /home/kousu/bin/scr # ^D $ screen -ls There are screens on: 21423.152001(Detached) 22840.152333(Detached) 2 Sockets in /tmp/uscreens/S-kousu. $ So I added this to rc.local: sh /home/kousu/bin/scr But whenever I reboot I get this: $ screen -ls There is a screen on: 12042.151112(Dead ???) Remove dead screens with 'screen -wipe'. 1 Socket in /tmp/uscreens/S-kousu. I tried moving the sh /home/kousu/bin/scr to the very last line of /etc/rc just in case, right before exit 0 but still no luck. I took a look at all the environment variables in the working and broken cases and even copied all except the SUDO_* and SSH_* into my script and got no difference, so the only remaining difference between when I run it as a logged in user and when the system runs it for me is that /etc/rc gets run under the the login class 'daemon'. But even that seems wrong since I just added a test user with login class 'daemon', su'd in, and ran my script and when I came back to my user account had a shiny new screen session waiting for me. My only remaining theory is that getty(8) or login(1) is resetting the terminals which might make screen(1) sad, but I have no idea how to get error messages out of screen at boot time. Interestingly, running rtorrent from my crontab as @reboot screen -fa -d -m -S torrents rtorrent (thanks http://www.plouj.com/blog/2008/03/31/howto-run-rtorrent-from-cron-inside-screen) works and is simpler than having to sudo -u and give full paths for everything so I'll just stick with that. I'd still like to know what's going on here. Running things from boot scripts appearently works on Linux, and a guy I asked last night seemed to think my method should work on FreeBSD, so what is OpenBSD doing that's upsetting screen? Thanks for your attention, -Nick
Re: screen(1) on boot
On Wed, Apr 08, 2009 at 04:58:38PM -0400, Nick Guenther wrote: I'm trying to make my torrents get started with my server. A script is at http://ubuntuforums.org/archive/index.php/t-859543.html that starts it up in a detached screen session, but obviously the linux-ism of that script won't work here. I pulled out the important bits and just to start off wrote this script which I placed in ~/bin/scr: #!/bin/sh TAG=TAG=`date +%H%M%S` sudo -u kousu -H /usr/local/bin/screen -d -m -S $TAG If I run this script as myself or as root (to simulate running as /etc/rc) it works: $ sh bin/scr $ screen -ls There is a screen on: 21423.152001(Detached) 1 Socket in /tmp/uscreens/S-kousu. $ sudo su # cd / # sh /home/kousu/bin/scr # ^D $ screen -ls There are screens on: 21423.152001(Detached) 22840.152333(Detached) 2 Sockets in /tmp/uscreens/S-kousu. $ So I added this to rc.local: sh /home/kousu/bin/scr But whenever I reboot I get this: $ screen -ls There is a screen on: 12042.151112(Dead ???) Remove dead screens with 'screen -wipe'. 1 Socket in /tmp/uscreens/S-kousu. I tried moving the sh /home/kousu/bin/scr to the very last line of /etc/rc just in case, right before exit 0 but still no luck. I took a look at all the environment variables in the working and broken cases and even copied all except the SUDO_* and SSH_* into my script and got no difference, so the only remaining difference between when I run it as a logged in user and when the system runs it for me is that /etc/rc gets run under the the login class 'daemon'. But even that seems wrong since I just added a test user with login class 'daemon', su'd in, and ran my script and when I came back to my user account had a shiny new screen session waiting for me. My only remaining theory is that getty(8) or login(1) is resetting the terminals which might make screen(1) sad, but I have no idea how to get error messages out of screen at boot time. Interestingly, running rtorrent from my crontab as @reboot screen -fa -d -m -S torrents rtorrent (thanks http://www.plouj.com/blog/2008/03/31/howto-run-rtorrent-from-cron-inside-screen) works and is simpler than having to sudo -u and give full paths for everything so I'll just stick with that. I'd still like to know what's going on here. Running things from boot scripts appearently works on Linux, and a guy I asked last night seemed to think my method should work on FreeBSD, so what is OpenBSD doing that's upsetting screen? Thanks for your attention, -Nick Why don't you use btpd (it's in ports). http://www.murmeldjur.se/btpd/ I use it to make exactly what you mean (and then btcli to monitor from time to time).
Re: screen(1) on boot
On Wed, Apr 08, 2009 at 04:58:38PM -0400, Nick Guenther wrote: I'm trying to make my torrents get started with my server. A script is at http://ubuntuforums.org/archive/index.php/t-859543.html that starts it up in a detached screen session, but obviously the linux-ism of that script won't work here. I pulled out the important bits and just to start off wrote this script which I placed in ~/bin/scr: #!/bin/sh TAG=TAG=`date +%H%M%S` sudo -u kousu -H /usr/local/bin/screen -d -m -S $TAG If I run this script as myself or as root (to simulate running as /etc/rc) it works: $ sh bin/scr $ screen -ls There is a screen on: 21423.152001(Detached) 1 Socket in /tmp/uscreens/S-kousu. Try the @reboot entry in your personal crontab. That's how I get my tmux session going. And switch to tmux, it's better. :) -ME
Re: screen(1) on boot
Yeah, it's there, that's why I said I don't have to bother with sudo -u to switch from root to my user. I still want to know what's killing screen. Thanks, -Nick On 08/04/2009, Mike Erdely m...@erdelynet.com wrote: On Wed, Apr 08, 2009 at 04:58:38PM -0400, Nick Guenther wrote: I'm trying to make my torrents get started with my server. A script is at http://ubuntuforums.org/archive/index.php/t-859543.html that starts it up in a detached screen session, but obviously the linux-ism of that script won't work here. I pulled out the important bits and just to start off wrote this script which I placed in ~/bin/scr: #!/bin/sh TAG=TAG=`date +%H%M%S` sudo -u kousu -H /usr/local/bin/screen -d -m -S $TAG If I run this script as myself or as root (to simulate running as /etc/rc) it works: $ sh bin/scr $ screen -ls There is a screen on: 21423.152001(Detached) 1 Socket in /tmp/uscreens/S-kousu. Try the @reboot entry in your personal crontab. That's how I get my tmux session going. And switch to tmux, it's better. :) -ME
Re: screen(1) on boot
I ran it for a while but it's too barebones for me. IIRC, It doesn't let me monitor torrent-packets and peers and all the other niceties the usual torrent clients have. Especially, it doesn't support encryption. On 08/04/2009, Abel Camarillo acam...@the00z.org wrote: On Wed, Apr 08, 2009 at 04:58:38PM -0400, Nick Guenther wrote: I'm trying to make my torrents get started with my server. A script is at http://ubuntuforums.org/archive/index.php/t-859543.html that starts it up in a detached screen session, but obviously the linux-ism of that script won't work here. I pulled out the important bits and just to start off wrote this script which I placed in ~/bin/scr: #!/bin/sh TAG=TAG=`date +%H%M%S` sudo -u kousu -H /usr/local/bin/screen -d -m -S $TAG If I run this script as myself or as root (to simulate running as /etc/rc) it works: $ sh bin/scr $ screen -ls There is a screen on: 21423.152001(Detached) 1 Socket in /tmp/uscreens/S-kousu. $ sudo su # cd / # sh /home/kousu/bin/scr # ^D $ screen -ls There are screens on: 21423.152001(Detached) 22840.152333(Detached) 2 Sockets in /tmp/uscreens/S-kousu. $ So I added this to rc.local: sh /home/kousu/bin/scr But whenever I reboot I get this: $ screen -ls There is a screen on: 12042.151112(Dead ???) Remove dead screens with 'screen -wipe'. 1 Socket in /tmp/uscreens/S-kousu. I tried moving the sh /home/kousu/bin/scr to the very last line of /etc/rc just in case, right before exit 0 but still no luck. I took a look at all the environment variables in the working and broken cases and even copied all except the SUDO_* and SSH_* into my script and got no difference, so the only remaining difference between when I run it as a logged in user and when the system runs it for me is that /etc/rc gets run under the the login class 'daemon'. But even that seems wrong since I just added a test user with login class 'daemon', su'd in, and ran my script and when I came back to my user account had a shiny new screen session waiting for me. My only remaining theory is that getty(8) or login(1) is resetting the terminals which might make screen(1) sad, but I have no idea how to get error messages out of screen at boot time. Interestingly, running rtorrent from my crontab as @reboot screen -fa -d -m -S torrents rtorrent (thanks http://www.plouj.com/blog/2008/03/31/howto-run-rtorrent-from-cron-inside-screen) works and is simpler than having to sudo -u and give full paths for everything so I'll just stick with that. I'd still like to know what's going on here. Running things from boot scripts appearently works on Linux, and a guy I asked last night seemed to think my method should work on FreeBSD, so what is OpenBSD doing that's upsetting screen? Thanks for your attention, -Nick Why don't you use btpd (it's in ports). http://www.murmeldjur.se/btpd/ I use it to make exactly what you mean (and then btcli to monitor from time to time).
