Thread: [Cppcms-users] Segmentaion fault occurs to booster::aio::io_service running in booster::thread
Brought to you by:
artyom-beilis
Menu
▾
▴
cppcms-users
|
From: CN <cn...@fa...> - 2016-05-08 14:04:36
|
File "t.cpp":
#include <booster/aio/io_service.h>
#include <cppcms/service.h>
#include <boost/bind.hpp>
#include <booster/shared_ptr.h>
#include <booster/log.h>
#include <signal.h>
booster::shared_ptr<cppcms::service> this_cppcms_service;
static int caught_signal=-1;
void signal_handler(int signal_number)
{
BOOSTER_DEBUG("begin handler");
caught_signal=signal_number;
this_cppcms_service->shutdown();
BOOSTER_DEBUG("end handler");
}
class my_class {
private:
booster::aio::io_service io_service;
public:
void start(){
io_service.run();
}
void stop(){
io_service.stop();
}
};
int main(int argc,char ** argv)
{
while(true){
try{
this_cppcms_service.reset(new
cppcms::service(argc,argv));
//Install signals catchers.
struct sigaction actions;
memset(&actions,0,sizeof(actions));
actions.sa_handler=signal_handler;
int result;
if(
(result=sigaction(SIGTERM,&actions,NULL))
!= 0
||
(result=sigaction(SIGHUP,&actions,NULL))
!= 0
){
BOOSTER_ERROR("") << "sigaction()
failed";
exit(EXIT_FAILURE);
}
my_class mc;
booster::thread
mc_thread(boost::bind(&my_class::start,&mc));
BOOSTER_DEBUG("==1==");
this_cppcms_service->run();
BOOSTER_DEBUG("==2==");
mc.stop(); mc_thread.join();
BOOSTER_DEBUG("==3==");
if(caught_signal == SIGTERM)
return 0;
BOOSTER_DEBUG("==4==");
//SIGHUP to reload configurations
}
catch(std::exception const &e){
BOOSTER_ERROR("") << e.what();
return 1;
}
}
return 0;
}
----------
File "t.js":
{
"service" : {
"api" : "fastcgi",
"socket" : "/tmp/t.sock",
"disable_global_exit_handling":true
},
"daemon":{
"enable":true,
"lock":"/tmp/t.pid"
},
"logging" : {
"level" : "debug",
"stderr" : false,
"syslog" : {
"enable":true,
"id" : "t"
}
}
}
--------
Commands issued:
cd /tmp
g++ -lbooster -lcppcms -lboost_system t.cpp
./a.out -c t.js
kill -TERM `cat t.pid`
--------
File "/var/log/syslog":
May 8 21:36:13 host t: ==1==: (t.cpp:51)
May 8 21:36:36 host t: begin handler: (t.cpp:12)
May 8 21:36:36 host t: end handler: (t.cpp:15)
May 8 21:36:36 host t: ==2==: (t.cpp:53)
May 8 21:36:36 host kernel: a.out[5146]: segfault at b5b5dba8 ip
b715205e sp bfad0620 error 4 in libpthread-2.19.so[b714a000+18000]
With this simple code, I get segfault at "mc.stop(); mc_thread.join();"
after issuing command "kill -TERM <pid>". Would someone please enlighten
me why?
Best regards,
CN
--
http://www.fastmail.com - Accessible with your email software
or over the web
|
|
From: Marcel H. <ke...@co...> - 2016-05-09 06:38:22
Attachments:
signature.asc
|
I'm not entirely sure, but don't you need something like '-pthread' to
use threads in a unix environment. Try that out.
On 05/08/2016 04:04 PM, CN wrote:
> File "t.cpp":
>
> #include <booster/aio/io_service.h>
> #include <cppcms/service.h>
> #include <boost/bind.hpp>
> #include <booster/shared_ptr.h>
> #include <booster/log.h>
> #include <signal.h>
> booster::shared_ptr<cppcms::service> this_cppcms_service;
> static int caught_signal=-1;
>
> void signal_handler(int signal_number)
> {
> BOOSTER_DEBUG("begin handler");
> caught_signal=signal_number;
> this_cppcms_service->shutdown();
> BOOSTER_DEBUG("end handler");
> }
>
> class my_class {
> private:
> booster::aio::io_service io_service;
> public:
> void start(){
> io_service.run();
> }
> void stop(){
> io_service.stop();
> }
> };
>
>
> int main(int argc,char ** argv)
> {
> while(true){
> try{
> this_cppcms_service.reset(new
> cppcms::service(argc,argv));
> //Install signals catchers.
> struct sigaction actions;
> memset(&actions,0,sizeof(actions));
> actions.sa_handler=signal_handler;
> int result;
> if(
> (result=sigaction(SIGTERM,&actions,NULL))
> != 0
> ||
> (result=sigaction(SIGHUP,&actions,NULL))
> != 0
> ){
> BOOSTER_ERROR("") << "sigaction()
> failed";
> exit(EXIT_FAILURE);
> }
> my_class mc;
> booster::thread
> mc_thread(boost::bind(&my_class::start,&mc));
>
> BOOSTER_DEBUG("==1==");
> this_cppcms_service->run();
> BOOSTER_DEBUG("==2==");
> mc.stop(); mc_thread.join();
> BOOSTER_DEBUG("==3==");
> if(caught_signal == SIGTERM)
> return 0;
> BOOSTER_DEBUG("==4==");
> //SIGHUP to reload configurations
> }
> catch(std::exception const &e){
> BOOSTER_ERROR("") << e.what();
> return 1;
> }
> }
> return 0;
> }
>
> ----------
>
> File "t.js":
>
> {
> "service" : {
> "api" : "fastcgi",
> "socket" : "/tmp/t.sock",
> "disable_global_exit_handling":true
> },
> "daemon":{
> "enable":true,
> "lock":"/tmp/t.pid"
> },
> "logging" : {
> "level" : "debug",
> "stderr" : false,
> "syslog" : {
> "enable":true,
> "id" : "t"
> }
> }
> }
>
> --------
>
> Commands issued:
>
> cd /tmp
> g++ -lbooster -lcppcms -lboost_system t.cpp
> ./a.out -c t.js
> kill -TERM `cat t.pid`
>
> --------
>
> File "/var/log/syslog":
>
> May 8 21:36:13 host t: ==1==: (t.cpp:51)
> May 8 21:36:36 host t: begin handler: (t.cpp:12)
> May 8 21:36:36 host t: end handler: (t.cpp:15)
> May 8 21:36:36 host t: ==2==: (t.cpp:53)
> May 8 21:36:36 host kernel: a.out[5146]: segfault at b5b5dba8 ip
> b715205e sp bfad0620 error 4 in libpthread-2.19.so[b714a000+18000]
>
>
> With this simple code, I get segfault at "mc.stop(); mc_thread.join();"
> after issuing command "kill -TERM <pid>". Would someone please enlighten
> me why?
>
> Best regards,
> CN
>
|
|
From: CN <cn...@fa...> - 2016-05-09 08:11:17
|
File "~/booster/lib/src/thread/pthread.cpp" already includes "pthread.h". Nevertheless, I have just tried as you suggested but got the same segmentation fault from the executable compiled with option "-pthread" added: g++ -lbooster -lcppcms -lboost_system -pthread t.cpp On Mon, May 9, 2016, at 02:20 PM, Marcel Hellwig wrote: > I'm not entirely sure, but don't you need something like '-pthread' to > use threads in a unix environment. Try that out. -- http://www.fastmail.com - mmm... Fastmail... |
|
From: Artyom B. <art...@gm...> - 2016-05-09 10:37:39
|
1st why are you using your own signal handler instead of one used by CppCMS it looks like doing the same stuff. On segfault - can you show the backtrace of the stack from gdb when it happens. Artyom > May 8 21:36:13 host t: ==1==: (t.cpp:51) > May 8 21:36:36 host t: begin handler: (t.cpp:12) > May 8 21:36:36 host t: end handler: (t.cpp:15) > May 8 21:36:36 host t: ==2==: (t.cpp:53) > May 8 21:36:36 host kernel: a.out[5146]: segfault at b5b5dba8 ip > b715205e sp bfad0620 error 4 in libpthread-2.19.so[b714a000+18000] > > > With this simple code, I get segfault at "mc.stop(); mc_thread.join();" > after issuing command "kill -TERM <pid>". Would someone please enlighten > me why? > |
|
From: Artyom B. <art...@ya...> - 2016-05-09 10:39:10
|
1st why are you using your own signal handler instead of one used by CppCMS?On segfault - can you show the backtrace of the stack from gdb when it happens.
Artyom
From: CN <cn...@fa...>
To: cpp...@li...
Sent: Sunday, May 8, 2016 5:04 PM
Subject: [Cppcms-users] Segmentaion fault occurs to booster::aio::io_service running in booster::thread
File "t.cpp":
#include <booster/aio/io_service.h>
#include <cppcms/service.h>
#include <boost/bind.hpp>
#include <booster/shared_ptr.h>
#include <booster/log.h>
#include <signal.h>
booster::shared_ptr<cppcms::service> this_cppcms_service;
static int caught_signal=-1;
void signal_handler(int signal_number)
{
BOOSTER_DEBUG("begin handler");
caught_signal=signal_number;
this_cppcms_service->shutdown();
BOOSTER_DEBUG("end handler");
}
class my_class {
private:
booster::aio::io_service io_service;
public:
void start(){
io_service.run();
}
void stop(){
io_service.stop();
}
};
int main(int argc,char ** argv)
{
while(true){
try{
this_cppcms_service.reset(new
cppcms::service(argc,argv));
//Install signals catchers.
struct sigaction actions;
memset(&actions,0,sizeof(actions));
actions.sa_handler=signal_handler;
int result;
if(
(result=sigaction(SIGTERM,&actions,NULL))
!= 0
||
(result=sigaction(SIGHUP,&actions,NULL))
!= 0
){
BOOSTER_ERROR("") << "sigaction()
failed";
exit(EXIT_FAILURE);
}
my_class mc;
booster::thread
mc_thread(boost::bind(&my_class::start,&mc));
BOOSTER_DEBUG("==1==");
this_cppcms_service->run();
BOOSTER_DEBUG("==2==");
mc.stop(); mc_thread.join();
BOOSTER_DEBUG("==3==");
if(caught_signal == SIGTERM)
return 0;
BOOSTER_DEBUG("==4==");
//SIGHUP to reload configurations
}
catch(std::exception const &e){
BOOSTER_ERROR("") << e.what();
return 1;
}
}
return 0;
}
----------
File "t.js":
{
"service" : {
"api" : "fastcgi",
"socket" : "/tmp/t.sock",
"disable_global_exit_handling":true
},
"daemon":{
"enable":true,
"lock":"/tmp/t.pid"
},
"logging" : {
"level" : "debug",
"stderr" : false,
"syslog" : {
"enable":true,
"id" : "t"
}
}
}
--------
Commands issued:
cd /tmp
g++ -lbooster -lcppcms -lboost_system t.cpp
./a.out -c t.js
kill -TERM `cat t.pid`
--------
File "/var/log/syslog":
May 8 21:36:13 host t: ==1==: (t.cpp:51)
May 8 21:36:36 host t: begin handler: (t.cpp:12)
May 8 21:36:36 host t: end handler: (t.cpp:15)
May 8 21:36:36 host t: ==2==: (t.cpp:53)
May 8 21:36:36 host kernel: a.out[5146]: segfault at b5b5dba8 ip
b715205e sp bfad0620 error 4 in libpthread-2.19.so[b714a000+18000]
With this simple code, I get segfault at "mc.stop(); mc_thread.join();"
after issuing command "kill -TERM <pid>". Would someone please enlighten
me why?
Best regards,
CN
--
http://www.fastmail.com - Accessible with your email software
or over the web
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Cppcms-users mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppcms-users
|
|
From: CN <cn...@fa...> - 2016-05-09 13:01:45
|
I am trying to implement a mechanism so that the program catches SIGHUP signal and accordingly reloads configuration file as suggested here: http://cppcms.com/wikipp/en/page/cppcms_1x_reload_application The signals handler installed by void service::setup_exit_handling() in file "service.cpp" simply calls cppcms::service::shutdown(). I therefore have to roll my own. Regarding the log of gdb backtrace, I seem to have encountered some trouble - upon the arrival of signal HUP, the process straightly disappears from gdb's control without trace leaving command "backtrace" useless. I am still trying to figure out how. I will post it as soon as I have it. Best regards, CN On Mon, May 9, 2016, at 06:36 PM, Artyom Beilis wrote: > 1st why are you using your own signal handler instead of one used > by CppCMS? > On segfault - can you show the backtrace of the stack from gdb when it > happens. > > > Artyom > >> **From:** CN <cn...@fa...> **To:** cppcms- >> us...@li... **Sent:** Sunday, May 8, 2016 5:04 PM >> **Subject:** [Cppcms-users] Segmentaion fault occurs to >> booster::aio::io_service running in booster::thread >> >> File "t.cpp": >> >> #include <booster/aio/io_service.h> >> #include <cppcms/service.h> >> #include <boost/bind.hpp> >> #include <booster/shared_ptr.h> >> #include <booster/log.h> >> #include <signal.h> >> booster::shared_ptr<cppcms::service> this_cppcms_service; >> static int caught_signal=-1; >> >> void signal_handler(int signal_number) >> { >> BOOSTER_DEBUG("begin handler"); >> caught_signal=signal_number; >> this_cppcms_service->shutdown(); >> BOOSTER_DEBUG("end handler"); >> } >> >> class my_class { >> private: >> booster::aio::io_service io_service; >> public: >> void start(){ >> io_service.run(); >> } >> void stop(){ >> io_service.stop(); >> } >> }; >> >> >> int main(int argc,char ** argv) >> { >> while(true){ >> try{ >> this_cppcms_service.reset(new >> cppcms::service(argc,argv)); >> //Install signals catchers. >> struct sigaction actions; >> memset(&actions,0,sizeof(actions)); >> actions.sa_handler=signal_handler; >> int result; >> if( >> (result=sigaction(SIGTERM,&actions,NULL)) >> != 0 >> || >> (result=sigaction(SIGHUP,&actions,NULL)) >> != 0 >> ){ >> BOOSTER_ERROR("") << "sigaction() >> failed"; >> exit(EXIT_FAILURE); >> } >> my_class mc; >> booster::thread >> mc_thread(boost::bind(&my_class::start,&mc)); >> >> BOOSTER_DEBUG("==1=="); >> this_cppcms_service->run(); >> BOOSTER_DEBUG("==2=="); >> mc.stop(); mc_thread.join(); >> BOOSTER_DEBUG("==3=="); >> if(caught_signal == SIGTERM) >> return 0; >> BOOSTER_DEBUG("==4=="); >> //SIGHUP to reload configurations >> } >> catch(std::exception const &e){ >> BOOSTER_ERROR("") << e.what(); >> return 1; >> } >> } >> return 0; >> } >> >> ---------- >> >> File "t.js": >> >> { >> "service" : { >> "api" : "fastcgi", >> "socket" : "/tmp/t.sock", >> "disable_global_exit_handling":true >> }, >> "daemon":{ >> "enable":true, >> "lock":"/tmp/t.pid" >> }, >> "logging" : { >> "level" : "debug", >> "stderr" : false, >> "syslog" : { >> "enable":true, >> "id" : "t" >> } >> } >> } >> >> -------- >> >> Commands issued: >> >> cd /tmp >> g++ -lbooster -lcppcms -lboost_system t.cpp >> ./a.out -c t.js >> kill -TERM `cat t.pid` >> >> -------- >> >> File "/var/log/syslog": >> >> May 8 21:36:13 host t: ==1==: (t.cpp:51) >> May 8 21:36:36 host t: begin handler: (t.cpp:12) >> May 8 21:36:36 host t: end handler: (t.cpp:15) >> May 8 21:36:36 host t: ==2==: (t.cpp:53) >> May 8 21:36:36 host kernel: a.out[5146]: segfault at b5b5dba8 ip >> b715205e sp bfad0620 error 4 in libpthread-2.19.so[b714a000+18000] >> >> >> With this simple code, I get segfault at "mc.stop(); >> mc_thread.join();" >> after issuing command "kill -TERM <pid>". Would someone please >> enlighten >> me why? >> >> Best regards, >> CN >> >> -- >> http://www.fastmail.com [1]- Accessible with your email software >> or over the web >> >> >> --------------------------------------------------------------------- >> --------- >> Find and fix application performance issues faster with Applications >> Manager >> Applications Manager provides deep performance insights into multiple >> tiers of >> your business applications. It resolves application problems >> quickly and >> reduces your MTTR. Get your free trial! >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> _______________________________________________ >> Cppcms-users mailing list >> Cpp...@li... >> https://lists.sourceforge.net/lists/listinfo/cppcms-users >> > ---------------------------------------------------------------------- > -------- > Find and fix application performance issues faster with > Applications Manager > Applications Manager provides deep performance insights into multiple > tiers of > your business applications. It resolves application problems > quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z[2] > _________________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users Links: 1. http://www.fastmail.com/ 2. https://ad.doubleclick.net/ddm/clk/302982198%3B130105516%3Bz -- http://www.fastmail.com - IMAP accessible web-mail |
|
From: CN <cn...@fa...> - 2016-05-09 15:35:52
|
On Mon, May 9, 2016, at 09:01 PM, CN wrote: > > Regarding the log of gdb backtrace, I seem to have encountered some > trouble - upon the arrival of signal HUP, the process straightly > disappears from gdb's control without trace leaving command > "backtrace" useless. > I am still trying to figure out how. I will post it as soon as I > have it. > I am unable to get useful result from gdb: (gdb) run [Here the program stops at cppcms::service::run()] [Find the running process id in another terminal.] (gdb) attach 5343 [A lot messages appear here] [Type command "kill -HUP 5343" in another terminal] (gdb) c Continuing. Program received signal SIGHUP. Hangup. 0xb7fdfce2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) Continuing. Cannot get thread event message: debugger service failed (gdb) Continuing. Cannot execute this command while the selected thread is running. ---- This is the related ouput from valgrind: ==6206== Invalid read of size 4 ==6206== at 0x462105E: pthread_join (pthread_join.c:47) ==6206== by 0x4121897: booster::thread::join() (pthread.cpp:85) ==6206== by 0x8049799: main (t.cpp:54) ==6206== Address 0x6821ba8 is not stack'd, malloc'd or ==(recently) free'd ==6206== ==6206== ==6206== Process terminating with default action of signal 11 (SIGSEGV) ==6206== Access not within mapped region at address 0x6821BA8 ==6206== at 0x462105E: pthread_join (pthread_join.c:47) ==6206== by 0x4121897: booster::thread::join() (pthread.cpp:85) ==6206== by 0x8049799: main (t.cpp:54) I seem to have encountered big trouble! How can it be pthread_join that is buggy? Any thought? Meanwhile, I am going to run this program in different machine to find more... Regards, CN -- http://www.fastmail.com - IMAP accessible web-mail |
|
From: CN <cn...@fa...> - 2016-05-09 16:16:43
|
On Mon, May 9, 2016, at 11:35 PM, CN wrote: > I seem to have encountered big trouble! How can it be pthread_join > that is buggy? > Any thought? > Meanwhile, I am going to run this program in different machine to > find more... This program also causes segfault in libthread-2.19.so running in different machine with different architecture (AMD64) and newer version of Linux. -- http://www.fastmail.com - The way an email service should be |
|
From: Artyom B. <art...@gm...> - 2016-05-10 05:43:52
|
Ok I got what is the problem: Few things: I've run your code and it indeed crashes **when it runs as daemon using its internal tool** I still don't know why exactly it crashes but I assume it is related to forking. Note that threads do not go well through forking (that is required to create a daemon), actually they all become suspended and you need to wake them up - but in general it is very bad practice. IF you want to run your threads AND use daemonization services (regarding restarting of the process) you need to start your threads in cppcms::service::after_fork callback - otherwise they'll be suspended after fork. On the side note: I think cppcms needs something like daemonize that can be called prior to service::run().... something to add to feature requests. Additional problem currently unsolved: Essentially cppcms service daemonization is intended to use when cppcms::service is master loop and responsible on the application life time. For example it can even start several independent processes in prefork mode. See when you can service::run() it performs daemonization if it isn't already a daemon and in service::~service() it removes the lock file. So it is problematic to start/stop the service several times (but I think this is at least fixable) If you want to restart the service on your own - which is very legitimate requirement, for example for creating web interfaces for existing services than you can't use the internal daemonization tool. You need to fork-off and run as daemon before you start your threads & run the service. Regards, Artyom |
|
From: CN <cn...@fa...> - 2016-05-10 06:47:48
|
Dear Artyom,
Thanks for taking time answering!
The program no longer causes segmentation fault after signals arrive if
parameter "daemon.enable" in file "t.js" is set to "false" and launched
by this shell script:
=========
#!/bin/sh
### BEGIN INIT INFO
# Provides: t
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: My Program
# Description: Test signals.
### END INIT INFO
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/tmp/a.out
NAME=t
CONFIGFILE="-c /tmp/t.js"
DESC="My Program"
SCRIPTNAME=/etc/init.d/$NAME
PIDFILE=/tmp/t.pid
test -x $DAEMON || exit 0
. /lib/lsb/init-functions
case "$1" in
start)
log_daemon_msg "Starting $DESC" $NAME
start-stop-daemon --start --oknodo --quiet --pidfile $PIDFILE
--exec $DAEMON -b -m -- $CONFIGFILE
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping $DESC" $NAME
start-stop-daemon --stop --retry TERM/10 --quiet --pidfile
$PIDFILE --exec $DAEMON --remove-pidfile
log_end_msg $?
;;
reload|force-reload)
log_daemon_msg "Reloading $DESC" $NAME
start-stop-daemon --stop --signal HUP --retry 10 --quiet
--pidfile $PIDFILE --exec $DAEMON
log_end_msg $?
;;
restart)
log_daemon_msg "Restarting $DESC" $NAME
$0 stop
$0 start
;;
status)
status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" && exit 0 || exit
$?
;;
*)
echo "Usage: $SCRIPTNAME
{start|stop|restart|reload|force-reload|status}" >&2
exit 1
;;
esac
exit 0
=========
Please note the "-b -m" options under "start)", in case this script is
*generally correct* and also useful to anyone in this community.
Best regards,
CN
On Tue, May 10, 2016, at 01:43 PM, Artyom Beilis wrote:
> Ok I got what is the problem:
>
> Few things:
>
> I've run your code and it indeed crashes **when it runs as daemon
> using its internal tool**
> I still don't know why exactly it crashes but I assume it is related to
> forking.
>
> Note that threads do not go well through forking (that is required to
> create a daemon), actually they all become suspended and you need to
> wake them up - but in general it is very bad practice.
> IF you want to run your threads AND use daemonization services
> (regarding restarting of the process) you need to start your threads
> in cppcms::service::after_fork callback - otherwise
> they'll be suspended after fork.
>
> On the side note: I think cppcms needs something like daemonize that
> can be called prior to service::run().... something to add to feature
> requests.
>
> Additional problem currently unsolved:
>
> Essentially cppcms service daemonization is intended to use when
> cppcms::service is master loop and responsible on the application life
> time. For example it can even start several independent processes in
> prefork mode.
> See when you can service::run() it performs daemonization if it isn't
> already a daemon and in service::~service() it removes the lock file.
> So it is problematic to start/stop the service several times (but I
> think this is at least fixable)
>
> If you want to restart the service on your own - which is very
> legitimate requirement, for example for creating web interfaces for
> existing services than you can't use the internal daemonization tool.
> You need to fork-off and run as daemon before you start your threads &
> run the service.
>
> Regards,
>
> Artyom
--
http://www.fastmail.com - Same, same, but different...
|
|
From: CN <cn...@fa...> - 2016-05-10 09:17:24
|
> The program no longer causes segmentation fault after signals arrive if
> parameter "daemon.enable" in file "t.js" is set to "false" and launched
> by this shell script:
>
> =========
> #!/bin/sh
> ### BEGIN INIT INFO
> # Provides: t
> # Default-Start: 2 3 4 5
> # Default-Stop: 0 1 6
> # Short-Description: My Program
> # Description: Test signals.
> ### END INIT INFO
>
>
> PATH=/sbin:/bin:/usr/sbin:/usr/bin
> DAEMON=/tmp/a.out
> NAME=t
> CONFIGFILE="-c /tmp/t.js"
> DESC="My Program"
> SCRIPTNAME=/etc/init.d/$NAME
> PIDFILE=/tmp/t.pid
>
> test -x $DAEMON || exit 0
>
> . /lib/lsb/init-functions
>
> case "$1" in
> start)
> log_daemon_msg "Starting $DESC" $NAME
> start-stop-daemon --start --oknodo --quiet --pidfile $PIDFILE
> --exec $DAEMON -b -m -- $CONFIGFILE
> log_end_msg $?
> ;;
> stop)
> log_daemon_msg "Stopping $DESC" $NAME
> start-stop-daemon --stop --retry TERM/10 --quiet --pidfile
> $PIDFILE --exec $DAEMON --remove-pidfile
> log_end_msg $?
> ;;
> reload|force-reload)
> log_daemon_msg "Reloading $DESC" $NAME
> start-stop-daemon --stop --signal HUP --retry 10 --quiet
> --pidfile $PIDFILE --exec $DAEMON
> log_end_msg $?
> ;;
> restart)
> log_daemon_msg "Restarting $DESC" $NAME
> $0 stop
> $0 start
> ;;
> status)
> status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" && exit 0 || exit
> $?
> ;;
> *)
> echo "Usage: $SCRIPTNAME
> {start|stop|restart|reload|force-reload|status}" >&2
> exit 1
> ;;
> esac
>
> exit 0
>
> =========
>
> Please note the "-b -m" options under "start)", in case this script is
> *generally correct* and also useful to anyone in this community.
I do not understand the effects coming from "reload|force-reload)" in
the shell script:
unknown symptom (1):
reload|force-reload)
start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE
--exec $DAEMON
These are the commands I issued:
/tmp/t.sh start
/tmp/t.sh reload
Here is its log:
May 10 16:55:49 host t: ==1==: (t.cpp:51)
May 10 16:56:20 host t: begin handler: (t.cpp:12)
May 10 16:56:20 host t: end handler: (t.cpp:15)
May 10 16:56:20 host t: ==2==: (t.cpp:53)
May 10 16:56:20 host t: ==3==: (t.cpp:55)
May 10 16:56:20 host t: ==4==: (t.cpp:58)
May 10 16:56:20 host t: ==1==: (t.cpp:51)
May 10 16:56:20 host t: ==1==: (t.cpp:51)
My understanding is that since parameter "daemon.enable" in "t.js" is
set to "false", process forking is then not involved. Why t.cpp:51
appears twice?
unknown symptom (2):
After "--retry 5" is added to make the script look so:
reload|force-reload)
start-stop-daemon --stop --signal HUP --retry 5 --quiet
--pidfile $PIDFILE --exec $DAEMON
, command "/tmp/t.sh reload" does not return until 5 seconds pass.
Besides, there is no process running for "a.out" after the command
returns.
Why is that?
Best regards,
CN
--
http://www.fastmail.com - mmm... Fastmail...
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X