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.

launch_daemon: Renamed TeamRegistrator to TeamListener

Merge remote-tracking branch 'upstream/master' into intel-extreme

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 a

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).

show more ...

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.
* Con

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.

show more ...

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
re

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.

show more ...

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
own

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.

show more ...

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 initia

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.

show more ...

launch_daemon: Added support for setting env.

* We cannot "source" files through a shell yet, though.

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 specia

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).

show more ...

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

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.

show more ...

launch_daemon: Moved Job+Target into separate files.

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

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.

show more ...

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 a

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).

show more ...

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

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.

show more ...

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.

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 shu

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.

show more ...

Merge branch 'master' into app_server

Conflicts:
src/kits/app/Roster.cpp