Running deployer as a service

Hi everybody,

Anybody knows how I can running a deployer environment as a service? I try to do it in debian (without X11) using /etc/init.d , but the boot sequence hang it when start the deployer environment (no appear the login entry, and others terminals have been disabled¡)

I want to do it in order to execute some Orocos components without login needs.

Note: I'm using the command "start-stop-daemon" to execute the deployer-gnulinux on my init.d script.

Regards, Toni

Running deployer as a service

2012/1/24 <antonio [dot] castellon [..] ...>:
> Hi everybody,
>
> Anybody knows how I can running a deployer environment as a service? I
try to
> do it in debian (without X11) using /etc/init.d , but the boot sequence
hang
> it when start the deployer environment (no appear the login entry, and
> others terminals have been disabled¡)
>
> I want to do it in order to execute some Orocos components without login
> needs.
>
> Note: I'm using the command "start-stop-daemon" to execute the
> deployer-gnulinux on my init.d script.
>
>

Hi,

there is no problem doing this. I think the key is to tell
"start-stop-daemon" to run your deployer in "background" with the "-b" or
"--background" option.

Here is my start line in my init.d script for instance :
start-stop-daemon -Smbv -x /opt/boot.sh -p $PIDFILE \
|| return 2

> Regards,
> Toni
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

enkulator's picture

Running deployer as a service

Hi Willy,

I used background and the blocking session dissapear, but now, the deployer
is not in memory¿? are you sure that your deployer is in memory ( I
launched the script directly by: *service myservice* ... but *ps -ef |
grep deployer* return nothing in memory)

I'm on Debian and I used directly the command:

*start-stop-daemon --background --start --make-pidfile --pidfile
/var/run/ugv-core.pid -d /home/root/ugv --exec
/orocos/install/bin/deployer-gnulinux -- "-s init.xml" || return 2*

Also I test using:

*start-stop-daemon -Smbv --make-pidfile --pidfile /var/run/ugv-core.pid
-d /home/root/ugv --exec /orocos/install/bin/deployer-gnulinux -- "-s
init.xml" || return 2*
*
*
*resulting the same... *
¿Could you check it?

Regards,
Toni

Running deployer as a service

2012/1/24 Antonio Castellon <antonio [dot] castellon [..] ...>

