Am 24.08.2011 20:40, schrieb Adam Williamson:
On Wed, 2011-08-24 at 19:59 +0200, Lennart Poettering wrote:
On Wed, 24.08.11 10:05, Adam Williamson (awill...@redhat.com) wrote:
FWIW, I do think that there may be use-cases for socket activation of a
database. I'd like to support the option
Actually there is another reason for socket activation to use AF_INET as
well as AF_UNIX: doing so prevents e.g. rpc.statd from port-squatting.
In fact, this is why CUPS no longer ships to ship a portreserve file.
Tim.
*/
signature.asc
Description: This is a digitally signed message part
--
On 24 August 2011 01:35, JB jb.1234a...@gmail.com wrote:
...do not expect them to accept your sick world domination drive
...and this is why some upstream developers have unsubscribed from
fedora-devel list. Ever wonder why people like David Zeuthen
unsubscribed? People like you.
I'm also ---
On Tue, Aug 23, 2011 at 06:11:45PM -0400, Tom Lane wrote:
Another way of saying this is: people are used to being able to check
if a service is up without thereby changing its state. Consider for
example somebody who has a nagios alert set to check database server
availability every few
Richard Hughes hughsient at gmail.com writes:
On 24 August 2011 01:35, JB jb.1234abcd at gmail.com wrote:
...do not expect them to accept your sick world domination drive
...and this is why some upstream developers have unsubscribed from
fedora-devel list. Ever wonder why people like
On Wed, Aug 24, 2011 at 12:18:57PM +, JB wrote:
Richard Hughes hughsient at gmail.com writes:
On 24 August 2011 01:35, JB jb.1234abcd at gmail.com wrote:
...do not expect them to accept your sick world domination drive
...and this is why some upstream developers have
JB jb.1234abcd at gmail.com writes:
...
There is a video on Youtube (I can not find the link right now, it is on
www.osnews.com article in comments section) from a German Linux sysadmin
presentation in Munich, in 2009 I believe - with Lennart present in
the audience and constantly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/08/11 14:18, JB wrote:
This guy is a loose cannon, with an outsized ego, but lacking UNIX
understanding and design skills.
Ok, it's getting clear, both of you won't become best friends.
Assuming, all arguments were written to this list,
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
Simo Sorce s...@redhat.com writes:
... If instead the socket is listening but not really accepting and
processing requests, then yes, you can have a deadlock.
So socket activation is not transparent by any means and needs to be
handled
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/23/2011 10:58 PM, Kevin Kofler wrote:
Steve Grubb wrote:
I think it was mentioned before that systemd is consuming a lot
of memory.
The amount quoted was actually ridiculously small considering both
today's memory sizes and the fact that
On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote:
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
Simo Sorce s...@redhat.com writes:
... If instead the socket is listening but not really accepting and
processing requests, then yes, you can have a deadlock.
So socket
On Wed, 2011-08-24 at 09:05 -0400, Daniel J Walsh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/23/2011 10:58 PM, Kevin Kofler wrote:
Steve Grubb wrote:
I think it was mentioned before that systemd is consuming a lot
of memory.
The amount quoted was actually
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote:
Why not?
If the service is enabled but the daemon not currently running, is it so
terrible for a connection test to cause the daemon to start? Remember,
in systemd
Am 24.08.2011 15:04, schrieb Simo Sorce:
I fail to see any reason why you would want to socket-activate a
database. Either you need the database, so it should start asap, or
don't
because systemd as shipped with F15 CAN NOT make sure that if it
means i have started mysql mysqld is ready for
Am 23.08.2011 23:28, schrieb Tom Lane:
Yeah. Another way in which socket activation is not transparent is that
code might try to determine whether the service is running by seeing
whether a connection attempt succeeds.
well if you have enabled the service and a listening socket
it is the
FYI, I have placed JB on moderation on this list.
I'll be happy to let through posts that are not personal attacks.
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote:
Why not?
If the service is enabled but the daemon not currently running, is it so
terrible for a
Hi,
On 08/24/2011 04:56 PM, Simo Sorce wrote:
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote:
Why not?
If the service is enabled but the daemon not currently
Simo Sorce s...@redhat.com writes:
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
It generally is a bad idea to automatically restart a database based on
a random connection. There many reasons why you may have stopped the
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote:
Simo Sorce s...@redhat.com writes:
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
It generally is a bad idea to automatically restart a database based on
a random
On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote:
If the service is enabled but the daemon not currently running, is it so
terrible for a connection test to cause the daemon to start? Remember,
in systemd logic 'service enabled with socket activation, daemon not
currently running' is
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote:
Simo Sorce s...@redhat.com writes:
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
It generally is a bad idea to automatically restart a database based on
a random
On Aug 24, 2011, at 10:05 AM, Adam Williamson wrote:
On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote:
Simo Sorce s...@redhat.com writes:
On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote:
On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote:
It generally is a bad idea to
On 20:17:14 Wednesday 24 August 2011 Adam Williamson wrote:
On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote:
If the service is enabled but the daemon not currently running, is it
so terrible for a connection test to cause the daemon to start?
Remember, in systemd logic 'service
On Wed, Aug 24, 2011 at 9:22 AM, Alexander Kurtakov akurt...@redhat.comwrote:
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
On Wed, 24.08.11 10:45, Tom Lane (t...@redhat.com) wrote:
Reindl Harald h.rei...@thelounge.net writes:
Am 23.08.2011 23:28, schrieb Tom Lane:
there's no other way for mysqladmin ping to work, for example
and where is the problem?
I'm not planning on repeating myself either, but: a
On Tue, Aug 23, 2011 at 06:14:34PM +0200, Lennart Poettering wrote:
systemctl list-unit-files is what you are looking for. It's simpler even
than chkconfig --list.
When I run systemctl list-unit-files, I get a Unknown operation
list-unit-files error. Did you mean systemctl list-units?
--
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.comwrote:
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
On Wed, 24.08.11 10:56, Simo Sorce (s...@redhat.com) wrote:
a random connection. There many reasons why you may have stopped the db
(or it may have stopped itself) and requires inspection before
attempting a new restart. Having to battle with socket activation while
in a critical
On Wed, 24.08.11 11:40, Andrew McNabb (amcn...@mcnabbs.org) wrote:
On Tue, Aug 23, 2011 at 06:14:34PM +0200, Lennart Poettering wrote:
systemctl list-unit-files is what you are looking for. It's simpler even
than chkconfig --list.
When I run systemctl list-unit-files, I get a Unknown
On Wed, 24.08.11 10:05, Adam Williamson (awill...@redhat.com) wrote:
FWIW, I do think that there may be use-cases for socket activation of a
database. I'd like to support the option ... the problem is to do so
without breaking existing, expected behaviors.
It was noted up-thread that
On Wed, 24.08.11 20:22, Alexander Kurtakov (akurt...@redhat.com) wrote:
On 20:17:14 Wednesday 24 August 2011 Adam Williamson wrote:
On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote:
If the service is enabled but the daemon not currently running, is it
so terrible for a connection
On Wed, 24.08.11 10:10, Jesse Keating (jkeat...@j2solutions.net) wrote:
FWIW, I do think that there may be use-cases for socket activation of a
database. I'd like to support the option ... the problem is to do so
without breaking existing, expected behaviors.
It was noted up-thread
On Wed, 2011-08-24 at 19:44 +0200, Lennart Poettering wrote:
On Wed, 24.08.11 10:56, Simo Sorce (s...@redhat.com) wrote:
a random connection. There many reasons why you may have stopped the db
(or it may have stopped itself) and requires inspection before
attempting a new restart.
On Wed, 2011-08-24 at 20:19 +0200, Lennart Poettering wrote:
On Wed, 24.08.11 10:10, Jesse Keating (jkeat...@j2solutions.net) wrote:
FWIW, I do think that there may be use-cases for socket activation of a
database. I'd like to support the option ... the problem is to do so
without
On Wed, 2011-08-24 at 19:59 +0200, Lennart Poettering wrote:
On Wed, 24.08.11 10:05, Adam Williamson (awill...@redhat.com) wrote:
FWIW, I do think that there may be use-cases for socket activation of a
database. I'd like to support the option ... the problem is to do so
without
On Aug 24, 2011, at 11:19 AM, Lennart Poettering wrote:
On Wed, 24.08.11 10:10, Jesse Keating (jkeat...@j2solutions.net) wrote:
FWIW, I do think that there may be use-cases for socket activation of a
database. I'd like to support the option ... the problem is to do so
without breaking
Jesse Keating (jkeat...@j2solutions.net) said:
Some of the argument here is that it is difficult to do this from a remote
host. You'd have to engage in remote execution of software, e.g. using
nagios nrpe to remotely (from the nagios system) execute commands on the
database system to call
On Wednesday, August 24, 2011 11:52:23 AM Jesse Keating wrote:
That would require your nagios (or other monitoring) system to be running
systemd, which may not be the case for quite a while :)
Why? When used to access remote machines systemctl shouldn't require running
systemd locally.
Lars
On Aug 24, 2011, at 1:33 PM, Lars Seipel wrote:
On Wednesday, August 24, 2011 11:52:23 AM Jesse Keating wrote:
That would require your nagios (or other monitoring) system to be running
systemd, which may not be the case for quite a while :)
Why? When used to access remote machines
On Aug 24, 2011, at 12:49 PM, Bill Nottingham wrote:
Jesse Keating (jkeat...@j2solutions.net) said:
Some of the argument here is that it is difficult to do this from a remote
host. You'd have to engage in remote execution of software, e.g. using
nagios nrpe to remotely (from the nagios
On Mon, 22.08.11 21:22, Jef Spaleta (jspal...@gmail.com) wrote:
On Mon, Aug 22, 2011 at 4:32 PM, Lennart Poettering
mzerq...@0pointer.dewrote:
In fact, systemd offers quite a number security features to secure your
services wich can be easily used to enhance local security. I'll
On 23 August 2011 01:32, Lennart Poettering mzerq...@0pointer.de wrote:
This is something we should
set for a number of services which never should get network access, like
upower, dbus, or colord.
As the upstream for two of those, what do I need to do? At the moment
both upower and colord are
On Tue, 23.08.11 11:53, Richard Hughes (hughsi...@gmail.com) wrote:
On 23 August 2011 01:32, Lennart Poettering mzerq...@0pointer.de wrote:
This is something we should
set for a number of services which never should get network access, like
upower, dbus, or colord.
As the upstream for
On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway tcall...@redhat.com wrote:
On 08/18/2011 06:28 AM, Lennart Poettering wrote:
On Wed, 17.08.11 16:43, Tim Waugh (twa...@redhat.com) wrote:
Oh, I just noticed this:
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation
On 23 August 2011 12:01, Lennart Poettering mzerq...@0pointer.de wrote:
I'll blog about it and use colord as an example. I'll ping you when I
have done that.
Legend, thanks.
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Monday, August 22, 2011 08:32:57 PM Lennart Poettering wrote:
On Mon, 22.08.11 17:19, Adam Williamson (awill...@redhat.com) wrote:
On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote:
On 08/22/2011 07:07 PM, Adam Williamson wrote:
On Sun, 2011-08-21 at 17:09 -0400, Steve Clark
On 08/22/2011 06:20 PM, Reindl Harald wrote:
and finally this idiotic discussion should have been
finished BEFORE release F15 wth sytemd and not at a
time where it is defacto too late because no one is gonna
fixing the bugs and wrong decisions for F15 this time
Mr. Harald,
This sort of tone
On 08/18/2011 06:29 PM, Lennart Poettering wrote:
Unlikely. CUPS is not that slow. I mean, if the dialog takes a second or
so this would still be completely fine, but in real life CUPS starts
much faster. On my machine it is very hard to see any difference at all
if I run lpq on a shell when
On Tue, Aug 23, 2011 at 01:12:31PM +0200, drago01 wrote:
On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway tcall...@redhat.com wrote:
On 08/18/2011 06:28 AM, Lennart Poettering wrote:
On Wed, 17.08.11 16:43, Tim Waugh (twa...@redhat.com) wrote:
Oh, I just noticed this:
On Tue, 23.08.11 07:29, Toshio Kuratomi (a.bad...@gmail.com) wrote:
I think FESCo needs to decide what its policies are wrt on-demand
loading, then we can adjust the Packaging Guidelines appropriately.
This is broken IMO ... there is nothing inherently wrong with on
demand loading
On Tue, 2011-08-23 at 16:57 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 07:29, Toshio Kuratomi (a.bad...@gmail.com) wrote:
I think FESCo needs to decide what its policies are wrt on-demand
loading, then we can adjust the Packaging Guidelines appropriately.
This is broken
On Tue, 23.08.11 11:10, Simo Sorce (s...@redhat.com) wrote:
I am pretty sure that 95% of everybody who has ssd or CUPS installed
will not use it more often than than 1/h, which is really seldom. Hence
I'd make these services socket activated by default (like MacOS does it
too), and for
On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 11:10, Simo Sorce (s...@redhat.com) wrote:
I am pretty sure that 95% of everybody who has ssd or CUPS installed
will not use it more often than than 1/h, which is really seldom. Hence
I'd make these services
On Tue, 23.08.11 11:56, Simo Sorce (s...@redhat.com) wrote:
On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 11:10, Simo Sorce (s...@redhat.com) wrote:
I am pretty sure that 95% of everybody who has ssd or CUPS installed
will not use it more often than
On Tue, 2011-08-23 at 18:14 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 11:56, Simo Sorce (s...@redhat.com) wrote:
On Tue, 2011-08-23 at 17:44 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 11:10, Simo Sorce (s...@redhat.com) wrote:
I am pretty sure that 95% of
On Tue, 2011-08-23 at 07:29 -0700, Toshio Kuratomi wrote:
This is broken IMO ... there is nothing inherently wrong with on
demand loading ... actually it is the opposite. (i.e should be done
whenever possible).
On demand loading is great. But the system administrator needs to have
JB jb.1234abcd at gmail.com writes:
...
Here are some more detailed thoughts.
Sys init.
-
Sys init as a process #1 should be beyond approach by design, and delegate
all work to other process(es), whether in a permanent or an ad-hoc manner,
that can be operated by sysadmin if needed
On 08/23/2011 01:48 PM, JB wrote:
JBjb.1234abcdat gmail.com writes:
...
Here are some more detailed thoughts.
Sys init.
-
Sys init as a process #1 should be beyond approach by design, and delegate
all work to other process(es), whether in a permanent or an ad-hoc manner,
that can
Adam Williamson awilliam at redhat.com writes:
On Tue, 2011-08-23 at 07:29 -0700, Toshio Kuratomi wrote:
This is broken IMO ... there is nothing inherently wrong with on
demand loading ... actually it is the opposite. (i.e should be done
whenever possible).
On demand loading is
Steve Clark sclark at netwolves.com writes:
...
Sys init.
-
Sys init as a process #1 should be beyond approach by design, and delegate
all work to other process(es), whether in a permanent or an ad-hoc manner,
that can be operated by sysadmin if needed (e.g. restarted,
On Tue, 23.08.11 17:48, JB (jb.1234a...@gmail.com) wrote:
Systemd and security - an example # 2 of an attack venue.
-
The above is dangerous as a design idea to achieve parallelization of
services.
Let's assume that service A is a
Tom Callaway (tcall...@redhat.com) said:
On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
I'm pretty sure that we kicked this up to FESCo and they decided to treat
them the same (although the latter may not have come to a formal vote and
only been discussed during their IRC meetings on the
On Tue, Aug 23, 2011 at 13:37, Bill Nottingham nott...@redhat.com wrote:
Tom Callaway (tcall...@redhat.com) said:
On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
I'm pretty sure that we kicked this up to FESCo and they decided to treat
them the same (although the latter may not have come to a
On Tue, 23.08.11 13:54, Stephen John Smoogen (smo...@gmail.com) wrote:
On Tue, Aug 23, 2011 at 13:37, Bill Nottingham nott...@redhat.com wrote:
Tom Callaway (tcall...@redhat.com) said:
On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
I'm pretty sure that we kicked this up to FESCo and
On Tue, Aug 23, 2011 at 4:29 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
On Tue, Aug 23, 2011 at 01:12:31PM +0200, drago01 wrote:
On Mon, Aug 22, 2011 at 6:45 PM, Tom Callaway tcall...@redhat.com wrote:
On 08/18/2011 06:28 AM, Lennart Poettering wrote:
On Wed, 17.08.11 16:43, Tim Waugh
Stephen John Smoogen (smo...@gmail.com) said:
A socket-activated service is much the same as a non-socket-activated
service, in that installing the unit won't activate the service unless
something calls for it, or the admin/rpm scripts run 'systemctl enable'. So
A couple of questions:
On Tue, 2011-08-23 at 21:33 +0200, Lennart Poettering wrote:
On Tue, 23.08.11 17:48, JB (jb.1234a...@gmail.com) wrote:
Systemd and security - an example # 2 of an attack venue.
-
The above is dangerous as a design idea to achieve
Lennart Poettering mzerqung at 0pointer.de writes:
On Tue, 23.08.11 17:48, JB (jb.1234abcd at gmail.com) wrote:
Systemd and security - an example # 2 of an attack venue.
-
The above is dangerous as a design idea to achieve
Simo Sorce s...@redhat.com writes:
... If instead the socket is listening but not really accepting and
processing requests, then yes, you can have a deadlock.
So socket activation is not transparent by any means and needs to be
handled very carefully in terms of circular dependencies as they
JB wrote:
This does not help in this case. The attack's effect can happen at any time
and catch systemd with its pants down at any time in the scenarios you
described.
The attack is on socket buffer availability via kernel, it lasts until no
resource is available system-wide. At that point
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
Simo Sorce s...@redhat.com writes:
... If instead the socket is listening but not really accepting and
processing requests, then yes, you can have a deadlock.
So socket activation is not transparent by any means and needs to be
handled
Björn Persson bjorn at xn--rombobjrn-67a.se writes:
JB wrote:
This does not help in this case. The attack's effect can happen at any time
and catch systemd with its pants down at any time in the scenarios you
described.
The attack is on socket buffer availability via kernel, it lasts
Adam Williamson awill...@redhat.com writes:
On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
Yeah. Another way in which socket activation is not transparent is that
code might try to determine whether the service is running by seeing
whether a connection attempt succeeds. In such a case,
Mathieu Bridon wrote:
Well, socket activation gives you better speed and resource usage as
already mentioned, but it also gives you:
[some really nifty features]
So basically, much improved service availability (which is what matters
to your business, isn't it?), and easier
On Tue, 23.08.11 18:11, Tom Lane (t...@redhat.com) wrote:
I think that one of the worst aspects of systemd is its assumption that
it can force new world-views upon every other piece of software in the
system :-(. But anyway, here's an example of why this is a problem:
when we tried to code
On Tue, 2011-08-23 at 18:11 -0400, Tom Lane wrote:
Another way of saying this is: people are used to being able to check
if a service is up without thereby changing its state. Consider for
Well, again, it's arguable that this describes the systemd case. You
have not changed the state of *the
On Wed, 24.08.11 00:24, Björn Persson (bjorn@rombobjörn.se) wrote:
Mathieu Bridon wrote:
Well, socket activation gives you better speed and resource usage as
already mentioned, but it also gives you:
[some really nifty features]
So basically, much improved service availability
JB wrote:
Björn Persson bjorn at xn--rombobjrn-67a.se writes:
JB wrote:
This does not help in this case. The attack's effect can happen at any
time and catch systemd with its pants down at any time in the
scenarios you described.
The attack is on socket buffer availability via
On Wed, Aug 24, 2011 at 1:03 AM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Wed, 24.08.11 00:24, Björn Persson (bjorn@rombobjörn.se) wrote:
Imagine a stripped-down Init that does only two things: First it forks and
executes SystemD, and then it just sits around and reaps orphan zombies.
Lennart Poettering mzerqung at 0pointer.de writes:
...
I really honestly wished the troupe of you four or five people who keep
trying to noisily shoot systemd down on fedora-devel would actually try
to understand what is going on. Try to get the bigger picture. Try for
once to see if there
On 08/24/2011 06:05 AM, JB wrote:
Lennart,
we are not going to sacrify UNIX/Linux, SysVinit, even systemd (the product
of you, your co-developers, and ... imported ideas from one song for one USD
company) for your ego, which is larger than life.
This type of personal attacks in this list is
Lennart, please don't shut off and stop listening just yet.
I realize that your rant was aimed at this whole thread rather than at my post
specifically, but I'd like to make it clear that I'm not one of those who keep
trying to noisily shoot systemd down as you put it. I see a lot of value in
Steve Grubb wrote:
I think it was mentioned before that systemd is consuming a lot of memory.
The amount quoted was actually ridiculously small considering both today's
memory sizes and the fact that systemd is a singleton process.
Plus, it can be reduced even further (by something like 90%!)
Am 21.08.2011 23:09, schrieb Steve Clark:
Read the part about Parallelizing Socket Services. It explains why
socket actviation is interesting,
I find a secure OS interesting. Bootup speed does not matter much to me.
-Steve
Obviously a lot on this list value boot up speed over security!
Steve Grubb sgrubb at redhat.com writes:
...
You're not seeing the hundreds - no thousands of emails about systemd?
You are not seeing that all the expected facilities of init are not covered?
There is well founded rebellion here.
...
Yes, you are right. And the people (e-mails, posts) you
On 08/18/2011 06:28 AM, Lennart Poettering wrote:
On Wed, 17.08.11 16:43, Tim Waugh (twa...@redhat.com) wrote:
Oh, I just noticed this:
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation
Since Fedora currently doesn't want any services to do on-demand
loading, all
On 08/22/2011 12:03 PM, JB wrote:
Steve Grubbsgrubbat redhat.com writes:
...
You're not seeing the hundreds - no thousands of emails about systemd?
You are not seeing that all the expected facilities of init are not covered?
There is well founded rebellion here.
...
Yes, you are right. And
On Mon, Aug 22, 2011 at 12:45:40PM -0400, Tom Callaway wrote:
On 08/18/2011 06:28 AM, Lennart Poettering wrote:
On Wed, 17.08.11 16:43, Tim Waugh (twa...@redhat.com) wrote:
Oh, I just noticed this:
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation
Since
On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
I'm pretty sure that we kicked this up to FESCo and they decided to treat
them the same (although the latter may not have come to a formal vote and
only been discussed during their IRC meetings on the overall subject.) Going
back to the quote in
On Mon, 22.08.11 15:09, Tom Callaway (tcall...@redhat.com) wrote:
On 08/22/2011 01:29 PM, Toshio Kuratomi wrote:
I'm pretty sure that we kicked this up to FESCo and they decided to treat
them the same (although the latter may not have come to a formal vote and
only been discussed during
On 08/22/2011 04:41 PM, Lennart Poettering wrote:
I'd vote for simply making this an implementation detail of the
package. I.e. if a package gets the permission to enable its service by
default it's up to it whether it wants to be started at boot or via
socket actviation of via any other kind
Am 22.08.2011 23:01, schrieb Tom Callaway:
On 08/22/2011 04:41 PM, Lennart Poettering wrote:
I'd vote for simply making this an implementation detail of the
package. I.e. if a package gets the permission to enable its service by
default it's up to it whether it wants to be started at boot or
On Mon, 22 Aug 2011 23:15:38 +0200
Reindl Harald h.rei...@thelounge.net wrote:
Am 22.08.2011 23:01, schrieb Tom Callaway:
On 08/22/2011 04:41 PM, Lennart Poettering wrote:
I'd vote for simply making this an implementation detail of the
package. I.e. if a package gets the permission to
Am 22.08.2011 23:58, schrieb Kevin Fenzi:
On Mon, 22 Aug 2011 23:15:38 +0200
Reindl Harald h.rei...@thelounge.net wrote:
Am 22.08.2011 23:01, schrieb Tom Callaway:
On 08/22/2011 04:41 PM, Lennart Poettering wrote:
I'd vote for simply making this an implementation detail of the
package.
On Sun, 2011-08-21 at 20:34 -0400, Steve Grubb wrote:
You're not seeing the hundreds - no thousands of emails about systemd? You
are not
Most of which seem to come from you, Reindl, or Steve Clark; a very
active cabal doth not a rebellion make.
--
Adam Williamson
Fedora QA Community Monkey
On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
-Steve
Obviously a lot on this list value boot up speed over security!
You're making a false assumption, which is that socket activation is
only about speed. It's also about resource usage. (There may be other
advantages I haven't
On 08/22/2011 07:07 PM, Adam Williamson wrote:
On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
-Steve
Obviously a lot on this list value boot up speed over security!
You're making a false assumption, which is that socket activation is
only about speed. It's also about resource
On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote:
On 08/22/2011 07:07 PM, Adam Williamson wrote:
On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
-Steve
Obviously a lot on this list value boot up speed over security!
You're making a false assumption, which is that
On Mon, 22.08.11 17:19, Adam Williamson (awill...@redhat.com) wrote:
On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote:
On 08/22/2011 07:07 PM, Adam Williamson wrote:
On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote:
-Steve
Obviously a lot on this list value boot up
1 - 100 of 151 matches
Mail list logo
