#
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.
|
#
e96835a9 |
|
27-Nov-2017 |
Axel Dörfler <axeld@pinc-software.de> |
Added simple test_launch_daemon. * Expects its config files in /boot/home/test_launch. * Uses standard I/O, and is always in user mode. * Also added test_launch_roster command that is able to talk to the test server like it does to the real thing.
|
#
852e09d6 |
|
29-Nov-2016 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added stop target ability. * Before, you had to stop each job by itself.
|
#
90fd6af0 |
|
12-Jan-2016 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added ability to enable/disable a job. * Instead of just starting/stopping it. * Also available via the launch_roster command.
|
#
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.
|
#
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.
|
#
2e17b650 |
|
21-Oct-2015 |
Axel Dörfler <axeld@pinc-software.de> |
BLaunchRoster::ResetStickyEvent() added. * Used to unflag sticky events that already have been triggered once.
|
#
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.
|
#
326e03f7 |
|
17-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
BLaunchRoster: removed be_launch_roster again. * Not implemented, an unused -- no need for a global instance.
|
#
d94e9c97 |
|
16-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added support for external events. * Other apps can register events, and the launch_daemon can act on them when they are triggered.
|
#
4c67f79c |
|
01-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
FirstBootPrompt: launch installer/desktop targets directly. * No need for shell scripting here.
|
#
560119c9 |
|
25-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Don't verify passwords. * Instead, the caller should have done this already. This is really outside of the scope of the launch_daemon. * Fixed Login with empty passwords; removed the (unused) test login feature along the way.
|
#
c086a183 |
|
15-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Improved target support. * You can now put jobs/services into a target. * Instead of having Login started as part of the normal boot process, it's now in the "login" target. * The app_server now launches the login target when a login becomes available (ie. during startup, but that could be improved later on).
|
#
ac0a462f |
|
10-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Basic user session implementation. * Instead of launching Tracker/Deskbar directly, we now launch the Login application. * This will now start a new session for the selected user (the password is currently ignored). * When a user session is started, the launch_daemon forks, and the child then restarts the LaunchDaemon application in user mode. * It then registers itself with its parent, in order to resolve user dependent services. * Added a user launch file that will cause Tracker, and Deskbar to start in the new session.
|
#
9d69dc09 |
|
21-Apr-2015 |
Axel Dörfler <axeld@pinc-software.de> |
libroot: added ability to communicate with the launch_daemon. * These methods don't really work yet, as BMessage doesn't support replying with a KMessage; the request is received, but the reply never gets to the target.
|
#
43aec2c7 |
|
21-Apr-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: added support for arbitrary ports. * Dropped "create_port" -- this is now the default for services. * Additionally (or alternatively, if you use the "legacy" mode), you can now create named ports, and specify their capacity. * Added convenience methods to BLaunchRoster that automatically use the signature of the current be_app.
|
#
d482c7ca |
|
15-Apr-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: actually launch the jobs. * BRoster::Launch() cannot be used (yet), as it pre-registers the application we're launching, and that won't work for the registrar or anything else until the registrar is up and running. * Renamed B_GET_LAUNCH_CONNECTIONS to B_GET_LAUNCH_DATA. * Add the team ID to the get-launch-data reply. * Added BLaunchRoster::GetPort() for convenience. * Removed some superfluous debug output, but temporarily dump all stdio to /dev/dprintf (ie. the syslog). * Made job matching case insensitive (as MIME types should be).
|
#
1480e5da |
|
02-Apr-2015 |
Axel Dörfler <axeld@pinc-software.de> |
The beginnings of a launch_daemon for Haiku. * This will be heavily inspired by Apple's launchd, as well as systemd -- for now it really doesn't do a whole lot, though. * What works so far: the configuration files are read, parsed, and the jobs created. * The jobs are even initialized, and their message ports created. * BApplication now retrieves a previously created port from the launch_daemon for use with BServer. * Only the registrar actually uses this for now.
|
#
326e03f721fc9ae3f401c486df14cfd49da63009 |
|
17-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
BLaunchRoster: removed be_launch_roster again. * Not implemented, an unused -- no need for a global instance.
|
#
d94e9c97d269f47313d5134d0d90a62dd9428dae |
|
16-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Added support for external events. * Other apps can register events, and the launch_daemon can act on them when they are triggered.
|
#
4c67f79c2cf7d08667cd36242f1520f279a7ed33 |
|
01-Jul-2015 |
Axel Dörfler <axeld@pinc-software.de> |
FirstBootPrompt: launch installer/desktop targets directly. * No need for shell scripting here.
|
#
560119c9a46601b0051520c3c77be5a0e8dd874a |
|
25-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Don't verify passwords. * Instead, the caller should have done this already. This is really outside of the scope of the launch_daemon. * Fixed Login with empty passwords; removed the (unused) test login feature along the way.
|
#
c086a1834bb7041ca9f64abfee7a3b3bb9f06aa9 |
|
15-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Improved target support. * You can now put jobs/services into a target. * Instead of having Login started as part of the normal boot process, it's now in the "login" target. * The app_server now launches the login target when a login becomes available (ie. during startup, but that could be improved later on).
|
#
ac0a462fba6a1337e6659ebf0ffd69fd64030786 |
|
10-Jun-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: Basic user session implementation. * Instead of launching Tracker/Deskbar directly, we now launch the Login application. * This will now start a new session for the selected user (the password is currently ignored). * When a user session is started, the launch_daemon forks, and the child then restarts the LaunchDaemon application in user mode. * It then registers itself with its parent, in order to resolve user dependent services. * Added a user launch file that will cause Tracker, and Deskbar to start in the new session.
|
#
9d69dc097d9ed89ff288101868a60c07660a6841 |
|
21-Apr-2015 |
Axel Dörfler <axeld@pinc-software.de> |
libroot: added ability to communicate with the launch_daemon. * These methods don't really work yet, as BMessage doesn't support replying with a KMessage; the request is received, but the reply never gets to the target.
|
#
43aec2c726cc9522f961f87771f1ea712d54c0b7 |
|
21-Apr-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: added support for arbitrary ports. * Dropped "create_port" -- this is now the default for services. * Additionally (or alternatively, if you use the "legacy" mode), you can now create named ports, and specify their capacity. * Added convenience methods to BLaunchRoster that automatically use the signature of the current be_app.
|
#
d482c7ca5ba4f9041dfd5db328bd9703ea57d2ae |
|
15-Apr-2015 |
Axel Dörfler <axeld@pinc-software.de> |
launch_daemon: actually launch the jobs. * BRoster::Launch() cannot be used (yet), as it pre-registers the application we're launching, and that won't work for the registrar or anything else until the registrar is up and running. * Renamed B_GET_LAUNCH_CONNECTIONS to B_GET_LAUNCH_DATA. * Add the team ID to the get-launch-data reply. * Added BLaunchRoster::GetPort() for convenience. * Removed some superfluous debug output, but temporarily dump all stdio to /dev/dprintf (ie. the syslog). * Made job matching case insensitive (as MIME types should be).
|
#
1480e5da6fc4a2926c3da1a973e39927ac2171ae |
|
02-Apr-2015 |
Axel Dörfler <axeld@pinc-software.de> |
The beginnings of a launch_daemon for Haiku. * This will be heavily inspired by Apple's launchd, as well as systemd -- for now it really doesn't do a whole lot, though. * What works so far: the configuration files are read, parsed, and the jobs created. * The jobs are even initialized, and their message ports created. * BApplication now retrieves a previously created port from the launch_daemon for use with BServer. * Only the registrar actually uses this for now.
|