[Q] drb, Session::Bash & FreeBSD

ruby-talk
1

Dear list,

I am using a kind of session-daemon who receives messages via drb and
sometimes it has to execute shell commands based on the message and to
return the result to the caller.

now i got 2 problems:

···

------------------
1. problem

Inside the session-daemon I used

result = `#{cmd}`

to execute the command and it worked quite well.
however I wanted to get the error-messages as well, so I considered using
Session::Bash:

stdout, stderr = Session::Bash::new.execute "#{cmd}"

for most command that works fine, but I have a shell script (first
line /usr/local/bin/bash) which returns some messages using "echo".
this messages never get into stdout (the new way) but the get back to result
(the old way). I also tried "/usr/local/bin/bash myshellscript" but that
didn't work ether. what am I missing?

------------------------

2nd problem (maybe only FreeBSD related)

the normal way to automatically start a service on system start in FreeBSD
is to have shell script in /usr/local/etc/rc.d/
(say /usr/local/etc/rc.d/session_daemon_starter.sh) which respond to the
parameter 'start' (and to 'stop' for the shutdown). I did this several
time: no prob.

the corresponding line in 'session_daemon_starter.sh' says

path_to_my_session-daemon &

to start it in the background. in 'path_to_my_session-daemon' itself the
first line is

#!/usr/local/bin/ruby

as usual. when I start 'session_daemon_starter.sh' by hand, e.g.

/usr/local/etc/rc.d/session_daemon_starter.sh start

everything is working fine: the session-daemon is running, accepting
messages via drb, sending messages via drb and sometimes executing
shell-commands based on the messages it receives.

when 'session_daemon_starter.sh' is automatically started with the system
start the session-daemon is running, accepting messages via drb, sending
messages via drb but doesn't execute any shell commands:
neither via
result = `#{cmd}`
nor via
stdout, stderr = Session::Bash::new.execute "#{cmd}"

what am I missing?

thank you for any response,

benny

2

benny wrote:

for most command that works fine, but I have a shell script (first
line /usr/local/bin/bash)

sorry, I meant:
first line:
#!/usr/local/bin/bash

benny

3

benny wrote:

2nd problem (maybe only FreeBSD related)
[snip]

ok, I got some further ideas:
- when I started the script manually I was always the user "toor" (thats an
alias to root, but with the bash as shell instead of the default shell for
root which is the csh). that might make a difference
- I changed the shell of root to the bash, but that didn't fix it either

I guess I have to figure out:
- under which user the startup-scripts are executed in FreeBSD
- how to let the script be executed under another name

So I will contact the FreeBSD group for that

benny

4

Okay, issue1. you shoulnt use direct paths. use
#!/usr/bin/env bash

this will find bash in the path and use that to execute

I dont understand why it wouldn't work.. something must be wrong with the script?

I use all the BSDs.. you can use "su user - 'command' " because the scripts are ran by root, so it automatically drops to the user and executes the command when you run the commandspecified. You could also have it built in to the program. Ruby has Process::Sys.setuid(integer) which returns nil.

--dross

benny wrote:

···

Dear list,

I am using a kind of session-daemon who receives messages via drb and
sometimes it has to execute shell commands based on the message and to
return the result to the caller.

now i got 2 problems:

------------------
1. problem

Inside the session-daemon I used

result = `#{cmd}`

to execute the command and it worked quite well.
however I wanted to get the error-messages as well, so I considered using
Session::Bash:

stdout, stderr = Session::Bash::new.execute "#{cmd}"

for most command that works fine, but I have a shell script (first
line /usr/local/bin/bash) which returns some messages using "echo".
this messages never get into stdout (the new way) but the get back to result
(the old way). I also tried "/usr/local/bin/bash myshellscript" but that
didn't work ether. what am I missing?

------------------------

2nd problem (maybe only FreeBSD related)

the normal way to automatically start a service on system start in FreeBSD
is to have shell script in /usr/local/etc/rc.d/
(say /usr/local/etc/rc.d/session_daemon_starter.sh) which respond to the
parameter 'start' (and to 'stop' for the shutdown). I did this several
time: no prob.

the corresponding line in 'session_daemon_starter.sh' says

path_to_my_session-daemon &

to start it in the background. in 'path_to_my_session-daemon' itself the
first line is

#!/usr/local/bin/ruby

as usual. when I start 'session_daemon_starter.sh' by hand, e.g.

