Re: Xinetd resurrection
2009/9/20 Lorenzo Villani : > On 09/20/2009 06:28 PM, Steve Grubb wrote: >> >> Not at all. These days the only need for xinetd is in memory constrained >> systems. For mainline x86_64 bought with typically 4Gb of main memory, >> xinetd >> is a thing of the past. That's my point. >> > Well, I am probably part of that 0.01% who would like some services to > start on-demand. > For example I don't print all the time and I prefer to have cups start only > when needed, then die instead of having it waiting for no real purpose. Now, > this is a case in which it doesn't make sense (you start xinetd instead of > cups for no real gain) but it can be useful with some setups. > > Even if I have a quad-core system with 4Gb of memory available I always > prefer to find a better use for it. Let's be theoretical here for a second. In our von neumann machine architecture, a process needs to be initialized, where the code and data are read off the slow storage into the fast storage, the code path is executed, and the run time state is set up. In order to use the service, this process always has to happen. While the process, a certain amount of memory has to be used. These are fundamental issues that apply to how we use von neumann machines. You're discussing the process of managing the lifecycle of this core process. When loading cups on startup, as a standalone process, this process is done once, and then the results are stored in the memory. When the system runs out of memory, the state of the program is pushed back to the slow storage in the form of swap. Assuming the process is swapped out between every run, you incur the expensive cost of reloading the state from the hard drive. You don't incur the cost of reinitializing the state, although there might be some relatively minor overhead (OS handling swapping of processes, the process updating it's state in case something else on the system has changed since the process was paused). In the best case scenario, this never occurs, but then a few precious megabytes of your 4GB (everyone should be so lucky) are taken up. If you have 4GB, not swapping and keeping the process in runtime memory will give you the most responsiveness. If you're an end user, this is probably what you want. If you have less, you have to make a decision. Do we load it on start and swap it out, or do we manage it on demand. You're basically asking this question. Given the costs, you're really asking the wrong question as an end user. It really doesn't matter at all. To the end user, you're offering the user too much choice, where the end user is not educated enough to know the difference, doesn't care, and just wants printing to work. Of course, there are a number of other benefits to using inetd or xinetd pointed out in this thread. Assuming your services are KISS compliant, meaning they're lightweight, doing everything on demand is The Right Thing (tm). (Proving this is left as an exercise to the reader.) -Yaakov -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
Dne neděle 20 září 2009 18:28:14 Steve Grubb napsal(a): > On Saturday 19 September 2009 07:25:13 pm Matej Cepl wrote: > > Steve Grubb, Fri, 18 Sep 2009 08:24:18 -0400: > > > I also think that the reason xinetd came into existence in the first > > > place has long since passed. > > > > Do you think that Fedora should humbly return with a cap in hand to > > inetd? > > Not at all. These days the only need for xinetd is in memory constrained > systems. For mainline x86_64 bought with typically 4Gb of main memory, > xinetd is a thing of the past. That's my point. Another use for xinetd could be for power saving. When I discussed this with power management guys, we agreed starting daemons on-demand could reduce power consumption on some systems considerably. - Jan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Sun, Sep 20, 2009 at 11:46 PM, Martin Langhoff wrote: > On Sun, Sep 20, 2009 at 1:24 AM, Matej Cepl wrote: > > Martin Langhoff, Fri, 18 Sep 2009 17:29:48 +0200: > >> In other words, xinetd is a saviour when you are running OLPC's School > >> Servers :-) > > > > That's not the point Steve was trying to make (I guess) ... what you need > > could be easily as well accomplished by its predecessory inetd server > > I've used both. xinetd has lots of useful features (conf.d-style > config, rate limiting, etc). My understanding was that it aimed at > being a better inetd, and within those goals, it definitily does the > trick. And anyone taking on xinetd maintainership has my respect and a > few beers next time we meet. > > Maybe inetd has grown all those same features in the meantime? If it > does, the manpage I have at hand right now doesn't know about it. > > Someone have ever looked or considered Apple launchd ? > cheers, > > > > m > > > > > which does bascially the same thing (and is default on Debian for > > example, http://packages.debian.org/sid/inetutils-inetd). > > > > Matěj > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list@redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Sun, Sep 20, 2009 at 1:24 AM, Matej Cepl wrote: > Martin Langhoff, Fri, 18 Sep 2009 17:29:48 +0200: >> In other words, xinetd is a saviour when you are running OLPC's School >> Servers :-) > > That's not the point Steve was trying to make (I guess) ... what you need > could be easily as well accomplished by its predecessory inetd server I've used both. xinetd has lots of useful features (conf.d-style config, rate limiting, etc). My understanding was that it aimed at being a better inetd, and within those goals, it definitily does the trick. And anyone taking on xinetd maintainership has my respect and a few beers next time we meet. Maybe inetd has grown all those same features in the meantime? If it does, the manpage I have at hand right now doesn't know about it. cheers, m > which does bascially the same thing (and is default on Debian for > example, http://packages.debian.org/sid/inetutils-inetd). > > Matěj > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Sun, Sep 20, 2009 at 7:40 PM, Lorenzo Villani wrote: > On 09/20/2009 06:28 PM, Steve Grubb wrote: > >> >> Not at all. These days the only need for xinetd is in memory constrained >> systems. For mainline x86_64 bought with typically 4Gb of main memory, >> xinetd >> is a thing of the past. That's my point. >> >> Well, I am probably part of that 0.01% who would like some services > to start on-demand. > For example I don't print all the time and I prefer to have cups start only > when needed, then die instead of having it waiting for no real purpose. Now, > this is a case in which it doesn't make sense (you start xinetd instead of > cups for no real gain) but it can be useful with some setups. > > Even if I have a quad-core system with 4Gb of memory available I always > prefer to find a better use for it. > > What about launchd ? http://en.wikipedia.org/wiki/Launchd http://developer.apple.com/macosx/launchd.html Sound good But it really have MUCH more functionality of xinetd (or the old inetd) > -- > Lorenzo V. > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On 09/20/2009 06:28 PM, Steve Grubb wrote: Not at all. These days the only need for xinetd is in memory constrained systems. For mainline x86_64 bought with typically 4Gb of main memory, xinetd is a thing of the past. That's my point. Well, I am probably part of that 0.01% who would like some services to start on-demand. For example I don't print all the time and I prefer to have cups start only when needed, then die instead of having it waiting for no real purpose. Now, this is a case in which it doesn't make sense (you start xinetd instead of cups for no real gain) but it can be useful with some setups. Even if I have a quad-core system with 4Gb of memory available I always prefer to find a better use for it. -- Lorenzo V. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Saturday 19 September 2009 07:25:13 pm Matej Cepl wrote: > Steve Grubb, Fri, 18 Sep 2009 08:24:18 -0400: > > I also think that the reason xinetd came into existence in the first > > place has long since passed. > > Do you think that Fedora should humbly return with a cap in hand to inetd? Not at all. These days the only need for xinetd is in memory constrained systems. For mainline x86_64 bought with typically 4Gb of main memory, xinetd is a thing of the past. That's my point. If more work is done on xinetd, the new devs should think about how much memory any new feature would add. I would look at the functions in the lib directory and scuttle anything I could to make xinetd smaller and more memory efficient. I wanted to do some of this in the past where it could use native glibc functionality on Linux and portable functions elsewhere. But the project leader wanted to use compat functions on all platforms so any bug reports aren't platform specific. In any new development, I would forgo supporting the Cray, SunOS, and True64 in favor of smaller footprint on modern OS. They can still use the old xinetd. xinetd could be put on a diet and made better. For example, the ident protocol is useless from a security PoV. All that code could be dropped. The config parser is huge. That code could be dlopened and then dropped once the daemon is running. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On 09/20/2009 01:32 AM, King InuYasha wrote: Is Fedora still using xinetd? I thought we moved to something like launchd by now? You mean upstart? As far as I know, it doesn't have xinetd-like functionality yet. Lorenzo V. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
Is Fedora still using xinetd? I thought we moved to something like launchd by now? On Sat, Sep 19, 2009 at 6:25 PM, Matej Cepl wrote: > Steve Grubb, Fri, 18 Sep 2009 08:24:18 -0400: > > I also think that the reason xinetd came into existence in the first > > place has long since passed. > > Do you think that Fedora should humbly return with a cap in hand to inetd? > > Matěj > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
Steve Grubb, Fri, 18 Sep 2009 08:24:18 -0400: > I also think that the reason xinetd came into existence in the first > place has long since passed. Do you think that Fedora should humbly return with a cap in hand to inetd? Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
Martin Langhoff, Fri, 18 Sep 2009 17:29:48 +0200: > In other words, xinetd is a saviour when you are running OLPC's School > Servers :-) That's not the point Steve was trying to make (I guess) ... what you need could be easily as well accomplished by its predecessory inetd server which does bascially the same thing (and is default on Debian for example, http://packages.debian.org/sid/inetutils-inetd). Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
Jan Zeleny (jzel...@redhat.com) said: > I'm current maintainer of xinetd in Fedora. Lately I've been inspecting some > major patches and I was informed that upstream is pretty much dead. I think > this project is interesting and it's worth to try to resurrect it. > > My plan is to start project on fedora hosted and basically rebuild the whole > source code, so it is more clean and can be extended/maintained easily if > needed. > > I already have one developer, who is willing to join me. I'd like to know > your > opinion of this project. And of course if there is anybody who would like to > join, just let me know, I'd be happy to gather some more people to work on > this. Active, available maintainers are generally a good thing. I wouldn't worry much about extending it - it's essentially legacy code at this point. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Fri, Sep 18, 2009 at 3:39 PM, Steve Grubb wrote: >> I always thought that one reason for xinetd was the capability of running >> network servers without actually having any network code in the server. > > Its network code, it just doesn't do listen/accept. :) Of course xinetd also > takes care of restricting access a number of ways like time of day , network, > tcp_wrappers, and setting up the uid/group... Yes. I use it to write small network services and not have to worry about implementing all the rate control and access limiting stuff. And some of these services are written in python, and seldom used; xinetd saves a ton of memory. In other words, xinetd is a saviour when you are running OLPC's School Servers :-) m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Friday 18 September 2009 08:34:03 am Ralf Ertzinger wrote: > Hi. > > On Fri, 18 Sep 2009 08:24:18 -0400, Steve Grubb wrote: > > I also think that the reason xinetd came into existence in the first > > place has long since passed. The original intent was to save memory > > by not having half a dozen servers running. (Remember the early > > 1990's systems.) Today we have plenty of memory in computers and the > > reason for xinetd is gone. > > I always thought that one reason for xinetd was the capability of running > network servers without actually having any network code in the server. Its network code, it just doesn't do listen/accept. :) Of course xinetd also takes care of restricting access a number of ways like time of day , network, tcp_wrappers, and setting up the uid/group... Something I forgot to mention earlier, even though I give up any interest in xinetd, you should contact Rob Braun who is the maintainer and verify he has no more interest. I cannot speak for him. Also, another bug that appears sometimes...xinetd has a builtin daytime service. It follows RFC867, which says there is no syntax for the daytime protocol and its use is for *debugging*. It also lists 2 popular formats. Xinetd follows one of the 2 listed, and HPUX / AIX (and likely others) follow the other one. If the RFC were better specified, there would be no conflict. Xinetd's daytime implementation goes back more than 10 years so its got a lot of history in its current format and should stay the default. So, maybe there should be a config option to specify one format or the other for interoperability. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
Hi. On Fri, 18 Sep 2009 08:24:18 -0400, Steve Grubb wrote: > I also think that the reason xinetd came into existence in the first > place has long since passed. The original intent was to save memory > by not having half a dozen servers running. (Remember the early > 1990's systems.) Today we have plenty of memory in computers and the > reason for xinetd is gone. I always thought that one reason for xinetd was the capability of running network servers without actually having any network code in the server. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Friday 18 September 2009 06:04:43 am Jan Safranek wrote: > Don't forget to announce the fork on xinetd mailing list. Its dead. > Also, contacting orginal xinetd maintainer if he is willing to contribute, > e.g. with xinetd.org domain :). I am/was the co-maintainer of xinetd. I hearby relinquish all interest in xinetd. I have more than enough projects to keep me busy. I also think that the reason xinetd came into existence in the first place has long since passed. The original intent was to save memory by not having half a dozen servers running. (Remember the early 1990's systems.) Today we have plenty of memory in computers and the reason for xinetd is gone. A note to anyone taking this on. We had people running xinetd on very old hardware and they expected it to work. If you are going to drop support for the old systems, you might want to name the project xinetd-ng or something to signify that its not the same old code. Also, you can cleanhouse with that portable library and other crazy stuff in the lib directory. There is one serious bug in xinetd that needs fixing that you might want to address. If you have a "wait" service, xinetd does not accept the connection - this is by design. It passes the descriptor for the connection to the child which is required to accept the connection before using the socket. If that program does not accept the connection, it likely cannot read anything and will exit. Xinetd re-enables the listening descriptor and sees the same descriptor in ready state and spawns the same child to handle it. Round and round we go eating up CPU. There needs to be kernel support for looking at a descriptor and seeing its state so that this problem can be handled gracefully. As far as I know, this problem is unique to inetd programs since they pass descriptors to other programs for use. I also think you might want to contact people in altlinux or openwall and see if they are interested in this new project. They expressed some interest in the past - especially if the code footprint can be reduced. They want a smaller, leaner xinetd. Good Luck... -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On 09/18/2009 09:31 AM, Jan Zeleny wrote: Hi all, I'm current maintainer of xinetd in Fedora. Lately I've been inspecting some major patches and I was informed that upstream is pretty much dead. I think this project is interesting and it's worth to try to resurrect it. My plan is to start project on fedora hosted and basically rebuild the whole source code, so it is more clean and can be extended/maintained easily if needed. I suggest you to contact xinetd maintainers in other distros (Debian, Gentoo, SuSE, ...) and try to coordinate the effort. You may get more helping hands and I am pretty sure they have their own patches you might consider to include. Don't forget to announce the fork on xinetd mailing list. Also, contacting orginal xinetd maintainer if he is willing to contribute, e.g. with xinetd.org domain :). Jan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
> On Fri, Sep 18, 2009 at 09:31:49AM +0200, Jan Zeleny wrote: > > I already have one developer, who is willing to join me. I'd like to know > > your opinion of this project. And of course if there is anybody who would > > like to join, just let me know, I'd be happy to gather some more people > > to work on this. > > There is a distributions mailinglist at freedesktop.org, where you could > coordinate with other distributions and fin more interested people. Thanks for the hint Jan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Fri, Sep 18, 2009 at 09:31:49AM +0200, Jan Zeleny wrote: > I already have one developer, who is willing to join me. I'd like to know > your > opinion of this project. And of course if there is anybody who would like to > join, just let me know, I'd be happy to gather some more people to work on > this. There is a distributions mailinglist at freedesktop.org, where you could coordinate with other distributions and fin more interested people. Regards Till -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