> Hi Willy,
>
> I used background and the blocking session dissapear, but now, the
> deployer is not in memory¿? are you sure that your deployer is in memory (
> I launched the script directly by: *service myservice* ... but *ps -ef |
> grep deployer* return nothing in memory)
>
> I'm on Debian and I used directly the command:
>
> *start-stop-daemon --background --start --make-pidfile --pidfile
> /var/run/ugv-core.pid -d /home/root/ugv --exec
> /orocos/install/bin/deployer-gnulinux -- "-s init.xml" || return 2*
>
> Also I test using:
>
> *start-stop-daemon -Smbv --make-pidfile --pidfile /var/run/ugv-core.pid
> -d /home/root/ugv --exec /orocos/install/bin/deployer-gnulinux -- "-s
> init.xml" || return 2*
> *
> *
> *resulting the same... *
> ¿Could you check it?
>
>
I am sorry, I can't test this before a week at least.
Check your */home/root/ugv/*orocos.log, maybe the deployer is quitting
early.

> Regards,
> Toni
>

enkulator's picture

Running deployer as a service

Hi Willy,

Yes, I see it before... the *orocos.log* informed that the deployer is
kick-out, but I can't understand what is the reason, No Errors are
showed ..:-(

[Info][Thread] Creating Thread for scheduler: 1
[Info][TaskBrowser] Thread created with sheduler type '1', priority 0, cpu
affinity 4294967295 and period 0.
[Info][Logger] Entering Task Deployer
[Info][DeploymentComponent::stopComponentsGroup] Stopping group 0
[Info][DeploymentComponent::cleanupComponentsGroup] Cleaning up group 0
[Info][Logger] Unloading group 0
[Info][Logger] Kick-out of group 0 successful.
[Info][Logger] Orocos Logging Deactivated.

I launch the deployer without load components , the script only run the
deployer-gnulinux.
Any idea?

Thanks in advance for your support,
Toni

On Tue, Jan 24, 2012 at 17:33, Willy Lambert <lambert [dot] willy [..] ...>wrote:

>
>
> 2012/1/24 Antonio Castellon <antonio [dot] castellon [..] ...>
>
>> Hi Willy,
>>
>> I used background and the blocking session dissapear, but now, the
>> deployer is not in memory¿? are you sure that your deployer is in memory (
>> I launched the script directly by: *service myservice* ... but *ps -ef
>> | grep deployer* return nothing in memory)
>>
>> I'm on Debian and I used directly the command:
>>
>> *start-stop-daemon --background --start --make-pidfile --pidfile
>> /var/run/ugv-core.pid -d /home/root/ugv --exec
>> /orocos/install/bin/deployer-gnulinux -- "-s init.xml" || return 2*
>>
>> Also I test using:
>>
>> *start-stop-daemon -Smbv --make-pidfile --pidfile
>> /var/run/ugv-core.pid -d /home/root/ugv --exec
>> /orocos/install/bin/deployer-gnulinux -- "-s init.xml" || return 2*
>> *
>> *
>> *resulting the same... *
>> ¿Could you check it?
>>
>>
> I am sorry, I can't test this before a week at least.
> Check your */home/root/ugv/*orocos.log, maybe the deployer is quitting
> early.
>
>
>
>
>
>> Regards,
>> Toni
>>
>
>

Running deployer as a service

On Tue, Jan 24, 2012 at 5:56 PM, Antonio Castellon <
antonio [dot] castellon [..] ...> wrote:

> Hi Willy,
>
> Yes, I see it before... the *orocos.log* informed that the deployer is
> kick-out, but I can't understand what is the reason, No Errors are
> showed ..:-(
>
> [Info][Thread] Creating Thread for scheduler: 1
> [Info][TaskBrowser] Thread created with sheduler type '1', priority 0,
> cpu affinity 4294967295 and period 0.
> [Info][Logger] Entering Task Deployer
> [Info][DeploymentComponent::stopComponentsGroup] Stopping group 0
> [Info][DeploymentComponent::cleanupComponentsGroup] Cleaning up group 0
> [Info][Logger] Unloading group 0
> [Info][Logger] Kick-out of group 0 successful.
> [Info][Logger] Orocos Logging Deactivated.
>
>
>
> I launch the deployer without load components , the script only run the
> deployer-gnulinux.
> Any idea?
>

The deployer opens a terminal, and gets a 'ctrl-d' because it is running in
the background. As a consequence, it quits and cleans up.

There is bin/rttscript which is a deployer without a TaskBrowser prompt
(takes both XML and ops files). Be warned, you need to find a way to delay
the exit of the application, for example, by blocking on a condition on the
last script you provided.. See line 165 of deployer.cpp. Any suggestions to
provide a standard way to implement this are welcome.

Peter

Running deployer as a service

I think I was using the deployer under "screen" in fact :D That's why it
weren't interrupted.

2012/1/24 Peter Soetens <peter [..] ...>

> On Tue, Jan 24, 2012 at 5:56 PM, Antonio Castellon <
> antonio [dot] castellon [..] ...> wrote:
>
>> Hi Willy,
>>
>> Yes, I see it before... the *orocos.log* informed that the deployer is
>> kick-out, but I can't understand what is the reason, No Errors are
>> showed ..:-(
>>
>> [Info][Thread] Creating Thread for scheduler: 1
>> [Info][TaskBrowser] Thread created with sheduler type '1', priority 0,
>> cpu affinity 4294967295 and period 0.
>> [Info][Logger] Entering Task Deployer
>> [Info][DeploymentComponent::stopComponentsGroup] Stopping group 0
>> [Info][DeploymentComponent::cleanupComponentsGroup] Cleaning up group 0
>> [Info][Logger] Unloading group 0
>> [Info][Logger] Kick-out of group 0 successful.
>> [Info][Logger] Orocos Logging Deactivated.
>>
>>
>>
>> I launch the deployer without load components , the script only run the
>> deployer-gnulinux.
>> Any idea?
>>
>
> The deployer opens a terminal, and gets a 'ctrl-d' because it is running
> in the background. As a consequence, it quits and cleans up.
>
> There is bin/rttscript which is a deployer without a TaskBrowser prompt
> (takes both XML and ops files). Be warned, you need to find a way to delay
> the exit of the application, for example, by blocking on a condition on the
> last script you provided.. See line 165 of deployer.cpp. Any suggestions to
> provide a standard way to implement this are welcome.
>
> Peter
>
>
>

Running deployer as a service

here is the init file for info :

#! /bin/sh
### BEGIN INIT INFO
# Provides: ard_autostart
# Required-Start: $remote_fs $syslog $ard_can
# Required-Stop: $remote_fs $syslog $ard_can
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Example initscript
# Description: This is used to autostart ARd's binairies for matches
### END INIT INFO

# Author: Foo Bar <contact [..] ...>

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="This is used to autostart ARd's binairies for matches"
NAME=ard_autostart
DAEMON=/opt/boot.sh
DAEMON_ARGS=""
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the environnement variables are not present
if [ -x "/opt/env.sh" ] ; then
echo "ERROR : The /opt/env.sh script is not present : $DAEMON"
exit 0
else
. /opt/color.sh
#. /opt/env.sh
fi

# Exit if the package is not installed
if [ ! -x "$DAEMON" ] ; then
cecho "red" "The autostart script is not present : $DAEMON, or it doesn't
have execution rigths"
exit 0
fi

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test
> /dev/null \
|| return 1

if [ -f /opt/conf/MATCH ]; then
#S=start m=create pid file b=go to background v=verbose
start-stop-daemon -Smbv -x /opt/boot.sh -p $PIDFILE \
|| return 2
cecho "yellow" "Autostarting binaries !"
sleep 2
else
cecho "yellow" "/opt/conf/MATCH is not present, I am not autostarting
binaries"
fi

}

#
# Function that stops the daemon/service
#
do_stop()
{
if [ -f $PIDFILE ] ; then
cecho "yellow" "stopping autostarted binaries !"
kill -9 `cat $PIDFILE`
rm -f $PIDFILE
return 0
else
cecho "red" "process are not started !"
return 2
fi
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
return 0
}

case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
#reload|force-reload)
#
# If do_reload() is not implemented then leave this commented out
# and leave 'force-reload' as an alias for 'restart'.
#
#log_daemon_msg "Reloading $DESC" "$NAME"
#do_reload
#log_end_msg $?
#;;
restart|force-reload)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
#echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
exit 3
;;
esac

:

and the boot.sh contains either :
screen -D deployer-gnulinux -s truc.ops
or
roslaunch ....

2012/2/1 Willy Lambert <lambert [dot] willy [..] ...>

> I think I was using the deployer under "screen" in fact :D That's why it
> weren't interrupted.
>
>
> 2012/1/24 Peter Soetens <peter [..] ...>
>
>> On Tue, Jan 24, 2012 at 5:56 PM, Antonio Castellon <
>> antonio [dot] castellon [..] ...> wrote:
>>
>>> Hi Willy,
>>>
>>> Yes, I see it before... the *orocos.log* informed that the deployer is
>>> kick-out, but I can't understand what is the reason, No Errors are
>>> showed ..:-(
>>>
>>> [Info][Thread] Creating Thread for scheduler: 1
>>> [Info][TaskBrowser] Thread created with sheduler type '1', priority 0,
>>> cpu affinity 4294967295 and period 0.
>>> [Info][Logger] Entering Task Deployer
>>> [Info][DeploymentComponent::stopComponentsGroup] Stopping group 0
>>> [Info][DeploymentComponent::cleanupComponentsGroup] Cleaning up group 0
>>> [Info][Logger] Unloading group 0
>>> [Info][Logger] Kick-out of group 0 successful.
>>> [Info][Logger] Orocos Logging Deactivated.
>>>
>>>
>>>
>>> I launch the deployer without load components , the script only run the
>>> deployer-gnulinux.
>>> Any idea?
>>>
>>
>> The deployer opens a terminal, and gets a 'ctrl-d' because it is running
>> in the background. As a consequence, it quits and cleans up.
>>
>> There is bin/rttscript which is a deployer without a TaskBrowser prompt
>> (takes both XML and ops files). Be warned, you need to find a way to delay
>> the exit of the application, for example, by blocking on a condition on the
>> last script you provided.. See line 165 of deployer.cpp. Any suggestions to
>> provide a standard way to implement this are welcome.
>>
>> Peter
>>
>>
>>
>

enkulator's picture

Running deployer as a service

Ok Willy,

One last question to understand correctly your script,
you use on start twice calls to the script-deployer (boot.sh) ... why? (the
first is not in background,,,it have any sense?)

My script is function on workstation correctly without start-stop-daemon
call and using the parameter -dmS on screen command. Later I check it
onboard and I will say you if it was successfull.

[init.d/script]
...
# call directly the boot.sh
boot.sh || return 2
...

[boot.sh]
...
screen -dmS deployer-gnulinux -s test.ops
...

Thanks in advance
Toni

>>
>

Running deployer as a service

2012/2/3 Antonio Castellon <antonio [dot] castellon [..] ...>

> Ok Willy,
>
>
> One last question to understand correctly your script,
> you use on start twice calls to the script-deployer (boot.sh) ... why?
> (the first is not in background,,,it have any sense?)
>

the first call is a test. I don't really know if it is really usefull but
to be honest I use the /etc/init.d/skeleton file as a model without
wondering much about the "why"

>
> My script is function on workstation correctly without start-stop-daemon
> call and using the parameter -dmS on screen command. Later I check it
> onboard and I will say you if it was successfull.
>

great !

>
> [init.d/script]
> ...
> # call directly the boot.sh
> boot.sh || return 2
> ...
>
>
> [boot.sh]
> ...
> screen -dmS deployer-gnulinux -s test.ops
> ...
>
>
>
> Thanks in advance
> Toni
>
>
>>>
>>
>

enkulator's picture

Running deployer as a service

Thanks Peter for your comments,
Now I 'm evaluated to use an another executable component (usign main_ORO)
in order to generate a controled loop() which load the XML configuration
files that defines the mini architecture of components to be loaded and
executed.
My last question is if exists other easy method based on
luascript/orocos-script that allow to do it without generate an extra
component.... I try to test something like:

while(true){};

into a *test.ops* file, but it hang the boot sequence (this is the reason
about my delay in my response).

Thnaks in advance,
Toni

Note: I attached the last email for remmeber my quesiton. As you said me, I
check the deployer.cpp but I can't imaginate how to do it.

On Tue, Jan 24, 2012 at 23:44, Peter Soetens <peter [..] ...>wrote:

> On Tue, Jan 24, 2012 at 5:56 PM, Antonio Castellon <
> antonio [dot] castellon [..] ...> wrote:
>
>> Hi Willy,
>>
>> Yes, I see it before... the *orocos.log* informed that the deployer is
>> kick-out, but I can't understand what is the reason, No Errors are
>> showed ..:-(
>>
>> [Info][Thread] Creating Thread for scheduler: 1
>> [Info][TaskBrowser] Thread created with sheduler type '1', priority 0,
>> cpu affinity 4294967295 and period 0.
>> [Info][Logger] Entering Task Deployer
>> [Info][DeploymentComponent::stopComponentsGroup] Stopping group 0
>> [Info][DeploymentComponent::cleanupComponentsGroup] Cleaning up group 0
>> [Info][Logger] Unloading group 0
>> [Info][Logger] Kick-out of group 0 successful.
>> [Info][Logger] Orocos Logging Deactivated.
>>
>>
>>
>> I launch the deployer without load components , the script only run the
>> deployer-gnulinux.
>> Any idea?
>>
>
> The deployer opens a terminal, and gets a 'ctrl-d' because it is running
> in the background. As a consequence, it quits and cleans up.
>
> There is bin/rttscript which is a deployer without a TaskBrowser prompt
> (takes both XML and ops files). Be warned, you need to find a way to delay
> the exit of the application, for example, by blocking on a condition on the
> last script you provided.. See line 165 of deployer.cpp. Any suggestions to
> provide a standard way to implement this are welcome.
>
> Peter
>
>
>

enkulator's picture

try to understand rttscript

Dear developers,

I try to execute a non-periodic component that reads from serial port, it is successfull execution when it is running on command taskbrowser environment (deployer-<target>), it is always on memory capturing data. My problem appears when I try to launch it automatically in boot sequence as a service, in order that it capture data without login requirement.

my steps:

I use deployer-<target> it hangs my OS system boot sequence. Therefore, I use rttscript-<target> it only execute for few time (5 seconds aprox.) and later it is automatically closed.

As Peter said me, I try to use some block conditional sentence on my script, but I not found something like sleep or delay or wait on Orocos Script. Therefore I used as block command : while (true){}; but the result is the same, the script is automatically finished 5 seconds later to load the component (without errors).

Somebody knows what is wrong or another method to have the components running on the OS without login requirement?

Thanks in advance for your help. Toni

try to understand rttscript

On Wed, Feb 1, 2012 at 10:52 AM, <antonio [dot] castellon [..] ...> wrote:
> Dear developers,
>
> I try to execute a non-periodic component that reads from serial port, it is
> successfull execution when it is running on command taskbrowser environment
> (deployer-), it is always on memory capturing data.
> My problem appears when I try to launch it automatically in boot sequence as
> a service, in order that it capture data without login requirement.
>
> my steps:
>
> I use deployer- it hangs my OS system boot sequence. Therefore, I use
> rttscript- it only execute for few time (5 seconds aprox.) and later it is
> automatically closed.
>
> As Peter said me, I try to use some block conditional sentence on my script,
> but I not found something like sleep or delay or wait on Orocos Script.
> Therefore I used as block command : while (true){}; but the result is the
> same, the script is automatically finished 5 seconds later to load the
> component (without errors).

The while(true) block should effectively block your app forever (at
100% CPU usage). So at least that should work.
Could it be that something is sending Ctrl-C (SIGINT) or SIGHUP to
your program ?

What you really need is rttscript to deamonize, such that the Linux
init manager does not try to terminate your script ( I suppose ). I
have added a -d flag to rttscript which lets rttscript call fork()
early on and then proceeds in the background with the rest of the
execution.

>
> Somebody knows what is wrong or another method to have the components running
> on the OS without login requirement?

At least start to wait for SIGINT in the deployer. I attached a patch
that does this by adding waitForInterrupt() as a DeploymentComponent
function. Could you test it (call it from your script, not in a while
loop!) and see if it improves your situation ?

There is also a second patch which removes the ctrl-c blocking of the
taskbrowser, such that you can also test waitForInterrupt(). I think
this 'signal masking' in the taskbrowser should be removed anyway for
portability reasons...

The third patch adds the -d option to rttscript, which you will need as well.

>
> Thanks in advance for your help.
> Toni

Peter

enkulator's picture

try to understand rttscript

Hi Peter & Cia,

Finally, I test the patches but the execution using "*deployer-xenomai -d
-s init.xml*" has not result :-/ ... nothing is on memory and the *
orocos.log* file contains:

0.000 [ Info ][Logger] No ORO_LOGLEVEL environment variable set.
0.000 [ Info ][Logger] OROCOS version '2.4.0' compiled with GCC 4.4.5. in
Xenomai.
0.000 [ Info ][Logger] Orocos Logging Activated at level : [ Warning] ( 4
)
0.000 [ Info ][Logger] Reference System Time is : 9364100006 ticks (
3.0451 seconds ).
0.000 [ Info ][Logger] Logging is relative to this time.
0.000 [ Info ][Logger] Real-time memory: 17248 bytes free of 20480
allocated.
0.000 [ Info ][Logger] Setting OCL factory for real-time logging

... no more log is writted

however if I use "*deployer-xenomai -s init.xml*" (both test were executed
in command line into Debian 6.0.2 virtual machine)

0.000 [ Info ][Logger] No ORO_LOGLEVEL environment variable set.
0.000 [ Info ][Logger] OROCOS version '2.4.0' compiled with GCC 4.4.5.
Running in Xenomai.
0.000 [ Info ][Logger] Orocos Logging Activated at level : [ Warning] ( 4
)
0.000 [ Info ][Logger] Reference System Time is : 9652036173 ticks (
3.13873 seconds ).
0.000 [ Info ][Logger] Logging is relative to this time.
0.000 [ Info ][Logger] Real-time memory: 17248 bytes free of 20480
allocated.
0.000 [ Info ][Logger] Setting OCL factory for real-time logging
0.000 [ Info ][Logger] Xenomai Periodic Timer runs in preemptive
'one-shot' mode.
0.000 [ Info ][Logger] Installing SIGXCPU handler.
0.000 [ Info ][Logger] No RTT_COMPONENT_PATH set. Using default:
/root/orocos-toolchain-2.4.0/install/lib/orocos
0.000 [ Info ][Logger] plugin 'rtt' not loaded before.
0.000 [ Info ][Logger] Loading plugin libraries from directory
/root/orocos-toolchain-2.4.0/install/lib/orocos/xenomai/./plugins ...
0.000 [ Info ][Logger] Loaded RTT Service 'marshalling' from
'rtt-marshalling'
0.000 [ Info ][Logger] Loaded RTT Service 'scripting' from 'rtt-scripting'
0.000 [ Info ][Logger] typekit 'rtt' not loaded before.
0.000 [ Info ][Logger] Loading typekit libraries from directory
/root/orocos-toolchain-2.4.0/install/lib/orocos/xenomai/./types ...
0.000 [ Info ][TypekitRepository::Import] Loading Transport
mqueue://rtt-types.
{ ...* a lot of common traces *... }
0.000 [ Info ][DeploymentComponent::configureComponents] Configuration
successful for group 0.
0.000 [ Info ][DeploymentComponent::startComponentsGroup] Startup of
'AutoStart' components successful for group 0.
0.000 [ Info ][Logger] Successfully loaded, configured and started
components from init.xml
0.000 [ Info ][Thread] Creating Thread for scheduler: 1
0.000 [ Info ][TaskBrowser] Thread created with scheduler type '1',
priority 0, cpu affinity 4294967295 and period 0.
0.000 [ Info ][Logger] Entering Task Deployer

Are the patches succesfull done ? something is different when I test the
daemon parameter, but all script is shutdown/fatal exception without traces
or simple hang ..... Do you have any idea ? Other test to done by me?

Thanks in advance and best regards,
Toni

try to understand rttscript

Hi Antonio,

On Tue, Mar 13, 2012 at 10:28 AM, Antonio Castellon <
antonio [dot] castellon [..] ...> wrote:

> Hi Peter & Cia,
>
> Finally, I test the patches but the execution using "*deployer-xenomai -d
> -s init.xml*" has not result :-/ ... nothing is on memory and the *
> orocos.log* file contains:
>
> 0.000 [ Info ][Logger] No ORO_LOGLEVEL environment variable set.
> 0.000 [ Info ][Logger] OROCOS version '2.4.0' compiled with GCC 4.4.5. in
> Xenomai.
> 0.000 [ Info ][Logger] Orocos Logging Activated at level : [ Warning] (
> 4 )
> 0.000 [ Info ][Logger] Reference System Time is : 9364100006 ticks (
> 3.0451 seconds ).
> 0.000 [ Info ][Logger] Logging is relative to this time.
> 0.000 [ Info ][Logger] Real-time memory: 17248 bytes free of 20480
> allocated.
> 0.000 [ Info ][Logger] Setting OCL factory for real-time logging
>
> ... no more log is writted
>
>
The patch is indeed not yet working for Xenomai (see:
http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#M...
)

We'll have to adapt it such that the fork() is done before Xenomai is
initialised nor any RTT logging is done We could do this by modifying the
RTT::os layer to do the fork early on (detect '-d' flag) OR to manually
call the RTT OS initialisation functions in the deployer, after the fork.

I'll try to fix this later this week. Keep bugging us if you don't hear any
news :-)

Peter

enkulator's picture

try to understand rttscript

Many thanks Peter,
This changes will be included in future deployments of Orocos ? or it's
only a trick for me?

Regards,
Toni

On Sun, Feb 5, 2012 at 23:21, Peter Soetens <peter [..] ...>wrote:

> On Wed, Feb 1, 2012 at 10:52 AM, <antonio [dot] castellon [..] ...> wrote:
> > Dear developers,
> >
> > I try to execute a non-periodic component that reads from serial port,
> it is
> > successfull execution when it is running on command taskbrowser
> environment
> > (deployer-), it is always on memory capturing data.
> > My problem appears when I try to launch it automatically in boot
> sequence as
> > a service, in order that it capture data without login requirement.
> >
> > my steps:
> >
> > I use deployer- it hangs my OS system boot sequence. Therefore, I use
> > rttscript- it only execute for few time (5 seconds aprox.) and later it
> is
> > automatically closed.
> >
> > As Peter said me, I try to use some block conditional sentence on my
> script,
> > but I not found something like sleep or delay or wait on Orocos Script.
> > Therefore I used as block command : while (true){}; but the result is the
> > same, the script is automatically finished 5 seconds later to load the
> > component (without errors).
>
> The while(true) block should effectively block your app forever (at
> 100% CPU usage). So at least that should work.
> Could it be that something is sending Ctrl-C (SIGINT) or SIGHUP to
> your program ?
>
> What you really need is rttscript to deamonize, such that the Linux
> init manager does not try to terminate your script ( I suppose ). I
> have added a -d flag to rttscript which lets rttscript call fork()
> early on and then proceeds in the background with the rest of the
> execution.
>
> >
> > Somebody knows what is wrong or another method to have the components
> running
> > on the OS without login requirement?
>
> At least start to wait for SIGINT in the deployer. I attached a patch
> that does this by adding waitForInterrupt() as a DeploymentComponent
> function. Could you test it (call it from your script, not in a while
> loop!) and see if it improves your situation ?
>
> There is also a second patch which removes the ctrl-c blocking of the
> taskbrowser, such that you can also test waitForInterrupt(). I think
> this 'signal masking' in the taskbrowser should be removed anyway for
> portability reasons...
>
> The third patch adds the -d option to rttscript, which you will need as
> well.
>
> >
> > Thanks in advance for your help.
> > Toni
>
> Peter
>

try to understand rttscript

On Mon, Feb 6, 2012 at 1:09 PM, Antonio Castellon
<antonio [dot] castellon [..] ...> wrote:
> Many thanks Peter,
> This changes will be included in future deployments of Orocos ? or it's only
> a trick for me?

If you confirm that it works, I'll push it straight away to gitorious
for inclusion in next release :-)

Peter

enkulator's picture

Xenomai patch for use as service

Do you have more news about the patch to be used on Xenomai System? Best wishes, Toni

Xenomai patch for use as service

Hi Toni,

On Mon, Apr 2, 2012 at 9:19 AM, <antonio [dot] castellon [..] ...> wrote:
> Do you have more news about the patch to be used on Xenomai System?
> Best wishes,
> Toni

There were indeed some issues left which I hope are fixed now. They
are on the toolchain-2.5 branch and I have also attached them. They
should apply cleanly on 2.4 too. But I didn't test them myself on
Xenomai...

One of the problems were log() statements before initializing the OS.
I've also disabled the TaskBrowser for daemonized deployers.

Peter