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 pulkomandy, 5 years ago

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.

comment:2 by X512, 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 pulkomandy, 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.

Note: See TracTickets for help on using tickets.