In erlang it is possible to create a pid which does not correspond to a process. An example using this can be found here in Learn You Some Erlang.
pid(0,250,0).
Is there a way to do the same in elixir?
The closes I have got at the moment is to create a process that immediately terminates and use that pid.
fake_pid = Process.spawn(fn -> end)
This seams like a bit of a hack, and I am unsure if there might be some slight differences between a never created pid and a dead pid.
You can use the pid/3 Erlang function directly in Elixir:
:c.pid(0,250,0)
Also - just a note from the Erlang docs:
Converts X, Y, Z to the pid <X.Y.Z>. This function should only be used when debugging.
For your purposes, I would use self() from the test code. That would resolve to the process running the current test case.
If you for some reason need to test another pid, your way of using Process.spawn/1 is quite nice, because it ensures the pid is not taken (and doesn't point to something vital in the system) and that it is already dead (or alive, if you keep it alive for the duration of the test).
The Erlang :c.pid/3 or the new Elixir 1.1 IEx.Helpers.pid/3 are only meant to be convenience functions to be used in the shell.
Related
My goal is to write to a file (that the user whenever the user launches an application, such as FireFox) and timestamp the event.
The tricky part is having to do this from the kernel (or a module loaded onto the kernel).
From the research I've done so far (sources listed below), the execve system call seemed the most viable. As it had the filename of the process it was handling which seemed like gold at the time, but I quickly learned that it wasn't as useful as I thought since this system call isn't limited to user-related operations.
So then I thought of using ps -ef as it listed all the current running processes and I would just have to filter through which ones were applications opened by the user.
But the issue with that method is that I would have to poll every X seconds so, it has the potential to miss something if the user launched and closed an application within the time that I didn't call ps -ef.
I've also realized that writing to a file would be a challenge as well, since you don't have access to the standard library from the kernel. So my guess for that would be making use of proc somehow to allow the user to actually access the information that I'm trying to log.
Basically I'm running out of leads and I'd greatly appreciate it if anyone could point me in the right direction.
Thanks.
Sources:
http://tldp.org/LDP/lkmpg/2.6/html/x978.html (not very recent)
https://0xax.gitbooks.io/linux-insides/content/SysCall/syscall-4.html
First, writing to a file or reading a real file from the kernel is a bad idea which is not used in the kernel. There is of course VFS files, like /sys/fs or /proc, but this is a special case and this is allowed.
See this article in Linux Journal,
"Driving Me Nuts - Things You Never Should Do in the Kernel" by Greg Kroach-Hrtman
http://www.linuxjournal.com/article/8110
Every new process that is created in Linux, adds an entry under /proc,
as /proc/pidNum, where pidNum is the Process ID of the new process.
You can find out the name of the new application which was invoked simply by
cat /proc/pidNum/cmdline.
So for example, if your crond daemon has pid 1336, then
$cat /proc/1336/cmdline
will give
cron
And there are ways to monitor adding entries to a folder in Linux.
So I am trying to keep my Node server on a embedded computer running when it is out in the field. This lead me to leveraging inittab's respawn action. Here is the file I added to inittab:
node:5:respawn:node /path/to/node/files &
I know for a fact that when I startup this node application from command line, it does not get to the bottom of the main body and console.log "done" until a good 2-3 seconds after I issue the command.
So I feel like in that 2-3 second window the OS just keeps firing off respawns of the node app. I see in the error logs too in fact that the kernel ends up killing off a bunch of node processes because its running out of memory and stuff... plus I do get the 'node' process respawning too fast will suspend for 5 minutes message too.
I tried wrapping this in a script, dint work. I know I can use crontab but thats every minute... am I doing something wrong? or should I have a different approach all together?
Any and all advice is welcome!
TIA
Surely too late for you, but in case someone else finds such a problem: try removing the & from the command invocation.
What happens is that when the command goes to the background (thanks to the &), the parent (init) sees that it exited, and respawns it. Result: a storm of new instantations of your command.
Worse, you mention embedded, so I guess you are using busybox, whose init won't rate-limit the respawning - as would other implementations. So the respawning will only end when the system is out of memory.
inittab is overkill for this. I found out what I need is a process monitor. I found one that is lightweight and effective; it has some good reports of working great out in the field. http://en.wikipedia.org/wiki/Process_control_daemon
Using this would entail configuring this daemon to start and monitor your Node.js application for you.
That is a solution that works from the OS side.
Another way to do it is as follows. So if you are trying to keep Node.js running like I was, there are several modules written meant to keep other Node.js apps running. To mention a couple there are forever and respawn. I chose to use respawn.
This method entails starting one app written in Node.js that uses the respawn module to start and monitor the actual Node.js app you were interested in keeping running anyway.
Of course the downside of this is that if the Node.js engine (V8) goes down altogether then both your monitoring and monitored process will go down with it :-(. But its better than nothing!
PCD would be the ideal option. It would go down probably only if the OS goes down, and if the OS goes down then hope fully one has a watchdog in place to reboot the device/hardware.
Niko
In Linux, I want a process to be assigned with higher priority than usual. I.e. when a process starts I want it's priority to be set to higher value. I want this to be done implicitly, i.e when the process starts (eg.:on a double click).
For this will I have to change the kernel code (sched.c)?
And are there any tools or packages using which I can see how exactly a process starts and how the priorities are assigned?
Would ptrace ( http://linux.die.net/man/2/ptrace) and strace ( http://linux.die.net/man/1/strace) help me with this?
Assuming you don't want to hack the actual application itself you can always create a custom desktop file which wraps the command with "nice" which will modify the niceness (priority) of the command you'll run.
For example, create a ~/.local/share/applications/myfastapp.desktop which looks like:
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Exec=nice -n -20 /usr/bin/myapp
Name=My App (niced)
Comment=Custom definition for myapp
Have the process call the set_priority() system call in main() to lower it's nice level and raise it's priority. See the man page for details: http://linux.die.net/man/2/setpriority
You can also mark the process as a real time process using sched_setscheduler() but that is a little bit more involved and probably an overkill for what you seek.
You 100% don't need to change the kernel for this :-)
I've found this question, but even when is close to what I need, is useless
Basically, I have an app that needs to do something when another process (of known name) is launched and/or terminated, but i don't have the PID, so i can't set a kqueue to look for it.
I could do a while for "ps aux | grep processtolook | grep -v grep" command, but that's my last resort.
Any ideas?
Look at this answer: Determine Process Info Programmatically in Darwin/OSX. The libproc.h header file has proc_listpids which will get you all the pids. You can then get the pid information in a loop and using proc_pidinfo and check the name. Looking at the top source as suggested there might also be worthwhile. (The current verson is here http://www.opensource.apple.com/source/top/top-67/.)
Unfortunately, this is an undocumented interface and subject to change at any time. Also, it isn't the quickest thing, since you have to loop over all the processes in the system. In general, this isn't a great way to do this.
A better way might be to write a new processtolook that simply invoked the old one which you can move or rename. It could then notify you of the process start and stop. Is that a possibility?
If the target process/program name which you want the PID is "processtolook" then you can use pidof command to get the PID of that running program.
pidof processtolook
have a look at the pidof manual. This is a part of sysvinit-tools package.
EDIT1:
Have a look at this code i found: http://programming-in-linux.blogspot.com/2008/03/get-process-id-by-name-in-c.html
This might help you get you the outline.
On BSD you can use kvm_openfiles and kvm_getprocs to implement what you want. I don't know if it's available on OSX. If you have a pgrep program, look how it's implemented (src/bin/pkill.c).
If I launched a shell script using AuthorizationExecuteWithPrivileges what would be the easiest way to kill the script and any other processes that it spawned.
Thanks
It's running as root, so you can't kill it from a regular-user process. You're going to have to ask it nicely to exit on its own.
Apple has sample code that uses stdout to pass the PID back to the caller.
Use the communications pipe that AuthorizationExecuteWithPrivileges() returns by reference in its last argument, FILE **communicationPipe, to send a message to the child process that asks it to take itself and its descendants out. It can then kill itself and all its descendants using kill(0, SIGINT), or, if more drastic measures are required, SIGKILL.
The message you use can be as simple as closing the file while the child waits for the file to close; at that point, it knows you're done talking to it and it's time to take itself out.
There are some caveats about the descendants that will actually receive this message, for which see the kill(2) manpage. The caveats mostly won't matter so long as the process you started via AEWP hasn't dropped privileges, though one implicit issue is that this approach won't work if any child processes have put themselves in a new process group.