Unfortunately, my question is not as simple as keeping track of two windows created by the same process.
Here is what I have:
Two users, Jack and Jim are remotely logged in to the same Unix system and run X servers
Jack runs an application, 'AwesomeApp', that opens a GUI in a X window
Jim runs another instance of this application, opening his own GUI window
Now, Jack runs a supervisor application that will communicate with the process owning the first window (eg 'AwesomeApp') because it's HIS instance of 'AwesomeApp'
How can his instance of the supervisor find which instance of 'AwesomeApp' window is his own?
Aaaahhhh...looking it up on a per-user basis yes that could work.
As long as I tell the users that they cannot log in with the same user account from two different places.
You can use pgrep to get the process ID of Jack's instance of AwesomeApp:
pgrep -u Jack AwesomeApp
So if you launch the supervisor application from a shell script, you could do something like the following:
AWESOME_ID=`pgrep -u $USER AwesomeApp 2>/dev/null`
# run the supervisor application and pass the process id as the argument
supervisor $AWESOME_ID
Alternatively, if you don't want to use external programs like pgrep or ps, you could always try looking for the process in /proc directly.
Related
I have to restart 100's of scripts for at least 20+ users once the server restarts for any reason. I wanted to come up with a single script to trigger of all scripts/programs under all users with just one script (without root privilege).
Is it possible to do so? Linux If not, what is the best approach to proceed?
Thanks,
You can make a boot script in /etc/init.d/rc3.d that will use su - someuser -c somescript for the different users.
When you want the different users to control which scripts they want, you can give them control over the somescript (perhaps $HOME/bin/startme.sh).
When you are anxious that the scripts are always running, you can consider another approach: do not start them at a server restart, but put them in monitoring script in the users crontab. Each minute (or 5 minutes or hour) this monitor script can check the running scripts and restart them when needed.
Until we can implement our new HEAT SM system i am needing to create some workflows to ease our currently manual user administration processes.
I intend to use Powershell to execute the actual tasks but need to use VBS to send an argument to PS from an app.
My main question on this project is, Can an argument be sent to an already running Powershell process?
Example:
We have a PS menu app that we will launch in the AM and leave running all day.
I would love for there to be a way to allow PS to listen for commands/args and take action on them as they come in.
The reason I am wanting to do it this way is because one of the tasks needs to disable exchange features and the script will need to establish a connection a remote PSsession which, in our environment, can take between 10-45 seconds. If i were to invoke the command directly from HEAT (call-logging software) it would lock up while also preventing the tech from moving on to another case until the script terminates.
I have searched all over for similar functionality but i fear that this is not possible with PS.
Any suggestions?
I had already setup a script to follow this recommendation but i was curious to see if there was a more seamless approach
As suggested by one of the comments by #Tony Hinkle
I would have the PS script watch for a file, and then have the VBScript script create a file with the arguments. You would either need to start it on another thread (since the menu is waiting for user input), or just use a separate script that in turn starts another instance of the existing PS script with a param used to specify the needed action
I am working on a Raspberry Pi (with Rasbian). The board should run standalone (without login), so the application I developed should start upon each boot. But I would also like to be able to take the hand on the board locally (not using ssh). My requirements would then be:
boot
wait 1 minute - if there is any user interaction, skip 3.
launch application - this is a Python script
How would one do that?
Thanks for your help.
Julien
In our /etc/rc.local you can specify extra programs for startup, with delay. For instance you can add this:
python x
# sleep time in seconds
sleep 60
python y
If you are looking to to this ONLY if there is user interaction, I would recommend a bash script that returns this as bool. That would be in place of the "python y" command you see there. Sorry, I don't have a script like that handy.
I'm developing an app which will periodically download files from a remote server for a user. I'm wondering whether I should, in OS X parlance, use a daemon, i.e. it will run as long as OS X has been started, or a user agent, i.e. it will run as long as the particular user is logged in. Is there a convention? Are there any rules to abide by when thinking about this? I certainly don't want buck convention and end up having my app do something a user isn't expecting it to do.
Also, for such background processes, it seems like there might be a convention to have the app show up on the status bar. E.g. both Google drive and Mozy on my machine, which monitor for changes and upload in the background, both are represented in the status bar. Is this something I should do with my app?
there is absolutely a convention, a daemon is typically run as root or a special user (mysql, www), and a Agent runs as the user...
it doesn't matter with respect to how long they may live etc, as a daemon can either be long running like httpd, ftpd, etc, or launched just in time for use, as in a helper tool.
from man launchd:
In the launchd lexicon, a "daemon" is, by definition, a system-wide
service of which there is one
instance for all clients. An "agent" is a service that runs on a per-user basis. Daemons should not
attempt to display UI or interact directly with a user's login session. Any and all work that involves
interacting with a user should be done through agents.
so you may mix with some sort of IPC as in a backup daemon may send messages to a status bar app, which runs as and agent for your user.
Daemon vs Agent
UNIX Daemon - program(.plist + binary) which is running as a background process(like service in Windows)
Daemon is a UNIX Daemon without GUI. launchd starts it when a system has started(behalf on root). *launchd is also daemon - pid is 1 and it creates all other processes. Usually daemons have -d suffix(e.g. launchd, nsurlsessiond[About]). For example daemons can be used for Printer, Bluetooth...
Agent - is a UNIX daemon which can work with GUI through window server. launchd starts agent behalf on user after login with defined user permissions. For example Calendar, Skype...
launchd knows about daemons based on .plist in
User Agents ~/Library/LaunchAgents specific user
Global Agents /Library/LaunchAgents all users
System Agents /System/Library/LaunchAgents MacOS
Global Daemons /Library/LaunchDaemon installed apps
System Daemons /System/Library/LaunchDaemons MacOS
[Java Daemon tread]
I'm trying to start a service via a script that I run through cron. Basically it just does this
/local/services/servicename status
/local/services/servicename stop
/local/services/servicename start
The service starts fine if I run the commands myself, but whenever I run it via the script, and I check for the service status manually, its response is always
Servicename Service is not running.
I am truly confuse right now. Any particular reason why a bash script wouldn't be able to start the services?
Not really an answer to your specific question, but definitely a useful tip for debugging cron behavior in general. Cron sends email messages to the user it runs as. If you run that in the root crontab, run the mail command in a terminal as root and you'll see the cron messages in your inbox. Check them by typing the message number (or man mail to learn how to use it).