Shell Programming and Scripting

I would like to implement a push service, but I havent't found any example for that on the internet yet. The step from "kill" command to push service is too large for me.

A signal is a way to tell a program to do something when told instead of constantly checking for something. If it hasn't been told to do anything when it gets the signal, the signal will probably kill it instead.

Code:

#!/bin/sh

# Display the contents of a file and set a variable on SIGINT
trap 'cat /tmp/filename ; rm /tmp/filename ; VAR=1' INT

echo "My PID is $$"

while true
do
        VAR=0
        # Two reason read might fail -- end of file, or SIGINT.
        # If it was interrupted, just try again.  Otherwise, quit.
        if ! read LINE
        then
                [ "$VAR" -eq 1 ] && continue
                break
        fi

        echo "read line from keyboard: $LINE"
done

Run this in one window:

Code:

$ ./stupidchat.sh

My pid is 21188

Then do this in another:

Code:

# Vitally important message
$ echo "hey guys alj af MY FACE IS A ROTTORN BANANA" >/tmp/filename
$ kill -INT 21188

...and the first script should receive the signal, trap it, read the file and delete it

Thanks for your example :-)
There is still a problem, because I can't call "kill" on a remote machine. Hence, I can only call a remote script that sends the signal to the remote process. Is It better to call the process by name or by process ID? Will the process ID be constant after reboot?

Yes, kill is named for it's most popular use, termination, but it is just a signal sender.

in shell, trap is the shell signal catcher. SIGINT was available, but for apps SIGUSR1 and SIGUSR2 are most appropriate: Man Page for signal (linux Section 7) - The UNIX and Linux Forums

The signal processing is done out of sequence with the process thread(s), but in the same process so variables are passed.

So, you can push files to input-dir/unique.take-me-extension, the final step being mv and then kill to start the possibly, usually sleeping server so it processes the input.(

Code:

ssh server_host 'cat >input-dir/unique.take-me-extension.tmp
  mv input-dir/unique.take-me-extension.tmp input-dir/unique.take-me-extension
  kill -SIGUSR1 `< server-pid-file`
 ' < input-file

Of course, you have to be the same id or root to signal a process. Named pipes can stall servers that only require the writer have permission on the pipe.

Code:

$ mknod p p
$ ls -lA|grep '^p'
prw-r--r--   1 my_uid    my_group          0 Oct 25 14:54 p
$ while :
do
 cat <p
done &
[1]     19299
$ echo hi >p
$ hi
echo hello >p
$ hello

There may be a hundred scripts running with the same name, but they will all have different process ID's. No. The usual procedure is for a process to save a file under /var/run/ somewhere containing its process ID for other things to check.

The whole app shall be some kind of LAN messaging program with a central host that receives, stores and forwards messages to the correct receiver when he is online. For sending messages over the LAN, rcp shall be used.

On the mediator host, each user has a folder where all the messages are stored that are addressed to him. Therefore, each sender must be able to send a signal to this mediator host when a message has been sent. I haven't yet completely understood how to call unambiguously a process on this host.

A common dir means there is only one place to look when woken up to process input. The file name itself can contain unique information like what user sent it and what the sequence number is. A "kill -SIGUSR1 `<pid_file`" can wake up the service.

If you make it a UDP service, the server blocks on the UDP socket waiting for incoming messages, processing them one at a time. They can be queued in the socket buffer, which can be made large enough to deal with the probalbe backlog. The process reading the socket can just log the messages for further processing, so there is no liklihood of a big backlog. The service can frame the bytes in the log into different discussions. Once the log gets to a certain size, it can be rotated out for another. The log could even be a zip file for the day, with each message an archived file in appropriate interanl folder paths. You can glob through zip files as if they were directories with some tools like MS Windows Compressed folders and HXTT JDBC CSV/Text Drivers. UDP also allows for a multicast of messages back to participating users. The size is a bit restricted, not as much as twitter, 65k, but 1,440 is a more reliable size.