li230-248 : Nov 19 =11:14:05 : www-data : parse error in /etc/sudoers.d/webdna near line 1 ; =TTY=3Dunknown ; PWD=3D/var/www/site/site-root ;
On 19 Nov. 2016, at 08:47, christophe.billiottet@webdna.us wrote:I =would suggest to create a new file called /etc/sudoers.d/webdna , and =put this inside:
Defaults = !authenticate
%www-data ALL=3D/etc/init.d/WebCatalogCtl
Then chmod 0440 /etc/sudoers.d/webdna . Use the follow WebDNA =code with it:
[SHELL]sudo /etc/init.d/WebCatalogCtl =restart &[/SHELL]WebdnaMonitor utilizes a =file that contains the process ID of the running engine
When WebCatalog is started with =the -m argument, it does not create the WebCatalog.pid file. Instead the =WebDNAMonitor creates it, and puts its own PID in it:
# cat /usr/lib/cgi-bin/WebCatalogEngine/WebCatalog.pid
15568
# ps aux|grep 15568
root = 15568 0.0 0.0 4288 = 608 pts/17 S 12:28 = 0:00 /usr/lib/cgi-bin//WebCatalogEngine/WebDNAMonitor
The bug is that the WebCatalog.pid file is =deleted by WebCatalog on a clean exit regardless of whether or not it =created it. It should not do this if -m was passed.if the =running engine is killed (i.e. Not usually the best way to stop any =application)
This is how =WebCatalogCtl and WebDNAMonitor stop WebCatalog. It sends it a INT =signal, which goes through the same handler as TERM so there is no =difference.
What you want to avoid is =sending SIGKILL (aka signal 9), that is closest to force-quitting an =application from the OSX GUI. The application isn't able to run any =signal handlers and do a graceful shutdown, as signal 9 cannot be =caught.
"killall" will send a TERM signal =by default, which WebCatalog will catch and use to gracefully shutdown =by running CleanExit(0).there will likely end up =being a mismatch between the monitor and the engine. Then what will =happen is rogue instances of the engine.
Yeah you are right. Since WebCatalog deletes the =WebCatalog.pid file when it exits, the WebCatalogCtl script stops =working.
- chrisOn Nov =18, 2016, at 21:03, Donovan Brooke <dbrooke@euca.us> wrote:
WebdnaMonitor utilizes a file that contains the process ID of =the running engine.. if the running engine is killed (i.e. Not usually =the best way to stop any application), there will likely end up being a =mismatch between the monitor and the engine. Then what will happen is =rogue instances of the engine.
A better =idea to give people the power to control WebDNA and restarts of the =server would be to build a separate and optional WebDNA server control =app perhaps, that utilizes root capabilities... but there is already an =app for that... called shell, or terminal.
D.= Brooke Mobile
---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@webdna.us>.
To unsubscribe, E-mail =to: <talk-leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug= Reporting: support@webdna.us
|
li230-248 : Nov 19 =11:14:05 : www-data : parse error in /etc/sudoers.d/webdna near line 1 ; =TTY=3Dunknown ; PWD=3D/var/www/site/site-root ;
On 19 Nov. 2016, at 08:47, christophe.billiottet@webdna.us wrote:I =would suggest to create a new file called /etc/sudoers.d/webdna , and =put this inside:
Defaults = !authenticate
%www-data ALL=3D/etc/init.d/WebCatalogCtl
Then chmod 0440 /etc/sudoers.d/webdna . Use the follow WebDNA =code with it:
[shell]sudo /etc/init.d/WebCatalogCtl =restart &[/SHELL]WebdnaMonitor utilizes a =file that contains the process ID of the running engine
When WebCatalog is started with =the -m argument, it does not create the WebCatalog.pid file. Instead the =WebDNAMonitor creates it, and puts its own PID in it:
# cat /usr/lib/cgi-bin/WebCatalogEngine/WebCatalog.pid
15568
# ps aux|grep 15568
root = 15568 0.0 0.0 4288 = 608 pts/17 S 12:28 = 0:00 /usr/lib/cgi-bin//WebCatalogEngine/WebDNAMonitor
The bug is that the WebCatalog.pid file is =deleted by WebCatalog on a clean exit regardless of whether or not it =created it. It should not do this if -m was passed.if the =running engine is killed (i.e. Not usually the best way to stop any =application)
This is how =WebCatalogCtl and WebDNAMonitor stop WebCatalog. It sends it a INT =signal, which goes through the same handler as TERM so there is no =difference.
What you want to avoid is =sending SIGKILL (aka signal 9), that is closest to force-quitting an =application from the OSX GUI. The application isn't able to run any =signal handlers and do a graceful shutdown, as signal 9 cannot be =caught.
"killall" will send a TERM signal =by default, which WebCatalog will catch and use to gracefully shutdown =by running CleanExit(0).there will likely end up =being a mismatch between the monitor and the engine. Then what will =happen is rogue instances of the engine.
Yeah you are right. Since WebCatalog deletes the =WebCatalog.pid file when it exits, the WebCatalogCtl script stops =working.
- chrisOn Nov =18, 2016, at 21:03, Donovan Brooke <dbrooke@euca.us> wrote:
WebdnaMonitor utilizes a file that contains the process ID of =the running engine.. if the running engine is killed (i.e. Not usually =the best way to stop any application), there will likely end up being a =mismatch between the monitor and the engine. Then what will happen is =rogue instances of the engine.
A better =idea to give people the power to control WebDNA and restarts of the =server would be to build a separate and optional WebDNA server control =app perhaps, that utilizes root capabilities... but there is already an =app for that... called shell, or terminal.
D.= Brooke Mobile
---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@webdna.us>.
To unsubscribe, E-mail =to: <talk-leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug= Reporting: support@webdna.us
DOWNLOAD WEBDNA NOW!
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...