/usr/local/etc/rc.d/session_daemon_starter.sh start

everything is working fine: the session-daemon is running, accepting
messages via drb, sending messages via drb and sometimes executing
shell-commands based on the messages it receives.

when 'session_daemon_starter.sh' is automatically started with the system
start the session-daemon is running, accepting messages via drb, sending
messages via drb but doesn't execute any shell commands: neither via result = `#{cmd}` nor via stdout, stderr = Session::Bash::new.execute "#{cmd}"

what am I missing?

thank you for any response,

benny

5

* benny <listen@marcrenearns.de> [1024 10:24]:

Inside the session-daemon I used

result = `#{cmd}`

to execute the command and it worked quite well.
however I wanted to get the error-messages as well, so I considered using
Session::Bash:

stdout, stderr = Session::Bash::new.execute "#{cmd}"

I'll leave aside the whole security thing of this for now :slight_smile:

for most command that works fine, but I have a shell script (first
line /usr/local/bin/bash) which returns some messages using "echo".
this messages never get into stdout (the new way) but the get back to result
(the old way). I also tried "/usr/local/bin/bash myshellscript" but that
didn't work ether. what am I missing?

Perhaps echo is a shell built in - that might confuse things..
Try /bin/echo and see if that makes any difference?

when 'session_daemon_starter.sh' is automatically started with the system
start the session-daemon is running, accepting messages via drb, sending
messages via drb but doesn't execute any shell commands:
neither via
result = `#{cmd}`
nor via
stdout, stderr = Session::Bash::new.execute "#{cmd}"

Are you setting a path in the script? When you run it from your shell it inherits
all your environment, but the rc.d scripts run as root *cough* security hole *cough*....

···

--
Robots don't have emotions, and that sometimes makes me feel sad. - Bender
Rasputin :: Jack of All Trades - Master of Nuns

6

benny-

it's tough to say what might be happening but it sounds like a path/permission
error. eg. when your script is started via rc.d it's started at root and
that has some implications. as to the first problem i am also unsure of what
to say, can you post the the script called and the script that calls it using
Session::Bash. i've not had any bug reports about Session - but that sure
doesn't mean there aren't any and i'd love to diagnose this. btw i'm heading
out of town for a week in two days so send them pronto if you want me to look
at them.

kind regards.

-a

Dear list,

I am using a kind of session-daemon who receives messages via drb and
sometimes it has to execute shell commands based on the message and to
return the result to the caller.

now i got 2 problems:

------------------
1. problem

Inside the session-daemon I used

result = `#{cmd}`

to execute the command and it worked quite well.
however I wanted to get the error-messages as well, so I considered using
Session::Bash:

stdout, stderr = Session::Bash::new.execute "#{cmd}"

for most command that works fine, but I have a shell script (first
line /usr/local/bin/bash) which returns some messages using "echo".
this messages never get into stdout (the new way) but the get back to result
(the old way). I also tried "/usr/local/bin/bash myshellscript" but that
didn't work ether. what am I missing?

------------------------

2nd problem (maybe only FreeBSD related)

the normal way to automatically start a service on system start in FreeBSD
is to have shell script in /usr/local/etc/rc.d/
(say /usr/local/etc/rc.d/session_daemon_starter.sh) which respond to the
parameter 'start' (and to 'stop' for the shutdown). I did this several
time: no prob.

the corresponding line in 'session_daemon_starter.sh' says

path_to_my_session-daemon &

to start it in the background. in 'path_to_my_session-daemon' itself the
first line is

#!/usr/local/bin/ruby

as usual. when I start 'session_daemon_starter.sh' by hand, e.g.

/usr/local/etc/rc.d/session_daemon_starter.sh start

everything is working fine: the session-daemon is running, accepting
messages via drb, sending messages via drb and sometimes executing
shell-commands based on the messages it receives.

when 'session_daemon_starter.sh' is automatically started with the system
start the session-daemon is running, accepting messages via drb, sending
messages via drb but doesn't execute any shell commands:
neither via
result = `#{cmd}`
nor via
stdout, stderr = Session::Bash::new.execute "#{cmd}"

what am I missing?

thank you for any response,

benny

-a

···

On Fri, 15 Oct 2004, benny wrote:
--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

7

as an aside, you can set the path of a session using

   session.path = '/foo/bin:/bar/bin:/foobar/bin'

or

   session.path = %w( /foo/bin /bar/bin /foobar/bin )

