Terminate child processes in OS X Sandbox - sandbox

I'm trying to bundle Apache in my sandboxed application. Starting it works but I'm finding some issues stopping it. By either directly calling 'kill' or using "apachectl -k stop" I keep receiving a "deny signal" sandbox error.
Is there any way of accomplishing what I'm trying? Are all signals denied?
I'm testing it in the latest version of OS X 10.8.

It is not possible to terminate other apps in sandbox, but you can use the SMLoginItemSetEnabled function, from Service Management framework, to start and stop other apps.
See Adding Login Items Using the Service Management Framework, if you want to use this method.

Related

Background service in ServiceStack

I've got an application w. AppHost (inside Startup.cs) and also a Configure.Db.cs file.
I want to run a background service (Timer based) to routinely do some things, in addition to serving services.
If I add the timer inside Apphost's Configure(), which is run before the Configure.Db, I get into a problem as the background service is dependent on the Db to be configured.
Edit: I just found that it is possible to specify order of Modular startup: https://docs.servicestack.net/modular-startup#modular-startup-prioritization which means I can force the Configure.db to run before Apphost.
Anyway, am I going about this wrong? Should I perhaps have a separate AppHost just for the background job?
I would recommend configuring a Background MQ Service for executing Services in the background.
You can look at how to do this with hangfire by adding the mix
x mix hangfire-postgres
This will allow you to add services that fire in the background on a cron schedule.
To make it work without a database you need to change the postgres provider to the in-memory provider: https://github.com/perrich/Hangfire.MemoryStorage

Is it possible to attach to a session that is being used by a service similar to the screen command?

I am running a game server as a service using systemctl to start and stop a script that runs the whole thing. I tried to modify the script to let me use a screen so I could attach to the process that the server is being run on, and issue commands. But so far I've not had much luck. Is it possible to attach to services that are running on a server?
This question belongs on the Unix/Linux StackExchange.
See e.g:
https://unix.stackexchange.com/questions/453998/systemd-connect-to-stdin-stdout-after-service-has-started
If you want to solve it via programming, you could consider writing a small web application as the interface instead of the console.
Not in systemd, but you can start the service using
screen -D -m yourservice
which will create a detached screen session that will wait for the process to exit (so systemd does not see the service terminating immediately if you use this in an ExecStart line). You can then attach to that session normally.

Remotely check on an app's status in pm2 from a website?

I'd like to check the status of an app registered with pm2 remotely such that other web-based monitoring services can give us a notification when something breaks.
Are there any options available to remotely check the status of a process in pm2 remotely? One possibility is to have a web script remotely eval() the pm2 status command and look for certain keywords, and make that script accessible on the web for the notification tool. This doesn't seem ideal, though, as we're using an eval command and maybe a regex of that output just to see what is going on.
Any advice?
I wrote a simple web interface for PM2.
You can simply start a websocket connection to /logs and get your application(s) stats updates such as status, uptime, cpu usage, memory usage, restarts in realtime.Feel free to use and contribute. Cheers!
https://github.com/doorbash/pm2-web
The best option is to use keymetrics. It's free to monitor upto 4 processes(great for development and side projects), easy to link an instance/server but quickly turns out to be very expensive when you scale up.
You could always try switching to other alternatives like upstart or pm2-gui.

What are the advantages and disadvantages of using the upstart script or forever script in a context of running node.js scripts ??

I am a node.js developer. I use Amazon ec2 to deploy my node.js apps.
I want to have my node.js service running permanently - restarted if it fails for any reason.
I came across 2 tools . Forever and Upstart
Is there any advantages of using one over the other ?
Is there any other tool which is better ?
Upstart is a system service controller, similar to SysV Init and will start/stop/restart essentially any service registered for it, Node.js-based or not, and it will also automatically start services on system start for you. But Upstart is essentially specific to Ubuntu, and Upstart-specific services won't run on other Linux distros.
Upstart has a SysV Init compatibility layer that you could target,instead, to maintain as broad of a compatibility layer as possible.
Forever is a Node.js application that monitors and restarts other Node.js applications as needed, and as defined by its configuration JSON. Lots of options and fine-grained control over your service without the effort that would be needed to duplicate it in a custom SysV Init script. However, Forever isn't a system service, so if the server is restarted, you'll have to manually start your forever scripts again.
Beyond that, if all you need is something that will restart your script if/when it crashes, and you don't care about it starting automatically on system start, all you need is a bash script as simple as:
#!/bin/bash
while true
do
node ./myScript.js
done
Just to correct a misleading statement in the accepted answer...it is not true that upstart is an Ubuntu-only technology. See:
https://serverfault.com/questions/291546/centos-6-and-upstart
http://searchenterpriselinux.techtarget.com/tip/RHEL-6-ditches-System-V-init-for-Upstart-What-Linux-admins-need-to-know
http://en.wikipedia.org/wiki/Upstart#Adoption
With that, I think it is a much more compelling solution.

Codeigniter CLI As Daemon

I am creating a queue system where I need a set of workers to run jobs. For the queue I am planning on using Amazon's SQS. For my workers I would like to run instances of Codeigniter because the core application will also use Codeigniter and I would like to share the models of the workers with that of the core application.
I see that it is possible to hit a controller method using CI's CLI (http://codeigniter.com/user_guide/general/cli.html). However, these workers should continually run, unless I kill them. I have looked into this article about setting up daemons using php: http://kevin.vanzonneveld.net/techblog/article/create_daemons_in_php/ This method requires that I use this class: https://github.com/kvz/system_daemon.
I am not sure if I should be calling and running System Daemon inside my controller in CI to spawn the entire CI instance as a daemon? Or is there a command-line approach where I can establish my call to the CI method as a daemon and then avoid using the 'System Daemon' class altogether? Any considerations I should be aware of? I have never created a running daemon, I have only used the cron tab to restart processes but that will not work in my case.
I dont know if anyone has daemonized properly codeigniter (I read that many had tried).
I had a similar situation with yours and I ended up using the System Daemon class which constantly checks SQS and then calling a CLI codeigniter via system() passing the message as a parameter.
My approach works for ~10 months without having any issues and serves ~30-40k messages per day.

Resources