Addressing process on a remote machine

[pinhead]

Hello forum,
how can I reliably address a process on a remote machine? A process has a name, which is sometimes not unique, and a process ID, which is unique, but not constant.

[atreyu]

Hi,

I'm not really sure I understand your question. Yes, the PID will always by unique, by definition, I'm not sure what you mean about it not being constant. Even if the process name was the same, the PID would always be different, each subsequent time it is run (or even if two instances are run concurrently).

Can you define your scenario in more detail?

In any event, Without knowing more, I'd say you should be able to get what you want through a combination of "ps" and "pidof -x". If it is on a remote machine, you can ssh in and run the command (or commands) in a remote shell, e.g.:

ssh user@remotehost "ps auxww|grep blah blah"

If you are in control of the running remote process, it would be good to make sure that it is being called via absolute path, e.g.:

/usr/sbin/progd

vs

exec progd

that way, you can use the full path to verify it is the program you are interested in.

[pinhead]

Thanks. I want to send a signal to a process that is running on a remote machine. This signal shall work as an event that indicates that a file has been sent from host A to host B. This kind of functionality should work between normal users without any admin privileges.

[atreyu]

Thanks. I want to send a signal to a process that is running on a remote machine.

Okay, so you need to know the name of the process. Are there multiple instances of this process running on the remote machine? Try this to get the pid:

pid=$(ssh user@remotehost pidof -x $process_name)

if $pid is not empty, then it found the process name and returned the pid. i'm not sure what the process is, and how to send signals to it, but it your are sending signals via kill, you can then do something like:

ssh user@remotehost kill -$signal $pid

This kind of functionality should work between normal users without any admin privileges.

hmm...not sure about that. it depends on how you are sending signals. you may have to configure sudo to do that, if the process is being run by root.

[pinhead]

No, only one instance is required.

The whole program should work as some kind of messaging script:
A sender writes some text, saves it in a file and sends this file via rcp to the receiver. The receiver script is then notified by a signal about the file that has been sent and it reads this file and displays it to the user. Another solution would be an endless while-loop that constantly observes a folder, but polling is always bad.

[atreyu]

The whole program should work as some kind of messaging script:
A sender writes some text, saves it in a file and sends this file via rcp to the receiver. The receiver script is then notified by a signal about the file that has been sent and it reads this file and displays it to the user.

Okay, so you don't have a program in place already. You can write one in bash fairly easily. You can use the "trap" command in Bash to trap signals sent to a bash script. Read the bash man page, and under SHELL BUILTIN COMMANDS, read up on the trap entry. I assume of course that this bash command is running as some sort of daemon.

[Irithori]

@pinhead: I assume, this question is related to your previous threads.
Correct me if I understood you wrong:
- You essentially want to build an Instant Messenger Service in bash
- Any user on a given machine shall be able to write messages to any user on the local and remote machines.

If that is the case, then copying a message via rcp and then triggering the remote side via ssh is not the best design.
1) It needs rcp configured on every machine. rcp is not so much used nowadays. This prerequisite is therefore not given.
2) rcp is not encrypted.
3) Using ssh to find out a remote process pid and then send a signal to it is bad design:
- User A would need the credentials of user B in order to login. That is a big NoNo.
- User A would then have full control of user B´s account.
4) Bash as a prerequisite is also a moving target: Not everyone uses bash. There are other shells like csh or tcsh.


My suggestion would be to write a daemon in a python/ruby/C.
This daemon should listen to a tcp port and have a defined API.
You can choose between a traditional server-client model or go for a p2p-like model.

Writing such a daemon/client in bash is not trivial.
Bash is not the first choice here, but if you want to go forward:
- daemonizing bash
- Advanced Bash-Scripting Guide

[pinhead]

You are right, but I don't have a choice here, because the requirements are predefined. I am a shell scripting noob, that's why I can't really evaluate which kind of architecture the best choice is. What do you think of xinetd? Could this be a better approach?

I forgot some info about the architecture:

Client:
Sends and receives messages

Server:
A mediator machine where all messages are sent to and that distributes them to the target machines.

rcp shall be used for data transmission.

[atreyu]

You are right, but I don't have a choice here, because the requirements are predefined. I am a shell scripting noob, that's why I can't really evaluate which kind of architecture the best choice is. What do you think of xinetd? Could this be a better approach?

For the record, I agree w/Irithori.

Also, could you be more specific about your requirements? For example, are you really required to use Bash to achieve your goal, and for that matter, what exactly is that goal? (I have not read/seen your other posts).

Understanding this will help us help you.

[pinhead]

The goal is to write a simple shell script LAN messaging program that sends messages by using rcp. Normal users should be able to send messages only to one user, admins should be able to send messages to all users. The client computers send messages to a central mediator host that stores and forwards them to the target hosts if they are reachable.

I am not limited to the Bash shell.