or append with

   session.path = session.path + %w( /foo/bin /bar/bin /foobar/bin )

-a

···

On Fri, 15 Oct 2004, Dick Davies wrote:

start the session-daemon is running, accepting messages via drb, sending
messages via drb but doesn't execute any shell commands:
neither via
result = `#{cmd}`
nor via
stdout, stderr = Session::Bash::new.execute "#{cmd}"

Are you setting a path in the script? When you run it from your shell it inherits
all your environment, but the rc.d scripts run as root *cough* security hole *cough*....

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

8

i have a very simple c program that wraps ruby in a way that allows it to be a
setuid binary. this allows one to have shell scripts like

#!/usr/local/bin/toor_ruby

that will always execute as the user toor. it's at

it's primary purpose is for writing cgi scripts that run as a certain user,
but it could help in this case too.

-a

···

On Fri, 15 Oct 2004, benny wrote:

benny wrote:

2nd problem (maybe only FreeBSD related)
[snip]

ok, I got some further ideas:
- when I started the script manually I was always the user "toor" (thats an
alias to root, but with the bash as shell instead of the default shell for
root which is the csh). that might make a difference
- I changed the shell of root to the bash, but that didn't fix it either

I guess I have to figure out:
- under which user the startup-scripts are executed in FreeBSD

- how to let the script be executed under another name

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

9

it's tough to say what might be happening but it sounds like a
path/permission
error. eg. when your script is started via rc.d it's started at root and
that has some implications.

it ran as root in both cases, so the permissions should make no difference.
I did set the path explicit now

session = Session::Bash::new
session.path =
'/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin'
stdout, stderr = session.execute "#{cmd}"

