Hello Ron, thank you for the fast reply.
On Thu, Aug 07, 2014 at 01:28:16AM +0930, Ron wrote: > > > > Hello, > > > > I prefer to run tftpd-hpa from inetd. > > Just for my own better understanding of who uses this how, and why, > can I ask what your reasons for that are? I use it rarely, only for netbooting things once in a while, where tftp is only available protocol for bootstrapping. I have other services running as well from inetd, and just like to avoid yet another process hanging around without reason for 99% of the time. The arguments become more aesthetically with recent hardware than actually a resource question, though. > > > > Unfortunately, the provided config and init scripts start it > > unconditionally as standalone. > > Apparently there used to be support for this, but it was removed in > 2009, and Daniel noted in the changelog: > > * Now running always in daemon mode, it is too error prone and messy > to support inetd mode (Closes: #272882, #275514, #437651, #503120, > #505335, #505367, #535212, #537476). > > I haven't looked at what the real problems with this were myself in any > detail (aside from noting that sure is a long list of bugs :), but my I have not read them neither; I only know that not all system scripts support all versions of (x)inetd configs equally well. > own initial thoughts on this go something like: > > - tftpd is tiny, weighing around 300k in RSS when it isn't swapped out > because nothing is using it and something else really needs that last > ounce of memory. If you haven't already disabled all of the several > tmpfs mounts you get by default these days, this one is the least of > your worries for "wasted" memory on a modern machine. The memory is not the argument, I am more concerned with partly too volatile storage for filesystems. But that is a different story. > - inetd itself is potentially Not Long For This World anymore. You'd > have a rather hard time installing and running the jessie release on > any of the sort of resource limited machines that were the problem > it was invented to solve. These days fast, large disks are ordinary > and whether you store your idle daemons in swap or on the filesystem > proper doesn't make a whole lot of real difference to the system > resources that remain available for active tasks. I like inetd.conf as a central config file for the behaviour of a bunch of small services. > > - Even if the last point wasn't true, for jessie systemd will be the > default init, and since it's basically just a glorified reinvention > of inetd itself, running as PID1, that's probably the last nail in > its coffin now. If someone really wants this mode, a better change > would probably be to offer a 'socket activation' unit for it now, > which is just a fancy word and different location for 'inetd.conf'. > I'll take a patch for that if somebody has the interest to make and > test one. While admitting that the sysv-init is improvable, systemd IMHO contradicts the unix philosophy (small tool with deciated purpose instead of one big multipurpose tool that does not really fit, e.g. insising that a service is started and therefore refusing to execute a start again because the pid file is there without checking that the correspending daemon might have died). But then again, systemd is a different story in itself. I'll think about the socket activation unit, anyway. > > > But that said ... > > > I would appreciate inetd support in the maintainer scipts, or if > > that is too complex, > > this: > > > an option to install tftpd-hpa but not start > > it by default, e.g. in /etc/default/tftpd-hpa TFTP_START=no > > is already possible. Just put 'exit 0' into that file and the init > script won't start it. It's just sourced as a shell snippet, so you > can abort its action there any way you like (or use update-rc.d to > change the runlevels that it is started in to suit what you need). That sounds to me too much like a hack, although it works for the time being. I'd prefer an option for it, and it could be added in a line in the init script. There I can offer a patch immediately ( [ "$TFTP_START" != "no" ] || exit 0 ;-) Runlevels are sometimes changed on package upgrades/reinstalls. Nevertheless it is not so hackish IMHO ;-) > So unless you have some compelling reason I haven't thought of for > why inetd itself isn't now living on borrowed time, I'm inclined to > think the time for adding support for it to this package is now > somewhat long past ... though it is still fairly trivial to add it > manually yourself for anyone who really wants that for a bit longer. That is coming close to my point. No problem with maintaining inetd.conf by myself, just not being forced by the init scripts to use same hackish approach would be great to give users the freedom of choice while bearing almost no complexity for the maintainer. Bye, Joerg
signature.asc
Description: Digital signature
