My question is just that. Is there a command in Xcode that uses a process other than fork?
There are other APIs to launch applications, but they all ultimately rely on fork()/exec(). There's no other way on UNIX to start a new process from userland than forking an existing process. You can install another task as a launchd job, then launch it by satisfying its start conditions - that doesn't directly use fork() (though of course it causes launchd to fork).
Related
I have my own embedded Linux system on PocketBeagle board. I have developed a simple gpio application in C that issues an on/off command to one of the pins of the connectors of the board. The application is called gpio_aa6 and located at /root.
The first challenge was to find a way to launch my application automatically after booting the board. I found two ways to do that; the first was to add an entry to etc/rcS directory. This entry is a simple script file that launches my application. The second way was to edit /etc/inittab file and add an entry to that file (::respawn:/root/gpio_aa6). In both these ways my application was launched successfully: but I am still not sure if this is the right way to launch my application automatically.
Then I came to the second challenge, how can I stop my running application, as the respawn re-launches the application if it's terminated?
I am communicating with the board in two ways; via a serial communication (using screen terminal) and via web sever (root#192.168.42.2). I have tried to use Ctrl+C, Ctrl+Z, Ctrl+\, but couldn't stop the program from being continue running. Then I used command "killall" with killsignals -9 or -15, it seems that the program is interrupted but it's launched again directly after that.
My application is to run infinitely, but I need to stop it sometimes to update it and re-launch it again.
Is there any suggestion how to overcome this problem?
Thanks.
Both solutions you have used are correct. I personally prefer the option of adding an init script to /etc/init.d though.
I believe the behavior that you observe that you apparently can't kill the program is because you are starting your program from inittab, with the respawn keyword, which precisely tells the init program to restart your application when it exits. If you actually check the PID of your application, you will see that it changes everytime you kill it.
Therefore, I would recommend you to use an init script instead, with which you can implement start and stop actions. See ./package/lldpd/S60lldpd for a basic example in Buildroot.
I am writing a normal, innocent C++/Qt program in Windows 7/MinGW.
It is the second time in two days that after closing the program the executable remains among the active processes, and there is no way to kill it (I try both from the command line and from Windows Task Manager).
One inconvenience is that I cannot re-link my code, because the binary code cannot be overwritten, being running.
The reason is that the executable was running under the control of the debugger, and this protected the process against any attempt to kill it. Stopping it through the debugger has been successful.
I did not know that the debugger could shield a process from any external attempt to kill it so well...
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.
For example if App-A tries to installed App-B. Is there any way for App-A to know when App-B is finished installing and can be run?
update
to be specific I am trying to install ChromeSetup.exe on windows using AIR 2.
update 2
Good information guys, after reviewing all your answers is seems like I should run the installer with the -ms argument so it installs silently. Then listen for the NativeProcessExitEvent.Exit event. I will try that and see if it works.
It Depends (TM).
Most of the time, the installer for an app is a single executable - so you can launch it and wait until execution comes back to you, but I've seen some unholy messes like "downloader unpacker -> installer downloader -> installer unpacker -> installer" which launched the next executable in the background. Try it with the specific apps you're after and see if the simple system() method works. If not, you'd have to monitor the process list to see if the other installer is done yet.
Installers generally generate logs that give output for events during install. It may be possible in your case to search for a generated log file from App-B installer and look at it to gauge success or failure. But if you're just running the App-B installer as a command line executable you could just invoke it synchronously and wait on it to complete.
Typically the installer would just exit and the system() call would return.
Or you can script installers and their own scripting language would control the sequence.
Generally speaking, the installer will run as a process, and you can wait for that process to finish. Under POSIX you can use spawn, and quite a few other systems provide the same or least something quite similar.
If I understand well, you are writing an installer and you want to install Chrome as a pre-requisite or something like that?
If so, you can run the installer silently with the "-ms" parameter according to what I could see on the Web.
Then how to call it depends on which programming language or system you're writing the installer on: for example, from a batch file, you would do
start /wait "" GoogleSetup.exe -ms
but how to call a separate process and wait for its termination depends on the development language and system you're using. Most of them offer functions to launch external processes and wait for their termination almost effortlessly.
My problem is not the best scenario for fork(). However, this is the best func I can get.
I am working on a Firefox plugin on Mac OSX. To make it robust, I need to create a new process to run my plugin. The problem is, when I forked a new process, much like this:
if (fork() == 0) exit(other_main());
However, since the state is not cleaned, I cannot properly initialized my new process (call NSApplicationLoad etc.). Any ideas? BTW, I certainly don't want create a new binary and exec it.
In general, you need to exec() after fork() on Mac OS X.
From the fork(2) man page:
There are limits to what you can do in the child process. To be totally safe you should restrict your-self to only executing async-signal safe operations until such time as one of the exec functions is called. All APIs, including global data symbols, in any framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe. If you need to use these frameworks in the child process, you must exec. In this situation it is reasonable to exec yourself.
TN2083 also comments on this subject:
Many Mac OS X frameworks do not work reliably if you call fork but do not call exec. The only exception is the System framework and, even there, the POSIX standard places severe constraints on what you can do between a fork and an exec.
IMPORTANT: In fact, in Mac OS X 10.5 and later, Core Foundation will detect this situation and print the warning message shown in Listing 13.
Listing 13: Core Foundation complaining about fork-without-exec
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
fork without exec is basically entirely unsafe on OSX. You will end up with stale mach ports for example.
I'm writing the FreeWRL plugin for Firefox (Linux at the moment, Mac & Windows soon).
http://freewrl.sourceforge.net/
It's based on fork+exec to launch FreeWRL and swallow its window into Firefox.
You'll have to use a pipe to correctly handle the possible failure of fork+exec or the failure of your child process :
How to handle execvp(...) errors after fork()?
Cheers,
C