I am new to Mac OSX and i am trying to develop a daemon (i am familiar with windows services, and trying to achieve about the same things).
What i did so far:
Managed to write a plist file in LaunchDaemons (i found out that those daemons run under system account, not user, just like a windows service with local system permissions).
I managed to make it run on startup, and run my simple hello world application that just writes something to a file every 10 seconds.
The problem is, when i unload the daemon with launchd, it just kills my process.
Is it any way to have the daemon either run something else on unload, or communicate to my process that it is shutting down, so i can perform an unload action in my code?
Thank you
The lifecycle of a daemon is documented by Apple and they describe how to handle Terminating Processes
If you're using Objective-c or Swift, you should be able to implement the applicationshouldterminate delegate method.
If you're not using Cocoa:
Non-Cocoa applications receive a “Quit Application” Apple event (kAEQuitApplication), as a courtesy, to give them a chance to shut down gracefully
Finally, since you're running a daemon (background process)
For background processes, the procedure is a little different. The loginwindow program notifies the process that it is about to be terminated by sending it a Quit Application Apple event (kAEQuitApplication). Unlike foreground processes, however, loginwindow does not wait for a reply. It proceeds to terminate any open background processes by sending a SIGKILL signal, regardless of any returned errors.
If the system is being shut down or restarted, it sends a SIGTERM signal to all daemons, followed a few seconds later by SIGKILL signal.
There's a discussion on handling SIGTERM here.
Related
Related to a question I asked here -- I have a process that I launched which is in a "suspended" state. I cannot kill or resume this process through any of the normal means (process explorer, task manager, WinDbg).
Logging-out of my session DOES kill this process though. How? What mechanism is the OS using when I log out that is somehow different to what Process Explorer is trying to do?
Edit: To clarify - I am assuming that Process Explorer is calling the TerminateProcess API function when it tries to kill a process. Something in the process state is stopping this from working though. Logging out obviously invokes some different behaviour and Windows ignores whatever was blocking TerminateProcess, and kills the process due to my session ending.
As a user, is there any different way to try and terminate a process other than calling the TerminateProcess API?
Process Explorer can't kill a process itself; it can only ask the OS to do so. The OS itself doesn't have to play by its own rules.
Remember, it's the OS itself which defines what a process is. It might very well define a process as part of a logon session. This would imply that if you clean up the whole session then you don't need to clean up individual processes. Just like you don't need to bother with CloseHandle before ExitProcess either.
With respect to this excellent post:
What's the difference between nohup and a daemon?
I would like to ask the following:
After launching an application from my terminal, the application keeps running either in the background or the foreground and the only thing I can do to interact with it is by sending it signals from my terminal (given that stdin is still in place).
However, after a daemon process is launched, I realized that it can be controlled with other means like querying it or restarting it (arch way):
# /etc/rc.d/daemon-name {start|stop|restart|status|...}
Could someone explain to me if that feature is built-into the general "daemon framework" and applies to every daemon process as a special feature or is it just a provision that processes designed to run as a daemon will have to handle internally?
And to add more to the matter, how on earth are we able to "control" daemons from the terminal using their name (i.e. sambad stop) while applications always have to be referred using their name (i.e. kill -9 1234)?
Thank you in advance!
# /etc/rc.d/daemon-name {start|stop|restart|status|...}
it is not a querying to the daemons directly. It is launching scripts by standart interface and these scripts in turn operate with daemon process by PID and signals. This scripts are creating during installation process of daemons-programs.
Heres a simple question - is there anyway that a non-console (ie a CWinApp) application can receive and process CTRL+BREAK, it would appear SetConsoleCtrlHandler doesnt do the job nor the installation of signal handlers?
I unfortunately am working with a legacy CDialog based app which is run under the control of Microsoft HPC and HPC uses CTRL+BREAK to cancel the program (assuming i guess that nobody in their right mind would have a non-console app running in the background)
Cheers.
Calling AttachConsole with ATTACH_PARENT_PROCESS should do the trick. This will attach your process to the HPC console so that it can receive the control-break signal. You should probably do this before calling SetConsoleCtrlHandler.
If that doesn't work, try AllocConsole instead. If HPC doesn't have a console of its own, it might be assuming that the sub-process will have created a new console group (this happens automatically for console-mode applications) in which case it will be sending a control-break signal to the sub-process PID. If so, it shouldn't matter whether the console group was created automatically or explicitly.
You may wish to start by making sure that HPC is indeed sending a control-break signal (presumably via GenerateConsoleCtrlEvent) by checking that SetConsoleCtrlHandler works as expected for a console-mode application. If it is calling TerminateProcess instead then there is nothing you can do about it.
Background: We have a VB6 application [1] that runs on terminal services. As part of the update scripts, tskill [2] is used to kill off any running apps so that the application may be updated. Sometimes tskill cannot kill the process, although remoting in, and using task manager can take care of it.
Questions: what could cause a VB6 mdiform app to hang and not get shut down? Is there anything we can add to the app to make it shut down more gracefully?
Notes:
1 - It was supposed to be replaced already, but the SAP replacement is more than 1 year behind schedule.
2 - The script command is basically tskill theApp /server:theServer as it iterates across all the servers.
The app could actually have code to ignore the shutdown/kill request and cancel the unload.
I've seen where message boxes being open will cause an application to not respond to shutdown requests.
It's possible the main form is unloading, but there are other forms resident in memory that cause the EXE to continue running without a UI.
I have a Win32 service, that needs to run a .NET executable on service stop (for cleanup reasons). I recently discovered that the cleanup never happens on shutdown, because the process creation gets blocked by OS. Does anyone know a way to override this? Process, I am spawning is not invasive and should only run a fraction of a second.
The only way I could find to do it was: pre-create a child process suspended, and them un-suspend it on shutdown.