On Wed, Aug 24, 2011 at 9:31 AM, Jef Spaleta <jspal...@gmail.com> wrote:
> > > On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov > <akurt...@redhat.com>wrote: > >> I want to add one more POV - not every database is constantly-used. >> Example >> usage is Amarok using mysql database and I really want mysql to not be >> started >> until I start Amarok. Not that this is very common usage scenario but >> still I >> know at least one guy using Amarok with mysql :). >> >> You are using a system-wide network exposed mysql for Amarok? Is this > mysql serving information to multiple clients or multiple users? If its > system-wide and only being used by one application by one user, why is it > being run system-wide? > And to belabor the point a bit more. We really need to have distinct discussions about what a system service "default" is and what its okay for local admins are encourage/discourage/allowed to do. If you need to run a private instance of mysql on non-standard network ports to serve a local Amarok application in an on-demand fashion. Then you can do that as a local admin. In fact working with the mysql packager you might be able to use systemd's support for multiple instances to make it easier to set that up without it interfering with the system default mysql. However, does it make since to write the default init for the system-wide mysql with this usage case in mind? I'm not sure. It could very well be that for right now the system wide mysql default init needs to refrain from socket activation as mysql is primarily aimed at a server workload and not an on-demand workload. Any service that primarily services remote systems instead of local applications will probably want to start up fully at boot and not on demand later. I guess that's sort of the sane boundary for me with regard to socket activiation. If a service wants to see the outside world via tcp sockets...probably should not be on-demand by default. If its unix socket only..it can probably be a socket activated service. There will be of course things that break that simple rule..but as I guide I think it will work as a starting point for service packagers. -jef
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
