I'm to write a script which will grab all the text from a file (/tmp/pidfile.txt) which is just a pid number, and then store that as a variable (say pidvar) or something and execute the following:
kill -2 pidvar
Seems simple enough I just don't know how to grab the pid from the .txt file. I have python installed if this helps. Trying to make it easier to kill uWSGI, any suggestions on an alternative would be welcome.
Thanks in advance for any help.
The literal answer to your question (using a bash extension to be slightly more efficient) would be
kill -2 "$(</tmp/pidfile.txt)"
...or, to be compatible with POSIX sh but slightly less efficient...
kill -2 "$(cat /tmp/pidfile.txt)"
...but don't do it either of those ways.
pidfiles are prone to race conditions, whereas process-tree-based supervision systems can guarantee that they only ever deliver a signal to the correct process.
runit, daemontools, Upstart, systemd, and many other alternatives are available which will guarantee that there's no risk of sending a signal to the wrong process based on stale data. CentOS is probably the last major operating system that doesn't ship with one of these (though future versions will almost certainly use systemd), but they're available as third-party packages -- and if you want your system to be reliable (detecting unexpected failures and restarting services as soon as they go down, for instance, without having to do it with your own code), you should be using one of them.
For instance, with systemd:
systemctl kill -s SIGINT uwsgi.service
...or, with runit:
sv interrupt uwsgi
...whereas with upstart, you can configure a completely arbitrary restart command to be triggered on initctl reload uwsgi.
For general best-practices documentation on using shell scripts for process management, see the appropriate page on the wooledge.org wiki, maintained by irc.freenode.org's #bash channel.
It is generally easier to ask uwsgi to kill itself. You can do this by using the "master-fifo" option in your config, and then send a "q" to the fifo. This is described here: http://uwsgi-docs.readthedocs.org/en/latest/MasterFIFO.html.
Related
You can force garbage collection in java using jcmd <pid> GC.run as shown at this StackOverflow link: How do you Force Garbage Collection from the Shell? . I understand that forcing garbage collection is frowned upon, but I was wondering if there was a similar command for golang. Like this question, I would like know if garbage collection can be done from the command line instead of calling Runtime.GC().
It is not possible to run the GC from the command line. Think that your program is a standalone compiled version.
If you need to "force" the GC to run at certain times, I think you could use two formulas:
In your app, check the existence of a file with inotify. When the file appears, you run the GC
In your app, wait for a signal from the operating system (Linux), such as SIGUSR1, and run the GC. Then you send the signal from the console using:
kill -10 pid
Where pid is the identifier of the running program as it appears in ps -aux
For years we've had a process-monitoring/control script as part of our application. The default behavior of the script is to daemonize itself. Often the script is launched, of necessity, by non-privileged users. For reasons I'll not elaborate, we need to keep both the script and this behavior.
On OSX systems, we have traditionally had the script restart itself in the background via the /usr/libexec/StartupItemContext launch script provided by Apple. This puts our process in the Mach StartupItem bootstrap context rather than the login bootstrap context. This is necessary because without that context switch, if and when the user logs out, which is also often necessary, the script loses access to directory services, getpwuid(), DNS services, etc. The original internal lines that daemonized the script looked essentially like this (in perl):
my $cmd = "/usr/libexec/StartupItemContext myscript #Commandline > logs/startup 2>&1" ;
system( "$cmd &") ;
exit 0 ;
When OSX Yosemite came out, that StartupItemContext script disappeared, so we switched to direct invocation of launchctl:
my $cmd = "/usr/launchctl bsexec / myscript #Commandline > logs/startup 2>&1" ;
system( "$cmd &") ;
exit 0 ;
With the recent OSX 10.10.3 upgrade, however, the bsexec subcommand of launchctl suddenly requires root privileges:
% launchctl bsexec
This subcommand requires root privileges: bsexec
%
This creates for us the showstopper problem that non-privileged users can no longer get our monitoring/control script to daemonize itself.
It seems that Glassfish has encountered this problem and addressed it with a patch that replaces
/bin/launchctl bsexec /
with
nohup
This may work for the Glassfish implementation, however I don't think for us. Notwithstanding the fact that I don't understand it -- i.e. why a simple blocking of SIGHUP would prevent a process in decommissioned login bootstrap context from losing services -- it also doesn't seem to work in our tests for all system services we need.
What is the new, canonical way to daemonize a process on OSX starting from a non-privileged, Mach "login" bootstrap context, without losing access to critical system services like DNS etc. when the user logs out?
"from a non-privileged, Mach "login" bootstrap context" unfortunately is very unlikely to have a "canonical way." The only canonical way is to launch services on demand via launchd. Even "bsexec" is barely supported and hardly documented. In my experience, it isn't possible to keep up with OS X changes and never redesign your launch systems. I redesign the daemon system about every other release because Apple breaks it, and they're going to keep breaking it. The only answer is to keep trying to make your requirements simpler. But pretty much any process that wants to run all the time, rather than on demand, is in direct violation of Apple's stated intent, so it's going to tend to break.
The solution given by Apple is to create a LaunchDaemon and assign it a UserName in your launchd plist. You must start privileged, and then switch to the user (and it needs to be a fixed user, not "the logged in user" since that would be a LaunchAgent). You can't upgrade your access this way. You must not daemonize yourself (again, the canonical answer is: don't do that. See the launchd.plist man page.)
I suspect the Glassfish nohup solution is just a dodge that doesn't actually put them in the Mach context. They're just trying to avoid being killed when the parent shell exits. That probably won't help you.
In my experience, the most robust solutions are multi-part. You wind up with one piece that is run as a system LaunchDaemon (with KeepAlive), and another piece that is a user LaunchAgent, and you let them communicate over IPC so that you can access the context you need for each activity you need to do. Yes, this is typically much more complicated to implement. Simpler solutions tend not to work.
And of course you have to constantly ask yourself "is there any way I could achieve this by doing things the way Apple wants me to." That means XPC is strongly preferred, followed by on-demand LaunchDaemons and LaunchAgents. If you build your system to use XPC components, you'll likely survive more OS X upgrades. Any work around you figure out that doesn't use these pieces will probably have to be fixed again in 10.11.
Okay, so I'm working with a shell script that needs to be as portable as possible, and I want to make sure I can cleanly tidy up any child-processes using a trap command.
Now, on more recent platforms the jobs -p command can be used to get a list of child process ids, suitable for throwing straight into a kill command to tidy things up without any fuss.
However, some environments don't have this. To work around this I'm using a variable into which I throw process IDs, but it's messy, and a typo could result in some or all child processes not being killed when they should be.
So, in the absence of the jobs command, what alternatives are there? Or put another way, what is the most compatible method to kill all child-processes of a script?
To give you an idea of potential limitations; the most basic system I need to work with has no pgrep, and only a basic version of ps only supporting the -w flag. It does have access to special files under /proc/$$/ but I'm not sure what to do with those (do any of them even list child processes?). This has been a big part of the difficulty, as many similar questions list solutions using tools I don't have access to, I just love compatibility issues =)
You can get the child pid using `!`
$!
I'm developing an app. The operating system I'm using is linux. I need to run if possible a ruby script on the file created in the directory. I need to keep this script always running. The first thing I thought about is inotify:
The inotify API provides a mechanism for monitoring file system events. Inotify can be used to monitor individual files, or to monitor directories.
It's exactly what I need, then I found "rb-inotify", a wrapper fir inotify.
Do you think there is a better way of doing what I need than using inotify? Also, I really don't understand the way that I have to use rb-inotify.
I just create, for example, a rb file with:
notifier = INotify::Notifier.new
notifier.watch("directory/to/check",:create) do |event|
#do task with event.name file
end
notifier.run
Then I just ruby myRBNotifier.rb, and it will stay looping for ever. How do I stop it? Any idea? Is this a good approach?
I'd recommend looking at god. It's designed for this sort of task, and makes it pretty easy to build a monitoring system for background and daemon apps.
As for the main code itself, inotify isn't cross-platform, so if you have a possibility you'll need to run on Windows or Mac OS then you'll need a different solution. It's not too hard to write a little piece of code that checks your target directory periodically for a change. If you need to know what changed, read and cache the directory entries then compare them the next time your code runs. Use sleep between runs to wait some period of time before looping.
The old-school method of doing similar things is to use cron to fire off a job at regular intervals. That job can be your script that checks whether the file list changed by comparing it to the cached version, then acting as needed if something is different.
Just run your script in the background with
ruby myRBNotifier.rb &
When you need to stop it, find the process id and use kill on it:
ps ux
kill [whatever pid your process gets from the OS]
Does that answer your question?
If you're running on a mac/unix machine, look at the launchctl man page. You can set up a process to run and execute a ruby script whenever a file changes. It's highly configurable.
With respect to this excellent post:
What's the difference between nohup and a daemon?
I would like to ask the following:
After launching an application from my terminal, the application keeps running either in the background or the foreground and the only thing I can do to interact with it is by sending it signals from my terminal (given that stdin is still in place).
However, after a daemon process is launched, I realized that it can be controlled with other means like querying it or restarting it (arch way):
# /etc/rc.d/daemon-name {start|stop|restart|status|...}
Could someone explain to me if that feature is built-into the general "daemon framework" and applies to every daemon process as a special feature or is it just a provision that processes designed to run as a daemon will have to handle internally?
And to add more to the matter, how on earth are we able to "control" daemons from the terminal using their name (i.e. sambad stop) while applications always have to be referred using their name (i.e. kill -9 1234)?
Thank you in advance!
# /etc/rc.d/daemon-name {start|stop|restart|status|...}
it is not a querying to the daemons directly. It is launching scripts by standart interface and these scripts in turn operate with daemon process by PID and signals. This scripts are creating during installation process of daemons-programs.