no difference! in both cases (i.e. for all commands after autostart and for
the one bash-script after manual start there seems to be an endless loop
(i.e. the command never finishs). maybe there is a deeper difference in the
execution of the backquotes (being executed before the assignment) and a
(maybe asynchronous) execution via session.execute ? what about the
inheritence of paths to subshells, can I control that or is it done
automatically?

as to the first problem i am also unsure of
what to say, can you post the the script called and the script that calls
it using
Session::Bash.

I sent it to you directly via email.

i've not had any bug reports about Session - but that sure
doesn't mean there aren't any and i'd love to diagnose this. btw i'm
heading out of town for a week in two days so send them pronto if you want
me to look at them.

kind regards.

regards, benny

···

Ara.T.Howard@noaa.gov wrote:

10

[path setting discussion]

since all used commands are with full path names there should be no missing
environment effect.

when I started the services I started them as root (toor: root with bash as
shell). I also changed the default shell of root to the bash: no
difference. so its exactly as I said: the same script under the same user
with the same (but irrelevant) environment, when automatically started: no
sub-shell command where executed, when started by hand: no problem

BTW using /bin/echo instead of echo in the one script that didn't work at
all with Session:Bash didn't make any difference

benny

···

Ara.T.Howard@noaa.gov wrote:

On Fri, 15 Oct 2004, Dick Davies wrote:

11

it ran as root in both cases, so the permissions should make no difference.
I did set the path explicit now

session = Session::Bash::new
session.path =
'/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin'
stdout, stderr = session.execute "#{cmd}"

try this

   debuglog = open "/tmp/debuglog.#{ $$ }", 'w'
   debuglog.sync = true

   stdout, stderr =
     session.execute("#{ cmd }") do |o,e|
       debuglog << (o || e)
     end

then do a tail -f of the debuglog as it's being produced. perhaps this will
help tell you if the cmd has gone into an infinite loop... if that's the case
i can't really help. if it is not the case and your cmd completes you've
found a bug in the session lib.

inheritence of paths to subshells, can I control that or is it done
automatically?

automatic.

I sent it to you directly via email.

got it.

-a

···

On Sat, 16 Oct 2004, benny wrote:
--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

12

[path setting discussion]

since all used commands are with full path names there should be no missing
environment effect.

Session::Bash will start 'bash' and this is searched for using PATH.

you could change this with

   Session::Bash::DEFAULT_PROG.replace '/bin/bash'

when I started the services I started them as root (toor: root with bash as
shell). I also changed the default shell of root to the bash: no
difference. so its exactly as I said: the same script under the same user
with the same (but irrelevant) environment, when automatically started: no
sub-shell command where executed, when started by hand: no problem

if 'bash' was not found in the path no session would actually be started.
also, the commands run via session will use PATH inherited.

how about other issues - for example if this is automatically started is the
network up when it's started?

i have tried this in my crontab

   * * * * * /dmsp/reference/bin/ruby -r session -e 'print((Session::new.execute("echo 42")).first)' >/home/ahoward/out

and it works fine. eg. there seems to be no environment issues.

sorry i haven't been of more help... very busy today - more later...

BTW using /bin/echo instead of echo in the one script that didn't work at
all with Session:Bash didn't make any difference

makes sense.

-a

···

On Fri, 15 Oct 2004, benny wrote:
--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

13

the logfile is created and filled correctly with the output of the script.
it tells that it has finished, so that might be a bug in the session lib.

BTW with

result =
`PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin;
export PATH; #{cmd}`

I got my script running from the autostarting up. but I would like to use
the Session Module anyway (at least because of the fetching of stderr).

greetings, benny

···

Ara.T.Howard@noaa.gov wrote:

try this

debuglog = open "/tmp/debuglog.#{ $$ }", 'w'
debuglog.sync = true

stdout, stderr =
session.execute("#{ cmd }") do |o,e|
debuglog << (o || e)
end

then do a tail -f of the debuglog as it's being produced. perhaps this
will help tell you if the cmd has gone into an infinite loop... if that's
the case i can't really help. if it is not the case and your cmd
completes you've found a bug in the session lib.

14

which session version are you using?

-a

···

On Sat, 16 Oct 2004, benny wrote:

Ara.T.Howard@noaa.gov wrote:

try this

debuglog = open "/tmp/debuglog.#{ $$ }", 'w'
debuglog.sync = true

stdout, stderr =
session.execute("#{ cmd }") do |o,e|
debuglog << (o || e)
end

then do a tail -f of the debuglog as it's being produced. perhaps this
will help tell you if the cmd has gone into an infinite loop... if that's
the case i can't really help. if it is not the case and your cmd
completes you've found a bug in the session lib.

the logfile is created and filled correctly with the output of the script.
it tells that it has finished, so that might be a bug in the session lib.

BTW with

result =
`PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin;
export PATH; #{cmd}`

I got my script running from the autostarting up. but I would like to use
the Session Module anyway (at least because of the fetching of stderr).

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

15

basically this is saying that session never finds the end pattern in it's
output.

my reccomendation is to examine the source to find the place where the output
from bash is read. it will be in AbstractSession as a call to gets in the
execute method. add some code to print the line read each time (or perhaps
print to a logfile). this should illuminate the problem and tell us why
session never sees the pattern signaling end of command - it could be some
sort of bash/buffering issue i've not seen under linux, but which exists under
bsd - i'm not sure.

if you are using session-2.1.9 look around line 328 and add something like

   @log = open("/tmp/log#{ $$ }",'w') unless @log
   @log.sync = true
   @log << line

if this does not help i'll iterject some new debuggin measures into session
   and send it to you.

thanks for helping debug this - as you can imagine this sort of error is quite
hard to debug.

-a

···

On Sat, 16 Oct 2004, benny wrote:

the logfile is created and filled correctly with the output of the script.
it tells that it has finished, so that might be a bug in the session lib.

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

16

which session version are you using?

ls -al /usr/local/lib/ruby/gems/1.8/gems/session-2.1.9/lib:
total 32
drwxr-xr-x 2 root wheel 512B 16 Okt 02:03 .
drwxr-xr-x 3 root wheel 512B 14 Okt 22:46 ..
-rw-r--r-- 1 root wheel 14K 14 Okt 22:46 session-2.1.9.rb
-rw-r--r-- 1 root wheel 14K 14 Okt 22:46 session.rb

a diff on them says that they are identifal so its quite confusing to have 2
files there :slight_smile:

in the script I use

require 'rubygems'
require_gem 'session'

regards,
benny

···

Ara.T.Howard@noaa.gov wrote:

-a
--

===============================================================================

> EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
> PHONE :: 303.497.6469
> When you do something, you should burn yourself completely, like a good
> bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

17

ok, I'll try this tomorrow because I am going to bed now if you dont mind :slight_smile:
at this point I suggest to continue the conversation directly via email
since it might not be that interesting for the list anymore.

regards,
benny

···

Ara.T.Howard@noaa.gov wrote:

thanks for helping debug this - as you can imagine this sort of error is
quite hard to debug.