Opened 5 years ago
Last modified 5 years ago
#15923 new bug
launch_daemon: add ability to configure jobs
Reported by: | X512 | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Servers/launch_daemon | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is hrev54101.
It should be possible to configure job start mode (auto start, demand start, disabled) and configuration should be saved.
Currently it is not posssible to disable launch jobs in package without blacklisting.
Change History (3)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
If I understand right launch_daemon is intended to run not only OS jobs, but also jobs of user installed software. User may want to change job start type and save setting so it will be preserved after reboot. Windows and Linux support this feature.
comment:3 by , 5 years ago
This is currently handled in each job by referring to the application settings file. As I mentionned, LaunchBox does this, LnLauncher which is user-installed does this too. So you can configure the job from inside each application.
The list of services in Windows is quite confusing as it lists many things and it's hard to know which are really useful or not, and which applications they come from.
In any case, since there is support for checking a settings file from inside a job, certainly it's not too hard to do it from outside a job as well, and add a global settings file with all disabled jobs.
Which system jobs do you need to disable?
The job itself can have a setting (for example LaunchBox and LnLauncher use this), we could extend this if needed. Or we could also split the Haiku package in more modular parts, so you can just remove the packages with the parts you don't want.
Letting the user disable parts of the OS can be a problem because then apps can't really know what's running or not. Currently when an application depends on the Haiku package, it can expect that that's enough to know all servers will be there and running. If we do this by splitting packages, apps could depend on specific ones (haiku_desktop, haiku_media, whatever) and still convey this info from package dependencies.
Maybe your use case is different and more specific control is needed.