#
a77aa747 |
|
25-Apr-2018 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added basic logging facility * The daemon now stores many events in am internal log. * You can use "launch_roster log" to retrieve it.
|
#
6d7b8a30 |
|
04-Dec-2017 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Renamed TeamRegistrator to TeamListener
|
#
59e6d9d2 |
|
27-Nov-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Maintain pending jobs for requirements. * If a requirement cannot be launched, a job is now added to the requirement as pending job. * If the requirement enters the launch queue at a later time, the pending job will be put there, too.
|
#
9e73b627 |
|
11-Nov-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Fixed preregister consequences. * Since the last change, the user launch_daemon would talk to the registrar again. * However, this also caused BRoster::Launch() to preregister the app, which messed up our preallocated port. * BRoster::Private::Launch() now allows to get the port that the registrar created in such a case, and the launch_daemon will now just use that one as default port. * This lets us talk to the Deskbar again, and should fix #12455, as well as #12454 (again).
|
#
70708ef9 |
|
10-Nov-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Retrieve default port from monitoring BRoster. * Instead, we now maintain a default port for a job. For "legacy" services, BRoster's B_SOME_APP_LAUNCHED will update it, too. * This allows to quit Tracker using "launch_roster stop". * Also, this fixes bug #12249, as we don't use the signature variant of creating BMessenger anymore in Job::GetMessenger(). This would call into the launch_daemon again, and deadlock.
|
#
5860caae |
|
07-Nov-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added basic ability to stop/start jobs via API. * Stopping a job is very simplistic right now, and will have to be extended considerably, probably with its own job.
|
#
e2f83cbd |
|
06-Nov-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Monitor teams, and restart services. * Services that end are now automatically restarted. * However, this is very basic at the moment, there is no throttling, and no support for shutting down the system.
|
#
4ae4b3ff |
|
18-Oct-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Fixed the remaining "operation not allowed" bug. * This was the harmless part: a job was been requeued that already was being launched. * I was already aware of this one, and only accidentally stumbled over the non-harmless case in the JobQueue code when I tried to fix that little issue... (ie. never ignore warnings, even if you think you know what's going on).
|
#
7cd19b7e |
|
17-Oct-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Implemented sticky events, and registration. * Sticky events are events that keep their signal raised, ie. even if a job is initialized afterwards, it will still be triggered. * Consolidated naming for external events. * Events are now registered once they are actually being used. This allows them to allocate the resources they need to do their thing.
|
#
5cf6c0fd |
|
28-Aug-2015 |
Michael Lotz <mmlr@mlotz.ch> |
launch_daemon: Create/inject ports on launch instead of upfront. The application is now launched suspended and the ports are created and transferred to the launched team before its main thread is resumed. The ports are therefore owned by the launched team instead of the launch_daemon. This is important when sending messages by area, as the port owner is used to determine where the data area needs to be transferred to. This commit therefore fixes #12285. Note that it is still possible to get at the ports with find_port() while they are still owned by the launch_daemon. This should not be a problem however, as these ports are not supposed to be found this way but only through BLaunchRoster::GetData(), which is synchronized with the above process. Creating the ports in the launch_daemon still has the benefit of returning valid communication ports earlier, i.e. without having to wait for the launched application to actually become ready.
|
#
14156a33 |
|
26-Aug-2015 |
Michael Lotz <mmlr@mlotz.ch> |
launch_daemon: Delegate launch data replies to Job. Previously the LaunchDaemon would send out its own team id when a given job was not yet launched, leading to invalid BMessengers once the port owner changed to the actually launched team. The launch of the target team and the launch data replies were also not synchronized, which could lead to the launched team getting a reply pointing to the launch_daemon when requesting data for itself. This is the case for the BRoster init of the registrar. The fix in hrev49561 therefore didn't always work, because the registrar would sometimes get the launch_daemon team id instead of the id of itself. It would later try talking to the launch_daemon, which obviously never replied, leading to #12237. The LaunchDaemon now delegates the launch data reply to the Job instead. The Job either replies directly, in case it has already been launched, or queues the reply for when the launch completes. This causes launch data requesters to block until the launch attempt is completed, but won't block the LaunchDaemon message loop. This commit introduces the seperate fLaunchStatus to properly handle the ambiguity of fTeam being < 0, which is the case for both, when no launch was attempted and when the launch failed. This new field now determines what IsLaunched() returns and how launch data replies are handled. The new launch status is additionally protected by the launch status lock, which will later probably be made broader in scope to protect against race conditions once service monitoring is implemented.
|
#
2ca4f3f8 |
|
17-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Jobs were started before their target. * A job must not be launched when its target hasn't been launched yet. This fixes Tracker launching when the mount_server scanned the initial disk, even though the FirstBootPrompt was showing. * Jobs are no longer initialized when their target has not been launched yet. This also means that you cannot talk to a service beforehand in this case. * Slight refactoring and clarifying, even added some documentation :-) * _TriggerJob() is now called _LaunchJob(), and does all the checks for jobs that _LaunchJobs() does now for targets.
|
#
ea19a80e |
|
06-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added support for setting env. * We cannot "source" files through a shell yet, though.
|
#
e0fc09b4 |
|
25-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Conditions now know if they are constant. * This allows to remove a job in the init phase already, if its condition is not only constant, but also failing. * Also removed the special Job::LaunchInSafeMode() method; this is now done using the conditions (the config option no_safemode remains, though).
|
#
1e9c9871 |
|
22-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added basic support for conditions. * Admittedly not very well thought out, but it should be good enough for now; it doesn't really make sense to initialize jobs that is never run due to failed conditions. * Job, and Target now have a common base class BaseJob that deals with the conditions.
|
#
8b8780bf |
|
15-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Moved Job+Target into separate files.
|
#
5cf6c0fd3b9fe36a587bd712eade8045ea4cc723 |
|
28-Aug-2015 |
Michael Lotz <mmlr@mlotz.ch> |
launch_daemon: Create/inject ports on launch instead of upfront. The application is now launched suspended and the ports are created and transferred to the launched team before its main thread is resumed. The ports are therefore owned by the launched team instead of the launch_daemon. This is important when sending messages by area, as the port owner is used to determine where the data area needs to be transferred to. This commit therefore fixes #12285. Note that it is still possible to get at the ports with find_port() while they are still owned by the launch_daemon. This should not be a problem however, as these ports are not supposed to be found this way but only through BLaunchRoster::GetData(), which is synchronized with the above process. Creating the ports in the launch_daemon still has the benefit of returning valid communication ports earlier, i.e. without having to wait for the launched application to actually become ready.
|
#
14156a33ac0233f4233546080d6b975618b331fa |
|
26-Aug-2015 |
Michael Lotz <mmlr@mlotz.ch> |
launch_daemon: Delegate launch data replies to Job. Previously the LaunchDaemon would send out its own team id when a given job was not yet launched, leading to invalid BMessengers once the port owner changed to the actually launched team. The launch of the target team and the launch data replies were also not synchronized, which could lead to the launched team getting a reply pointing to the launch_daemon when requesting data for itself. This is the case for the BRoster init of the registrar. The fix in hrev49561 therefore didn't always work, because the registrar would sometimes get the launch_daemon team id instead of the id of itself. It would later try talking to the launch_daemon, which obviously never replied, leading to #12237. The LaunchDaemon now delegates the launch data reply to the Job instead. The Job either replies directly, in case it has already been launched, or queues the reply for when the launch completes. This causes launch data requesters to block until the launch attempt is completed, but won't block the LaunchDaemon message loop. This commit introduces the seperate fLaunchStatus to properly handle the ambiguity of fTeam being < 0, which is the case for both, when no launch was attempted and when the launch failed. This new field now determines what IsLaunched() returns and how launch data replies are handled. The new launch status is additionally protected by the launch status lock, which will later probably be made broader in scope to protect against race conditions once service monitoring is implemented.
|
#
2ca4f3f81d28b528d479f95e29cf6f936e2c7dc7 |
|
17-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Jobs were started before their target. * A job must not be launched when its target hasn't been launched yet. This fixes Tracker launching when the mount_server scanned the initial disk, even though the FirstBootPrompt was showing. * Jobs are no longer initialized when their target has not been launched yet. This also means that you cannot talk to a service beforehand in this case. * Slight refactoring and clarifying, even added some documentation :-) * _TriggerJob() is now called _LaunchJob(), and does all the checks for jobs that _LaunchJobs() does now for targets.
|
#
ea19a80ed6ba3f34abb2e4d138ddc666580b8d82 |
|
06-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added support for setting env. * We cannot "source" files through a shell yet, though.
|
#
e0fc09b439b66df0e35c159d0b5b055cde7d2792 |
|
25-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Conditions now know if they are constant. * This allows to remove a job in the init phase already, if its condition is not only constant, but also failing. * Also removed the special Job::LaunchInSafeMode() method; this is now done using the conditions (the config option no_safemode remains, though).
|
#
1e9c98710286129c9161f29787742b1ea2bff449 |
|
22-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added basic support for conditions. * Admittedly not very well thought out, but it should be good enough for now; it doesn't really make sense to initialize jobs that is never run due to failed conditions. * Job, and Target now have a common base class BaseJob that deals with the conditions.
|
#
8b8780bfe399a2a8058f4620e5f33f74db097ca2 |
|
15-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Moved Job+Target into separate files.
|