Re: [HEADS-UP] systemd for F14 - the next steps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 22, 2010 at 8:52 AM, drago01 <drago01@xxxxxxxxx> wrote:
> On Thu, Jul 22, 2010 at 3:22 PM, Matthew Miller <mattdm@xxxxxxxxxx> wrote:
>
>> (And
>> that those who have to pay this cost are "crying".)
>
> Everyone has to pay this cost and everyone gets something in return.

That's not what you are hearing from the system administrators on the
list - especially those that manage larger groups of systems, or
manage systems where there are several distributions in place.

For the sysadmins who manage large groups of systems, what is the
inherent benefit to systemd? All I've seen is alot of "hey, this is a
cool feature and you should like it", and not alot of "this
feature/capability will help with this specific problem".

And there isn't much discussion on how implementing systemd will
impact the traditional uses and implementation of a server system -
things like:

- application servers with connection pooling to databases to reduce
response time. The "systemd manages the connections" seems to go
against the current setups where the application handles manages the
application server processes depending on parameters in the
connection. How does the philosophy of having systemd start a process
for each connection impact server response time for normal operations.
Decreasing startup time is a nice-to-have - making sure the server
responds as fast as possible during normal operations is required.

- shared realms/shared memory for session tracking and
inter-application communications

- database startup and connections. I wouldn't want the Oracle or
MySQL listeners start up with each connection, there's way too much
overhead in that part of the process

- monitoring (the port checking that many monitoring systems use will
not work well with the "systemd manages the port and starts the
service when it gets the connection" that I've seen described here.
This is especially important when looking at high availability, where
you need to know that you don't just get a connection, but you
actually talk to the application that's supposed to be listening on
that port.

I'm sure there are other areas, but those are the first things that
came to my mind.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux