I have a processes that is open and can retrieve variables but it is running in the back ground.
so i need to send a variable to the processes using the PID ?? is it possible in the command line to send a variable to a processes or to reconnect to a processes.
Interprocess communication is often handled by sockets, which are supported in PHP. So if you have control over both applications you can set up sockets to communicate between them.
*nix type shells
You can reconnect to a process by doing fg [job id] (which isn't the PID but you can find it by using the jobs command from terminal)
IPC
You can also send variables into programs if the program is configured to accept it. It may read it off of a pipe, file, or network socket
A program is also able to receive signals (sent with the kill -[signal]) if its simply waiting for a boolean message
For php, sending variables through these methods may involve serialization of the variables prior to transmission
Related
I have a long running PHP script that I'm attempting to convert into a systemd daemon.
While planing the daemon, I figured that I could simply send SITERM/SIGUSR1/SIGUSR2/etc. signals to restart/reload to my script when necessary using the kill command, but after reading through the systemd documentation, I've noticed this bit in the "ExecReload" section:
Note however that reloading a daemon by sending a signal (as with the example line above) is usually not a good choice, because this is an asynchronous operation and hence not suitable to order reloads of multiple services against each other. It is strongly recommended to set ExecReload= to a command that not only triggers a configuration reload of the daemon, but also synchronously waits for it to complete.
So, while my script will run just fine and the daemon itself will work properly using kill to signal various events (I don't have and most likely won't ever have another daemon that would depend on this one), the quote above got me thinking about alternatives of sending a synchronous message to the daemon.
The only thing that I could think of so far is:
Open a local socket in the daemon and listen for messages on it
Execute any supported action when receiving a message
Send an OK message back to the sender once the action is complete
Is there a better/recommended/optimal way of achieving this?
I'm working on a PHP platform which gives to developers some features like cron jobs, events and WebSocket communications, for do that I run three different daemons written in PHP, so admins can disable a specific feature. When I start them, after fork, the daemon starter saves the PID on my database and then includes the daemon PHP file. I need to allow developers to easily communicate with these daemons using the specific PHP class. I've seen that exist many different methods for communicate with processes, I've seen for example the proc_open function but it looks like must run a new command for communicate with it. I'm looking for something like PHP sockets but which allow me to open the socket to a PID and without using a port (if it's possible) for avoid conflicts with other daemons sockets. Which is the better way for do that with native instruments of PHP?
One more detail: these daemons may be able to manage pretty big load of connections, events are propagated also to clients through WebSocket or AJAX polling so event and WebSocket daemons communicate between them.
Using a process based approach and reusing the same process ( presumed from your explanation ), and communicating with it without using sockets would be difficult. If you are not that bothered about scalability beyond a server, then it would be fine. You will have to at least use a socket (network or unix), then make the process bind and listen on a random port, and save the port number or unix path in the database, along with the PID.
Another (old fashioned option) would be to make use of xinetd; make your daemons started and managed by xinetd. Here you are really rewiring the stdin and stdout using sockets, by out-sourcing it to xinetd daemon.
We've got a utility here that's using proc_open() to call ssh to run commands on a remote machine. However, in some cases we need to halt the command on the remote machine but proc_close() and proc_terminate() do not cause the desired signal to be sent through to the far side of the ssh connection. SSH will generally issue a SIGHUP to running programs when it is terminated, but we need to send a SIGINT to ssh which will forward it through to the program running on the remote end.
I've googled as much as I can, and there seem to be a number of pcntl functions for receiving signals, but I have not been able to find anything about sending signals via PHP, let alone anything related to proc_* functions.
You can sending signals via PHP :
posix_kill(posix_getpid(), SIGTERM);
From PHP.net:
http://www.php.net/manual/en/function.pfsockopen.php
I understand the gist of what this function accomplishes, but I'm still unclear as to whether this will accomplish what I'd like it to. Here is my scenario:
I have a large PHP application that is used by many users simultaneously. Within the application, I'm opening a TCP socket to a remote server for logging messages, etc... It was my hope that I might be able to leverage pfsockopen in order that many fewer connections would need to be opened. For example, user1 signs in - socket opens. User2 signs in, no socket is opened because he can "piggyback" on the socket opened by user1.
Is this possible?
pfsockopen will indeed keep the socket open when the script ends, allowing it to be re-used from a request to another, effectively opening less connections like you would expect. However, this is not compatible with all SAPIs.
The persistence occurs on a per-process basis. As such, pfsockopen ran in a CLI SAPI will close and re-open a socket at every execution, because the CLI script is executed in a single process that starts, open a socket and ends (closing the socket along with the process).
In CGI mode with one process per script, this is also true.
With the Apache SAPI, it depends what type of multi-processing module (MPM) is in use. mpm-prefork spawns a new process at every request, so it most likely doesn't support it. mpm-worker however, spawns threads, so it will probably work there. mpm-winnt is a Windows variant of a multi-threaded MPM, so it should work too.
The worst that can happen is that the call will be executed as a normal fsockopen call.
From PHP.net:
http://www.php.net/manual/en/function.pfsockopen.php
I understand the gist of what this function accomplishes, but I'm still unclear as to whether this will accomplish what I'd like it to. Here is my scenario:
I have a large PHP application that is used by many users simultaneously. Within the application, I'm opening a TCP socket to a remote server for logging messages, etc... It was my hope that I might be able to leverage pfsockopen in order that many fewer connections would need to be opened. For example, user1 signs in - socket opens. User2 signs in, no socket is opened because he can "piggyback" on the socket opened by user1.
Is this possible?
pfsockopen will indeed keep the socket open when the script ends, allowing it to be re-used from a request to another, effectively opening less connections like you would expect. However, this is not compatible with all SAPIs.
The persistence occurs on a per-process basis. As such, pfsockopen ran in a CLI SAPI will close and re-open a socket at every execution, because the CLI script is executed in a single process that starts, open a socket and ends (closing the socket along with the process).
In CGI mode with one process per script, this is also true.
With the Apache SAPI, it depends what type of multi-processing module (MPM) is in use. mpm-prefork spawns a new process at every request, so it most likely doesn't support it. mpm-worker however, spawns threads, so it will probably work there. mpm-winnt is a Windows variant of a multi-threaded MPM, so it should work too.
The worst that can happen is that the call will be executed as a normal fsockopen call.