#
5140a1bb |
|
24-Jun-2023 |
Niels Sascha Reedijk <niels.reedijk@gmail.com> |
Package Kit/Launch Server: avoid/ignore use of requires keyword In C++20 `requires` is a reserved keyword. GCC13 warns against its use. This change removes the use of the keyword in our own code, and ignores it in the external 'libsolv' code. Change-Id: I3319d20c0a3fdad89630683cdff5ea3b17f04e99 Reviewed-on: https://review.haiku-os.org/c/haiku/+/6647 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
30764e38 |
|
25-Apr-2018 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Fixed getting data of stopped service * If you stopped a service, and ran it manually, it would hang forever waiting for its port data.
|
#
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
|
#
270f0f2f |
|
11-Jan-2016 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Don't get the token from the registrar. * It doesn't work, and BMessenger also only uses the preferred token. * I haven't investigated why it doesn't work yet, though.
|
#
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.
|
#
93bb55e4 |
|
11-Nov-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Fixed resetting launch status, port update. * _SetLaunchStatus() doesn't allow to set the status to B_NO_INIT (and rightly so). * Therefore, we now reset it manually in Job::TeamDeleted(). This fixes restarting things that once ran on demand. * Also update the port message when the default port changes.
|
#
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.
|
#
3282b758 |
|
04-Nov-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Add API to get information on jobs. * Ie. a listing of all targets/jobs, as well as specific (basic) info on each. * Also added a bit of optional debug output. * Moved translating the path to launch time -- we should take the job's environment into account here at some point.
|
#
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.
|
#
5b9f6b54 |
|
28-Aug-2015 |
Michael Lotz <mmlr@mlotz.ch> |
BRoster: Add launchSuspended option to _LaunchApp(). It allows to launch the app, but keep its main thread suspended instead of automatically resuming it. Also add appThread argument which allows to retrieve the main thread of the launched team.
|
#
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.
|
#
26f8579d |
|
23-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: GCC4 build fix.
|
#
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.
|
#
634aefe4 |
|
08-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Now supports getting the env from a script. * Scripts from targets are evaluated once on first target launch, scripts from jobs are evaluated on each start. * The "desktop" target now sources SetupEnvironment as usual.
|
#
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.
|
#
79879070 |
|
26-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: We can now talk to the authentication manager. * When creating the port of the registrar's authentication manager, we now set it manually, so that the user/group functions work. * This allows LaunchDaemon::_StartSession() to set up the user, and groups as needed.
|
#
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.
|
#
78e39852 |
|
17-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Use BRoster::Launch() without registrar. * BRoster now allows settings a "no-registrar" mode that is currently only honored in _LaunchApp(), though. * Job::Launch() is now using this, which also allows launching applications by signature (ie. if the job name matches the signature, you can omit the "launch" option).
|
#
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.
|
#
5b9f6b5485af065913bc747f5c6a21001b275b7f |
|
28-Aug-2015 |
Michael Lotz <mmlr@mlotz.ch> |
BRoster: Add launchSuspended option to _LaunchApp(). It allows to launch the app, but keep its main thread suspended instead of automatically resuming it. Also add appThread argument which allows to retrieve the main thread of the launched team.
|
#
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.
|
#
26f8579d4cac74375a9a8b322a86726242879235 |
|
23-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: GCC4 build fix.
|
#
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.
|
#
634aefe4fdaa245ad977dd7e8eff1744f380a02d |
|
08-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Now supports getting the env from a script. * Scripts from targets are evaluated once on first target launch, scripts from jobs are evaluated on each start. * The "desktop" target now sources SetupEnvironment as usual.
|
#
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.
|
#
798790700871873f6d9da860567ff951005d7fbe |
|
26-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: We can now talk to the authentication manager. * When creating the port of the registrar's authentication manager, we now set it manually, so that the user/group functions work. * This allows LaunchDaemon::_StartSession() to set up the user, and groups as needed.
|
#
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.
|
#
78e39852fad37b7ce43c29d0f22c41405513c119 |
|
17-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Use BRoster::Launch() without registrar. * BRoster now allows settings a "no-registrar" mode that is currently only honored in _LaunchApp(), though. * Job::Launch() is now using this, which also allows launching applications by signature (ie. if the job name matches the signature, you can omit the "launch" option).
|
#
8b8780bfe399a2a8058f4620e5f33f74db097ca2 |
|
15-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Moved Job+Target into separate files.
|