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]
Related
I would like to start a Windows service ((as a daemon or ScheduledTask) on one of the clients in a small Active Directory domain for testing purposes only. The Windows service is Docker Desktop. Ideally, the service should start before a user logs in.
I am wondering what is the recommended approach for this procedure to start services properly and securely.
My approach would be the following: I would create a local user and then assign the service to that user using Task Scheduler. Would that be broadly the recommended approach or is there some kind of system user to entrust the task to?
In OSX/Cocoa I'm creating a daemon to be run in given intervals of a day. AFAK, daemons are executed independently of logged users and so, in other words, it is run even with locked screen isn't it?
In my approach, I've created of a .plist file in the /Library/LaunchDaemons that describes my daemon. I've set the label, ProgramArguments, StartCalendarInterval, and UserName. All is correct, and by triggering launchctl load at console, the daemon runs OK;
Problem comes when my computer is asleep or screen-locked. Every time that my daemon executes, it send an email to me in the end of its execution, and it appears that the daemon is not running.
Am I missing something?
Is it possible to start postgres process with a user account that has "administrative" privileges? I am on windows XP.
--Error shown is --- (Not really error, it is a security feature)
The server must be started under an unprivileged user ID to prevent
possible system security compromises. See the documentation for
more information on how to properly start the server.
Current work around is to create normal user and run process under that. What I am looking at is quick way to start database, do some operations and shut it down as part of build process.
(years later)
Postgres ships with a control program. See details in official documentation
Short answer:
pg_ctl start "args"
I have a pair of launchd daemons, one of which is a true daemon (runs as root) and one of which is a GUI agent that runs as a per GUI session basis (session type Aqua).
I need to prevent non admin level users from disabling the user level agent using launchctl, or at the very least figure out how to reload the agent from the root level daemon.
The best article I've found so far is this one, but it doesn't really offer any clear solutions.
The easiest way would seem to be to fetch the current console user periodically in the root daemon and then run launchctl load ... as that user, but I'm not entirely if if that's possible/how I would go about this (if I just run load from the daemon without posing as the user, it will be loaded under the root user, which does no good).
Any ideas?
you could check for authorization in your SIGTERM handler, see http://developer.apple.com/mac/library/technotes/tn2002/tn2095.html for sample custom authorization check
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.