[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[Q] drb, Session::Bash & FreeBSD

benny

10/15/2004 9:28:00 AM

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
16 Answers

benny

10/15/2004 9:30:00 AM

0

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

benny

10/15/2004 11:58:00 AM

0

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

David Ross

10/15/2004 1:08:00 PM

0

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
>
>
>
>
>



Dick Davies

10/15/2004 1:32:00 PM

0

* 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 :)

> 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


Ara.T.Howard

10/15/2004 2:21:00 PM

0

Ara.T.Howard

10/15/2004 2:27:00 PM

0

Ara.T.Howard

10/15/2004 2:42:00 PM

0

benny

10/15/2004 9:50:00 PM

0

Ara.T.Howard@noaa.gov wrote:

> On Fri, 15 Oct 2004, Dick Davies wrote:
>
[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

10/15/2004 10:21:00 PM

0

benny

10/15/2004 10:25:00 PM

0

Ara.T.Howard@noaa.gov wrote:

> 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