Re: [DNG] [Dng] Readiness notification
Le 15/06/2015 01:14, Laurent Bercot a écrit : (We should take this to the supervision list, this is becoming seriously off-topic for dng.) Dear Laurent, My opinion is that it is not off-topic at all. Instead it is central. Fast init, readiness signalling and supervision are the primary reasons for the development of the badly designed Systemd, hence for forking Debian. There are two possible reasons for the bad design of Systemd: 1) strategic hijacking of Linux, 2) lack of thinking. Devuan reacted to hijacking in the first place; I think it should also work on a KISS framework for init and supervision providing a maximum of freedom (including no supervision, like in sysvinit). I mean unless there is already a dedicated forum for supervision. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Mon, Jun 15, 2015 at 09:12:36PM +0200, Klaus Hartnegg wrote: > Am 14.06.2015 um 23:17 schrieb Isaac Dunham: > >Quite honestly, it really *does* matter to me that I can boot Alpine > >Linux on my netbook in ~5 seconds rather than the ~10 seconds > > Just a single issue caused by the complexity by systemd wastes more time > than all saved boot seconds can ever sum up to. Agreed. However, Alpine Linux uses OpenRC; I intended to point out that time matters more than some were arguing but it's still not a good argument for systemd. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
Am 14.06.2015 um 23:17 schrieb Isaac Dunham: Quite honestly, it really *does* matter to me that I can boot Alpine Linux on my netbook in ~5 seconds rather than the ~10 seconds Just a single issue caused by the complexity by systemd wastes more time than all saved boot seconds can ever sum up to. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 15/06/2015 05:57, Isaac Dunham wrote: (3) Server uses "not-a-supervisor": # write a small C wrapper that forks, execs server in child, # accepts s6-style notification and exits in parent fake-sv -d 1 server client The main reason why I advocate such a simple notification style is that this kind of thing is trivial to script, without a C wrapper: if {server &;} | read y ; then client else echo "Server did not notify readiness" 1>&2 exit 1 fi (4) Server with s6, as far as I can tell from the skarnet docs: Using a supervision framework is the best solution if there is a case for running the server independently from the client. If there isn't, the above script works. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Mon, Jun 15, 2015 at 01:14:51AM +0200, Laurent Bercot wrote: > On 15/06/2015 00:36, Isaac Dunham wrote: > >I think that a program that must run in the background is broken. > >Yet *prohibiting* auto-backgrounding imposes an even more heavy toll > >on scripts where requires to be running and > >ready: you *must* run a supervisor, or else run a lame-not-quite-a- > >supervisor, just to do what would have been trivially done in a few > >more lines of C. > > Can you please elaborate or reformulate ? I don't understand what you > mean. I don't think there's *ever* a case where it is necessary for > the original process to die, so what is the kind of script you are > thinking of ? Could you give a small example ? > (We should take this to the supervision list, this is becoming > seriously off-topic for dng.) Consider the case where you want a script that a) starts a server b) runs a client that accesses that server in the foreground The client will send the server the message to terminate, or we can use a few other ways to watch. This could be a test script, qemu as a vpnc server, or any of a hundred other applications. The application I immediately think of is running a non-graphical qemu build (Alpine Linux choices...) with a vpnc client. I wanted a local script that I could use like plain old graphical qemu, on my old netbook (where running two instances of qemu is going to be off-limits due to crappy hardware). Possible solutions: (1) Backgrounding manually, as recommended for scripts by the site you mentioned. (1a) Error-prone: sometimes, client starts too soon server & client (1b) Usually works, but doesn't connect ASAP: server & sleep 5 client (2) Server auto-backgrounds: server -B client (3) Server uses "not-a-supervisor": # write a small C wrapper that forks, execs server in child, # accepts s6-style notification and exits in parent fake-sv -d 1 server client (4) Server with s6, as far as I can tell from the skarnet docs: # Upgrade GNU make to 4.0 & build skalibs # Build execline # Build s6 # Create a service directory for server, containing a run file like this: server # Launch it, via s6-svscan or s6-supervise # Wait and exit: s6-svwait -U servicedir client Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 15/06/2015 00:36, Isaac Dunham wrote: I think that a program that must run in the background is broken. Yet *prohibiting* auto-backgrounding imposes an even more heavy toll on scripts where requires to be running and ready: you *must* run a supervisor, or else run a lame-not-quite-a- supervisor, just to do what would have been trivially done in a few more lines of C. Can you please elaborate or reformulate ? I don't understand what you mean. I don't think there's *ever* a case where it is necessary for the original process to die, so what is the kind of script you are thinking of ? Could you give a small example ? (We should take this to the supervision list, this is becoming seriously off-topic for dng.) -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Sat, Jun 13, 2015 at 01:53:44AM +0200, Laurent Bercot wrote: > On 12/06/2015 22:21, marc...@welz.org.za wrote: > >The trick is for the daemon process to only background when > >it is ready to service requests (ie its parent process exits > >when the child is ready). > > This is bad design, for several reasons... > The reasons why it's bad are mostly described here: > > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html > > Your solution enforces forking, i.e. auto-backgrounding, and > prevents logging to stderr; in doing so, it prevents daemons from > ever being used with a supervision framework. systemd may be able > to supervise it, using cgroups, but that's about it, unless the > admin is using foreground hacks. > > Moreover, the method you are using to transmit one bit of information, > i.e. readiness of the service, is *the death of a process*. This > is pretty heavy on the system; a simple write() does the job just > as well, and hundreds of times faster. I think that a program that must run in the background is broken. Yet *prohibiting* auto-backgrounding imposes an even more heavy toll on scripts where requires to be running and ready: you *must* run a supervisor, or else run a lame-not-quite-a- supervisor, just to do what would have been trivially done in a few more lines of C. While I haven't written the code yet, it strikes me that it should be trivial to write something that can handle both styles of notification, and maybe even share some of the code. Essentially, part of the auto-background code becomes a trivial not-quite-a-supervisor that exits as soon as it receives the same notification that you use. In the example, I'd want an option like "-S ", where is the fd that goes to the pipe the supervisor is listening to. Pseudocode for this without proper error checking: int pipefds[2]; pid_t pid = 0; parse options; if (supervised) { pipefds[0] = -1; pipefds[1] = supervisor_fd; } else if (background_option) { pipe(pipefds); pid = fork(); if (pid < 0) { error_exit(); } else if (pid > 0) { //close write end of pipe and watch read end till the pipe closes } else /* if (pid == 0) */ { //close read end of pipe } } // setup process if (supervised || background_option) { write(pipefds[1], "1", 1); close(pipefds[1]); } Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Sat, Jun 13, 2015 at 09:42:34AM -0400, Steve Litt wrote: > On Sat, 13 Jun 2015 10:37:19 +0100 > KatolaZ wrote: > > I think there is another, more fundamental question: do we really need > > to know in *real time* when a service/daemon is ready for its job or > > has done what it is supposed to do? AFAIK all this fuss with > > "daemon-readiness" began with the first attempts to have parallel boot > > sequences, which is something that is still *useless* in 95% of the > > use cases: servers don't get restarted evey other minute and "normal" > > users who don't use suspend can wait 30 seconds to have their desktop > > ready, what else? Embedded systems? Well, they usually have just a few > > services running, if any Quite honestly, it really *does* matter to me that I can boot Alpine Linux on my netbook in ~5 seconds rather than the ~10 seconds it takes using LFS-based init scripts on my built-from-scratch system. It really is nice to be able to grab it, press the power button, and have it ready to use by the time I get downstairs; the old 45-second+ boots were rather awkward for conversations where some online document was enquired about. Alpine is OpenRC+busybox init; the built-from-scratch system is musl/busybox/sysvinit/LFS bootscripts, but I've thought about reverting to busybox init and doing a simpler rc script that does what I need. > > What are we really talking about? Isn't this just another > > feature-for-the-feature's-sake-thing? Why should I bother to allow > > cups signalling immediately that it is ready to put my printouts on a > > queue that will anyway need minutes to be processed? Maybe if you have a print server? For a moment, I thought "minutes to be processed" was ridiculous hyperbole; I use a laser printer that gets ~20 pages per minute. (I had a *lot* of papers to write and print in college.) > KatolaZ, I just got done converting Plop Linux to init with a > combination of Suckless Init (for the > PID1/interrupt_listening/shutdown_instantiation) and daemontools-encore > for the process management. I have a daemontools service running > dhclient in the foreground (like all daemontools managed daemons). As > you know, dhclient takes between what, 3 and 20 seconds to get an IP > address, so in my LittKit ordered startup script, I have a loop to > detect when there's an IP address, and stall til one appears. > > If dhclient had seen fit to inform us of a DHCP lease aquisition in a > way other than backgrounding itself (a feature I don't use because > within daemontools I run the program in the foreground), I could have > detected that. Or possibly written LittKit to afirmatively kick off a > process when all its dependencies are met (and you would be right: that > would be more than is necessary). man 8 dhclient: -sf Path to the network configuration script invoked by dhclient when it gets a lease. If unspecified, the default /sbin/dhclient-script is used. Busybox udhcpc and toybox dhcp use "-s" for this. You could use the script to start the network tools directly, or write some indicator that lets the process manager start spawning network programs. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
My take-away from this and the related threads is that a daemon author would ideally provide options to have it: * Either write log messages to stderr or syslog, but write the same data regardless; * Either stay running in the foreground, or auto-background itself once it's ready to begin taking requests; * Write a PID file only at the user's request--that is, only if a path is given. I figure it's up to the user to select the combination of options suitable to address the task at hand, and it's up to the distro to select the sensible defaults. -Jude On Sat, Jun 13, 2015 at 2:37 PM, Laurent Bercot wrote: > On 13/06/2015 08:40, Didier Kryn wrote: > >> Yes, daemon writers are good-willing developpers; they want their >> software to serve as many users as possible; and users install >> distros. This gives power to the distros. But if someone provides >> them with a KISS readyness-signaling method, along with a systemd >> wrapper, then they can satisfy RedHat's requests at no cost. >> > > And there you go: > http://skarnet.org/software/sdnotify-wrapper.c > > Untested with a real systemd, because I'm not going to install a > real systemd anywhere - but I've listened to a socket on the other > end of NOTIFY_SOCKET and it appears to work. Bug-reports welcome. > > > The question now is who will develop, maintain and package this >> wrapper? Will Devuan be the official developper of >> "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who >> else to take the job? Or are the daemon's developper powerfull enough >> to tell RH "do it yourself."? >> > > I'm willing to maintain this for the time being; as long as systemd > does not gratuitously break compatibility with itself, it should not > be too hard. The goal is to encourage daemon developers to stop using > the sd_notify() interface and just write a newline somewhere; the > wrapper is just there to make this simple behaviour work with systemd, > nothing more. > > I firmly believe it should *not* be packaged by Devuan. The wrapper is > meant to only be used on systemd installations, which is exactly what > Devuan is not. Devuan can advertise such a wrapper, advocate its use, > but I don't think it makes sense for it to be a part of the Devuan > distribution. > > I'm providing a single C file for now. I can turn it into a complete > package tarball with configure/make/make install if there's interest. > I'm not going to make distribution-specific packages, though; that's > the job of distribution maintainers. > > Enjoy! > > -- > Laurent > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 06/13/2015 09:34 AM, Klaus Hartnegg wrote: Am 13.06.2015 um 13:33 schrieb Laurent Bercot: 30 seconds is a lot. What if you could get your desktop ready in 5 seconds or less ? This would mean less than what most people think. Because everything longer than half a second is perceived as being forced to wait. As long as an improvement stays above this threshold, it just replaces one forced wait with another forced wait. I had some problem awhile back that required making changes in the Grub menu to see the result after bootup. 10 reboots * 5 seconds = 50 seconds 10 reboots * 30 seconds = 5 minutes 5 minutes / 5-second-reboots = 60 reboots 5 minutes / 30-second-reboots = 10 reboots It's not just a matter of speed, but also granularity. Yes, the faster boot time would give 6 reboots in the time of 1 on the slow machine. But it also lets me bail on a particular course of action sooner. Where I'd be sitting at the slow machine twiddling my thumbs for another 25 seconds, on the fast machine I'm analysing the feedback and choosing a new course of action. Given the average human attention span is only about 20 minutes, this is a qualitative difference. I mentioned Grub because it's the first that popped into my head. But given another 50 seconds I'd also mention the following: having the (practical) option to restart on a system freeze if you're in a hurry testing out the rt kernel vs stock kernel having the option to restart in a presentation if you get stuck somehow (or if the projector somehow only gets triggered at bootup) dev'ing rt kernel, init system, and lots of other stuff that requires reboot -Jonathan ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 13/06/2015 08:40, Didier Kryn wrote: Yes, daemon writers are good-willing developpers; they want their software to serve as many users as possible; and users install distros. This gives power to the distros. But if someone provides them with a KISS readyness-signaling method, along with a systemd wrapper, then they can satisfy RedHat's requests at no cost. And there you go: http://skarnet.org/software/sdnotify-wrapper.c Untested with a real systemd, because I'm not going to install a real systemd anywhere - but I've listened to a socket on the other end of NOTIFY_SOCKET and it appears to work. Bug-reports welcome. The question now is who will develop, maintain and package this wrapper? Will Devuan be the official developper of "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who else to take the job? Or are the daemon's developper powerfull enough to tell RH "do it yourself."? I'm willing to maintain this for the time being; as long as systemd does not gratuitously break compatibility with itself, it should not be too hard. The goal is to encourage daemon developers to stop using the sd_notify() interface and just write a newline somewhere; the wrapper is just there to make this simple behaviour work with systemd, nothing more. I firmly believe it should *not* be packaged by Devuan. The wrapper is meant to only be used on systemd installations, which is exactly what Devuan is not. Devuan can advertise such a wrapper, advocate its use, but I don't think it makes sense for it to be a part of the Devuan distribution. I'm providing a single C file for now. I can turn it into a complete package tarball with configure/make/make install if there's interest. I'm not going to make distribution-specific packages, though; that's the job of distribution maintainers. Enjoy! -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Sat, 13 Jun 2015 10:43:52 +0200 marc wrote: > On a personal note: You have been making a number of pronouncements > which suggest incomplete understanding of unix: Here unaware of > dup2(), but in previous posts you were unclear on when a shell needs > to do a stat() (5542b2d4.5030...@skarnet.org), misunderstood security > through obscurity (55449253@skarnet.org), do not realise that a > setgid exectuable which isn't world executable is almost useless > (5545e741.5000...@skarnet.org) Do you even know who you're talking to? You might want to find out who Laurent is and what software he's written before you declare his Unix understanding "incomplete". When Laurent speaks, I listen, and he's never steered me wrong. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Sat, 13 Jun 2015 10:37:19 +0100 KatolaZ wrote: > On Sat, Jun 13, 2015 at 08:40:27AM +0200, Didier Kryn wrote: > > [cut] > > > > > The question now is who will develop, maintain and package this > > wrapper? Will Devuan be the official developper of > > "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who > > else to take the job? Or are the daemon's developper powerfull > > enough to tell RH "do it yourself."? > > > > I think there is another, more fundamental question: do we really need > to know in *real time* when a service/daemon is ready for its job or > has done what it is supposed to do? AFAIK all this fuss with > "daemon-readiness" began with the first attempts to have parallel boot > sequences, which is something that is still *useless* in 95% of the > use cases: servers don't get restarted evey other minute and "normal" > users who don't use suspend can wait 30 seconds to have their desktop > ready, what else? Embedded systems? Well, they usually have just a few > services running, if any > > What are we really talking about? Isn't this just another > feature-for-the-feature's-sake-thing? Why should I bother to allow > cups signalling immediately that it is ready to put my printouts on a > queue that will anyway need minutes to be processed? > > My2Cents > > KatolaZ > Good questions, all. In my opinion, this is a legitimate issue, not an attempt to match another systemd marketing feature (magnesium paddle shifter). KatolaZ, I just got done converting Plop Linux to init with a combination of Suckless Init (for the PID1/interrupt_listening/shutdown_instantiation) and daemontools-encore for the process management. I have a daemontools service running dhclient in the foreground (like all daemontools managed daemons). As you know, dhclient takes between what, 3 and 20 seconds to get an IP address, so in my LittKit ordered startup script, I have a loop to detect when there's an IP address, and stall til one appears. If dhclient had seen fit to inform us of a DHCP lease aquisition in a way other than backgrounding itself (a feature I don't use because within daemontools I run the program in the foreground), I could have detected that. Or possibly written LittKit to afirmatively kick off a process when all its dependencies are met (and you would be right: that would be more than is necessary). I'd hate to have a boot where an outlier dhclient took 50 seconds to acquire a lease, and all sorts of network-dependent daemons got spawned in the meantime. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
Am 13.06.2015 um 13:33 schrieb Laurent Bercot: 30 seconds is a lot. What if you could get your desktop ready in 5 seconds or less ? This would mean less than what most people think. Because everything longer than half a second is perceived as being forced to wait. As long as an improvement stays above this threshold, it just replaces one forced wait with another forced wait. In contrast an iPad is immediately ready to get work done. No perceived wait. This feels like a different world! Good luck getting a PC from sleep to online in half a second. As long as it is slower, the precise number of seconds does not matter much. If you want to make Linux go from sleep to ready faster, there is an easier way: eliminate the waits in dhclient. The IP stack in a firmware which I wrote initializes itself in a few milliseconds. The replies from DHCP servers are lightning fast. Getting confirmation for the last used IP address does not take significantly longer than a ping time. The only slow parts are the waits in the recommended checks whether another PC is errorneously using the same IP address. This is a very rare case, and these cases can usually be detected within 10 milliseconds, because the offending machine must be very nearby. Do just this quick check, then report ready, and then do a more thorough check afterwards, just to be closer to be RFC-compliant. Please make this as systemd-incompatible as possible ;-) And then compare the whole sleep to useable time, not just the time to show the desktop. Btw. boot times tend to get less relevant in the future, because user devices just never go completely offline, and servers are mostly clusters. The whole upgrade downtime for the largest of my servers is over 5 minutes (but only once a month). How much effort would I spend to reduce this by 30 seconds? None! If the users want to get rid of this downtime, they must order a cluster. And then the downtime of the single machines would be completely irrelevant. There is no good reason to completely rewrite Linux just to save a few seconds boot time. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
Am 13.06.2015 um 08:40 schrieb Didier Kryn: Yes, daemon writers are good-willing developpers; they want their software to serve as many users as possible; and users install distros. This gives power to the distros. But if someone provides them with a KISS readyness-signaling method, along with a systemd wrapper, then they can satisfy RedHat's requests at no cost. This is great, because usually the way to win is to provide something which is immediately better, not discussing that other ideologies might cause issues in the future. Developers want an easier way to send this signal, which automatically works in all distributions. If there is a library which provides this, they will look at it. And while they are, there they might look at other offers there as well. Redhat will probably not provide such a thing, thus this is an example where Devuan can be better, and gain attention. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 13/06/2015 11:37, KatolaZ wrote: AFAIK all this fuss with "daemon-readiness" began with the first attempts to have parallel boot sequences, which is something that is still *useless* in 95% of the use cases: servers don't get restarted evey other minute and "normal" users who don't use suspend can wait 30 seconds to have their desktop ready, what else? Embedded systems? Well, they usually have just a few services running, if any 30 seconds is a lot. What if you could get your desktop ready in 5 seconds or less ? About embedded systems, things are changing quite fast. The amount of services running on an Android phone, for instance, is mind-boggling, and it can take several minutes to boot a phone. Most of this waiting time is unnecessary. What are we really talking about? Isn't this just another feature-for-the-feature's-sake-thing? Why should I bother to allow cups signalling immediately that it is ready to put my printouts on a queue that will anyway need minutes to be processed? A printing service may not be the best example, but when you're late for a broadcast and turn your TV on, you don't want to wait any more than is necessary to get image and sound. If your TV took extra seconds to boot up, you'd curse at it. (This has happened to me, I watch broadcast streams on my PC and have wished for faster booting times on more than one occasion.) More generally, the main reason why computing is so slow is that everyone reasons the same way "why bother?" Somebody has to start, and there's no better place than the low level. If nothing else, there's the public relations argument. As long as systemd is able to say "we do parallel service startup and boot your machine in 5 seconds, nobody else does it", then systemd has a real, valid, technical advantage over other systems, and it makes it harder to advocate against it. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 13/06/2015 10:43, marc wrote: It is only bad design if you have your heart set on a supervision framework like daemontools. No, it is bad design because - it lengthens the code path before the service is operational - it requires software authors to write more code into their daemon instead of less, code that could otherwise be factored - it prevents system administrators from running the service as they choose, supervised or not. Even systemd gives administrators this choice. Such frameworks have been around for decades too, and have not caught on (also for several reasons ;) Lots of good ideas have not caught on. Plan 9 has not caught on. Itanium has not caught on. Popularity has never been a suitable measure for technical quality, and if we were after popularity, we would be using Microsoft Windows. The biggest reason is that in a number of applications it is unclear if and when things should turn in to a daemon. Consider something like screen - things only background when you press . In general terms having a supervision framework means that a daemon is something an administrator decides to create, not something which the user asks his application to become. Um, yes. Supervision frameworks were made to help administrators, and usually run noninteractive programs. The way you manage a system requires planning, as any management task. The thing is, they don't prevent users from doing whatever they want. If a user wants to daemonize a screen process previously running interactively, then fine - it's possible to do so. It won't be supervised, but who cares? It wasn't supervised in the first place and does not need to. Also, I honestly wouldn't use GNU screen as an example of good software design, but that's not the point. * It becomes harder for end users to run their own daemons. Harder, less convenient, whatever. Not impossible - with enough contortions anything is possible. But it disempowers non-admin users. Huh? Non-admin users have exactly the *same* ways to run their own daemons with or without a supervision framework. And that is the point: it's always possible to make a program run in the background, whereas it's much harder to make an auto-backgrounding program run in the foreground. Supervision does not take away anything from anyone, it *opens up* possibilities. * Daemon programmers get to become lazy - where previously a crash was something horrible, a crash now means that the supervision framework restarts it, so no biggie. Welcome to windows, where software is expected to crash This is a complete straw man, akin to blaming antiretroviral treatment for people having unsafe sex and catching AIDS saying it's not that big of a deal anymore. * People are lulled into the false sense of security: "My supervision framework thinks the process is still up, so things are ok". But your process has has been running in an infinite loop for the last couple of days. If you want to have monitoring, monitor your task at the service it provides (retrieve a web page from a web server, finger the finger daemon). Supervision frameworks do not replace competent system administration, complete with logging, in-service monitoring and alerts if your SLA requires it. They only make it easier. This is another strawman. Inevitably that requires domain knowledge, which supervision framework advocates struggle to realise. Nothing replaces domain knowledge. Wanting to make administration easier is not the same as wanting to dumb it down. Progress and convenience is not decadence, unless you miss the time where washing machines did not exist, and men were men and did all their laundry by hand - wait, they didn't, they enslaved women instead. Or if you are Lennart, you end up absorbing all domains into your supervision framework, at which point we have to fork a distribution The fact that I'm following this list should make it clear that I'm not Lennart, and about anything I've written here or anywhere else should make it clear that my goal is quite opposite to absorbing all domains. * Supervison frameworks are marketed as "So easy to use, any idiot can write a daemon". No, this is not what they are marketed as, and you are severely misinterpreting. Closing stderr to the parent does not prevent logging to stderr, you can quite happily close a file descriptor with dup2(). The child is run with stderr pointing to a pipe to the parent. You have to close that descriptor for the parent to exit. The original stderr, the one the parent was run with, is overwritten with your dup2() in fork_parent() and the child has no access to it; and it is irremediably lost when the parent exits. You can dup2() all you want in the child, you will never get the original stderr back, which is of course the point of logging to stderr - you want to log to the stderr the daemon has when it is started! Or you could use some other
Re: [Dng] Readiness notification
On Sat, Jun 13, 2015 at 08:40:27AM +0200, Didier Kryn wrote: [cut] > > The question now is who will develop, maintain and package this > wrapper? Will Devuan be the official developper of > "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who > else to take the job? Or are the daemon's developper powerfull > enough to tell RH "do it yourself."? > I think there is another, more fundamental question: do we really need to know in *real time* when a service/daemon is ready for its job or has done what it is supposed to do? AFAIK all this fuss with "daemon-readiness" began with the first attempts to have parallel boot sequences, which is something that is still *useless* in 95% of the use cases: servers don't get restarted evey other minute and "normal" users who don't use suspend can wait 30 seconds to have their desktop ready, what else? Embedded systems? Well, they usually have just a few services running, if any What are we really talking about? Isn't this just another feature-for-the-feature's-sake-thing? Why should I bother to allow cups signalling immediately that it is ready to put my printouts on a queue that will anyway need minutes to be processed? My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
> On 12/06/2015 22:21, marc...@welz.org.za wrote: > >The trick is for the daemon process to only background when > >it is ready to service requests (ie its parent process exits > >when the child is ready). > > You already mentioned it in a reply to me, indeed. I intentionally > did not follow up, and here is why. > > This is bad design, for several reasons. It's actually worse design > than sd_notify(), and I'd rather have every daemon use sd_notify() > and write a sd_notify server myself than recommend your solution. > > The reasons why it's bad are mostly described here: > > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html It is only bad design if you have your heart set on a supervision framework like daemontools. Such frameworks have been around for decades too, and have not caught on (also for several reasons ;) The above link even lists all these attempts, and so presumably has the agenda of trying to make these frameworks happen The biggest reason is that in a number of applications it is unclear if and when things should turn in to a daemon. Consider something like screen - things only background when you press . In general terms having a supervision framework means that a daemon is something an administrator decides to create, not something which the user asks his application to become. This has at least four undesirable side-effects: * It becomes harder for end users to run their own daemons. Harder, less convenient, whatever. Not impossible - with enough contortions anything is possible. But it disempowers non-admin users. * Daemon programmers get to become lazy - where previously a crash was something horrible, a crash now means that the supervision framework restarts it, so no biggie. Welcome to windows, where software is expected to crash * People are lulled into the false sense of security: "My supervision framework thinks the process is still up, so things are ok". But your process has has been running in an infinite loop for the last couple of days. If you want to have monitoring, monitor your task at the service it provides (retrieve a web page from a web server, finger the finger daemon). Inevitably that requires domain knowledge, which supervision framework advocates struggle to realise. Or if you are Lennart, you end up absorbing all domains into your supervision framework, at which point we have to fork a distribution * Supervison frameworks are marketed as "So easy to use, any idiot can write a daemon". And assume it to be true and every idiot writes a daemon. People who don't know what an attack surface is, how a protection domain gets synthesised, etc. And typically in languages which assume infinite RAM and CPU time, cause if they run out, they just hit the wall... > Your solution enforces forking, i.e. auto-backgrounding, and > prevents logging to stderr; in doing so, it prevents daemons from > ever being used with a supervision framework. Closing stderr to the parent does not prevent logging to stderr, you can quite happily close a file descriptor with dup2(). Or you could use some other logging framework, but that would then conflict with the supervision framework. Framework collisions On a personal note: You have been making a number of pronouncements which suggest incomplete understanding of unix: Here unaware of dup2(), but in previous posts you were unclear on when a shell needs to do a stat() (5542b2d4.5030...@skarnet.org), misunderstood security through obscurity (55449253@skarnet.org), do not realise that a setgid exectuable which isn't world executable is almost useless (5545e741.5000...@skarnet.org) So in general this ok, everybody starts off new, nobody is perfect, etc. But surely it is worth understanding something before wanting to redesign it wholesale (5542603e.8000...@skarnet.org, and now here with daemon startup). Especially in a forum (devuan) which appears to have been forked in response to such a poorly conceived redesign. Consider your closing statement here: > But auto-backgrounding is not good > design in the first place; it comes from ancient Unix times when we > did not know better, and the daemon() function should either > disappear into oblivion, or have a place in the museum of medieval > programming as an example of how not to write Unix software. This paragraph does not convey anything useful, and the tone comes across as arrogant - consider carefully whom label as not knowing how to write Unix software, cause you might fit that description rather well, like all of us regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
Le 13/06/2015 01:15, Laurent Bercot a écrit : Encouraging daemon writers to use another API and providing a wrapper to make daemons using the simpler API work with the sd_notify mechanism is clearly the better ideological solution, and also technologically preferable because more compatible with other notification frameworks; but it's harder, because it requires communication with daemon authors, and the systemd proponents have more communication power than we do (read: $$$). But I think authors can be convinced if we show that our API is simpler to use and will work under any framework, systemd included. Yes, daemon writers are good-willing developpers; they want their software to serve as many users as possible; and users install distros. This gives power to the distros. But if someone provides them with a KISS readyness-signaling method, along with a systemd wrapper, then they can satisfy RedHat's requests at no cost. The question now is who will develop, maintain and package this wrapper? Will Devuan be the official developper of "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who else to take the job? Or are the daemon's developper powerfull enough to tell RH "do it yourself."? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
Le 13/06/2015 01:53, Laurent Bercot a écrit : On 12/06/2015 22:21, marc...@welz.org.za wrote: The trick is for the daemon process to only background when it is ready to service requests (ie its parent process exits when the child is ready). You already mentioned it in a reply to me, indeed. I intentionally did not follow up, and here is why. This is bad design, for several reasons. It's actually worse design than sd_notify(), and I'd rather have every daemon use sd_notify() and write a sd_notify server myself than recommend your solution. The reasons why it's bad are mostly described here: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html Your solution enforces forking, i.e. auto-backgrounding, and prevents logging to stderr; in doing so, it prevents daemons from ever being used with a supervision framework. systemd may be able to supervise it, using cgroups, but that's about it, unless the admin is using foreground hacks. Moreover, the method you are using to transmit one bit of information, i.e. readiness of the service, is *the death of a process*. This is pretty heavy on the system; a simple write() does the job just as well, and hundreds of times faster. If auto-backgrounding was an absolute necessity, then sure, the parent would need to die anyway, and you could time its death so it transmits readiness. Why not. But auto-backgrounding is not good design in the first place; it comes from ancient Unix times when we did not know better, and the daemon() function should either disappear into oblivion, or have a place in the museum of medieval programming as an example of how not to write Unix software. Thanks Laurent, I hope you explain it better than me. The point was already discussed on this list. It will take time before people are convinced because I think a lot of tutorials around still present auto-daemonization as the way to go. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Fri, 12 Jun 2015 22:21:06 +0200 marc...@welz.org.za wrote: > The trick is for the daemon process to only background when > it is ready to service requests (ie its parent process exits > when the child is ready). For those of us who use daemontools-inspired process managers or inits, the preceding does not work. We need our daemons to be able to run in the foreground. Just because today Devuan uses sysvinit doesn't mean that will always be true. One day, for all we know, Devuan will use runit or S6. And if that day comes, we will rue the day when the decision was made to have daemons be like dhclient and signal readiness by backgrounding at that particular time. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 12/06/2015 22:21, marc...@welz.org.za wrote: The trick is for the daemon process to only background when it is ready to service requests (ie its parent process exits when the child is ready). You already mentioned it in a reply to me, indeed. I intentionally did not follow up, and here is why. This is bad design, for several reasons. It's actually worse design than sd_notify(), and I'd rather have every daemon use sd_notify() and write a sd_notify server myself than recommend your solution. The reasons why it's bad are mostly described here: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html Your solution enforces forking, i.e. auto-backgrounding, and prevents logging to stderr; in doing so, it prevents daemons from ever being used with a supervision framework. systemd may be able to supervise it, using cgroups, but that's about it, unless the admin is using foreground hacks. Moreover, the method you are using to transmit one bit of information, i.e. readiness of the service, is *the death of a process*. This is pretty heavy on the system; a simple write() does the job just as well, and hundreds of times faster. If auto-backgrounding was an absolute necessity, then sure, the parent would need to die anyway, and you could time its death so it transmits readiness. Why not. But auto-backgrounding is not good design in the first place; it comes from ancient Unix times when we did not know better, and the daemon() function should either disappear into oblivion, or have a place in the museum of medieval programming as an example of how not to write Unix software. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 12/06/2015 20:09, Tomasz Torcz wrote: Hey, it's almost exactly what sd_notify() does. Instead of one character, it writes "READY=1" to a socket. Nothing more, no D-Bus, no additional libraries needed. In basic form it few lines of C code. Of course https://github.com/systemd/systemd/blob/0e4061c4d5de6b41326740ee8f8f13c168eea28d/src/libsystemd-daemon/sd-daemon.c#L414 looks much worse, but it packs more functionality than simply readiness signalling. Which is exactly the problem: it packs more functionality. More functionality, that can be added to at a developer's whim, is something that a stub has to support - if only to not crash on functionality it doesn't understand. More functionality means that daemon authors will rely on it, and use the readiness notification mechanism for things entirely unrelated. More functionality means feature creep that you will have to follow to remain compatible. It's easy to write a notification server that listens to connections from sd_notify() and does things when it reads READY=1. It's not so easy to implement all the sd_notify protocol, even right now, and with all the random stuff that will inevitably get added over the years, when daemons start relying on it. Instead of those 68 lines of code, I suggest the following: void notify_readiness (void) { write(1, "\n", 1) ; close(1) ; } You really don't need anything more. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 12/06/2015 19:46, Steve Litt wrote: I agree with every single thing you write above, but have one question for you: What does Devuan do when daemons like cupsd and sshd make sd_notify calls, and these don't condition the call on sd_notify being available, and sd_notify cannot be conditionally recompiled out of the program? Is Devuan going to rewrite every single daemon? Short answer: yes. That's exactly the point of a distribution, as Katola says. A bit longer answer: it doesn't even have to be hard. You don't have to rewrite anything - just patch; it shouldn't be too difficult to edit out the parts calling sd_notify. Even better, suggest alternative software that you don't have to patch. cupsd and sshd have been infected by systemd? Well, maybe you should inform the users, and provide similar functionality in a systemd-free way. Isn't that the goal of Devuan? sshd servers are not lacking. As for printing servers, I don't know, but I'd be surprised if cupsd was the only possibility. And if it actually is the only possibility, then we have a bigger problem than just sd_notify: it means that monopolies exist in free software - real, existing monopolies, albeit more inconspicuous than systemd's obvious attempts at a monopoly - and it is taking away from users' freedom. And that is what needs to be fought first and foremost. I firmly believe that in 20ish years, we have lost most of the awareness of what free software is and what it means. If we cannot actually dive into the code and take out what we don't want, then it's de facto not free software anymore, no matter the reason. systemd is proprietary software despite its licensing because it's too complex to be tinkered with at an individual level, it's controlled by a company, and it uses embrace and extend methods to establish market domination. But I don't think sshd and cupsd are there yet - they can still be worked with. Same with most daemons that have already succumbed to the sirens of sd_notify. And I certainly hope that those are few and far between. By the way, if there *were* a stub sd_notify, I'd have nothing against it doing nothing but passing the info to S6-notifywhenup or something like it. The issue is complex because it's both technical and ideological. Stubbing the sd_notify client, i.e. writing a library that daemons can link against, is easier because it doesn't depend on anyone else than the person writing it - but it is ideologically worse because it gives ground to systemd, and does nothing to incentivize daemon writers to stop usingthe sd_notify API. Encouraging daemon writers to use another API and providing a wrapper to make daemons using the simpler API work with the sd_notify mechanism is clearly the better ideological solution, and also technologically preferable because more compatible with other notification frameworks; but it's harder, because it requires communication with daemon authors, and the systemd proponents have more communication power than we do (read: $$$). But I think authors can be convinced if we show that our API is simpler to use and will work under any framework, systemd included. If there were a stub sd_notify, I'd rather have it output the info in the simplest possible format so that it can then be used by *any* notification reader, and so that it's actually easier for a daemon author to output the notification directly than to call sd_notify(). I'm a bit uncomfortable treading these grounds, because it's technical talk that ultimately has a political goal, and I don't like to mix the two, but when stubbing is involved it's unfortunately unavoidable. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
> For months, literally, the supervision list > has been wringing its hands over the very real problem that, for process > dependency purposes, one must know that process X is not only running, > but ready to handle its business. Knowing process X is running isn't > sufficent, because some processes take a long time between running > and being ready for business. At the risk of sounding like a broken record, this problem has been known for decades, and has been solved for decades (eg, see the sysklogd sources). The trick is for the daemon process to only background when it is ready to service requests (ie its parent process exits when the child is ready). And I am pretty sure I did (apologies for the repeated spam) mention my writeup at welz.org.za/notes/on-starting-daemons.html on this very list. It even contains a bit of sample code to reduce things to a single function call, and later a close() to stderr Actually, looking at the devuan archives, I actually mentioned it in a reply to you - not sure if this is sad or funny. regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification (was: One issue with ongoing depoetterization)
On Fri, Jun 12, 2015 at 07:37:21PM +0200, Laurent Bercot wrote: > Please don't do this. > The more you bend to the systemd interfaces, the more it gets a foot > in the door. By implementing a dummy sd_notify, you acknowledge the > validity of the interface; you accept that the systemd people have > created something worth using, and you validate the existence of > (a part of) systemd. If systemd has some good parts but systemd is bad cause it has a lot of other bad parts, and even the good parts are bad implemented, i don't see why we can't get only the good parts and reimplement them in a better way. For example, in this specific sd_notify, i can see a good thing to have a little "do only one thing" little daemon+library that implement the sd_notify call and the open compile an ascii text pseudofile somewhere in /sys with a list of "ready to use" daemons, and maybe also a unix socket where other daemons, a script, an init can connect to to have real time notifications of daemon getting ready. This way we have a great feature, one of the few good features of systemd, but implemented in a unix, kiss and indipendent (and good) way. So, why not? -- Franco (nextime) Lanza Lonate Pozzolo (VA) - Italy SIP://c...@casa.nexlab.it web: http://www.nexlab.net NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 --- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc --- signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification (was: One issue with ongoing depoetterization)
On Fri, Jun 12, 2015 at 07:37:21PM +0200, Laurent Bercot wrote: > On 12/06/2015 19:01, Steve Litt wrote: > >The one thing I *do* know is that we need to provide a sd_notify > >interface, even if it does nothing at all and drops passed information > >on the floor. > > > There's a much simpler mechanism that can be used to provide > readiness notification, and that I suggest in >http://skarnet.org/software/s6/notifywhenup.html > and that is: write a given character on a descriptor, then close that > descriptor. Hey, it's almost exactly what sd_notify() does. Instead of one character, it writes "READY=1" to a socket. Nothing more, no D-Bus, no additional libraries needed. In basic form it few lines of C code. Of course https://github.com/systemd/systemd/blob/0e4061c4d5de6b41326740ee8f8f13c168eea28d/src/libsystemd-daemon/sd-daemon.c#L414 looks much worse, but it packs more functionality than simply readiness signalling. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification (was: One issue with ongoing depoetterization)
On Fri, Jun 12, 2015 at 01:46:41PM -0400, Steve Litt wrote: [cut] > > Hi Laurent, > > I agree with every single thing you write above, but have one question > for you: What does Devuan do when daemons like cupsd and sshd make > sd_notify calls, and these don't condition the call on sd_notify being > available, and sd_notify cannot be conditionally recompiled out of the > program? Is Devuan going to rewrite every single daemon? > You can always patch-out the calls to sd_notify, can't you? Patching vanilla software to adhere to a set of requirements is exactly what distributions normally do, after all -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 12/06/2015 19:46, Steve Litt wrote: I agree with every single thing you write above, but have one question for you: What does Devuan do when daemons like cupsd and sshd make sd_notify calls, and these don't condition the call on sd_notify being available, and sd_notify cannot be conditionally recompiled out of the program? Is Devuan going to rewrite every single daemon? I have a detailed answer to this but I have to go out right now for a few hours. Sorry about that and stay tuned. ;) -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification (was: One issue with ongoing depoetterization)
On Fri, 12 Jun 2015 19:37:21 +0200 Laurent Bercot wrote: > On 12/06/2015 19:01, Steve Litt wrote: > > The one thing I *do* know is that we need to provide a sd_notify > > interface, even if it does nothing at all and drops passed > > information on the floor. > > Please don't do this. > The more you bend to the systemd interfaces, the more it gets a foot > in the door. By implementing a dummy sd_notify, you acknowledge the > validity of the interface; you accept that the systemd people have > created something worth using, and you validate the existence of > (a part of) systemd. > > The thing is, the sd_notify interface is not *too* bad, but like > the rest of systemd, it is overengineered, too complex, and mixes > several different things in a monolithic way so that people who are > trying to actually implement real support for sd_notify are bound > to reinvent systemd one way or another. > > It's absolutely like the old Microsoft "embrace and extend" > strategy, you know. They get one foot in the door by providing > something useful, but then pile their own crap onto it, and people > are already relying on it, so you want to implement support for it, > and then you're captive, and the only way to be 100%-compatible is to > use the original product. > > There's a much simpler mechanism that can be used to provide > readiness notification, and that I suggest in > http://skarnet.org/software/s6/notifywhenup.html > and that is: write a given character on a descriptor, then close that > descriptor. > It doesn't get any simpler than that, it doesn't require linking > daemons against any library, and it can be made to be compatible > with *everything*. If a daemon supports that mechanism, it is very > easy to write a systemd-notify program that would wrap that daemon and > communicate with systemd via sd_notify to inform it of the daemon's > readiness, the way s6-notifywhenup does for s6. > > Please KISS, and design good interfaces to be adopted, instead of > letting yourselves get bullied by systemd forcing its interfaces down > your throats and jumping through hoops to adapt to them. With a > simpler interface and a trivial wrapper program, the influence of > systemd only extends to the wrapper program, and not to the daemons > themselves. Hi Laurent, I agree with every single thing you write above, but have one question for you: What does Devuan do when daemons like cupsd and sshd make sd_notify calls, and these don't condition the call on sd_notify being available, and sd_notify cannot be conditionally recompiled out of the program? Is Devuan going to rewrite every single daemon? By the way, if there *were* a stub sd_notify, I'd have nothing against it doing nothing but passing the info to S6-notifywhenup or something like it. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Readiness notification (was: One issue with ongoing depoetterization)
On 12/06/2015 19:01, Steve Litt wrote: The one thing I *do* know is that we need to provide a sd_notify interface, even if it does nothing at all and drops passed information on the floor. Please don't do this. The more you bend to the systemd interfaces, the more it gets a foot in the door. By implementing a dummy sd_notify, you acknowledge the validity of the interface; you accept that the systemd people have created something worth using, and you validate the existence of (a part of) systemd. The thing is, the sd_notify interface is not *too* bad, but like the rest of systemd, it is overengineered, too complex, and mixes several different things in a monolithic way so that people who are trying to actually implement real support for sd_notify are bound to reinvent systemd one way or another. It's absolutely like the old Microsoft "embrace and extend" strategy, you know. They get one foot in the door by providing something useful, but then pile their own crap onto it, and people are already relying on it, so you want to implement support for it, and then you're captive, and the only way to be 100%-compatible is to use the original product. There's a much simpler mechanism that can be used to provide readiness notification, and that I suggest in http://skarnet.org/software/s6/notifywhenup.html and that is: write a given character on a descriptor, then close that descriptor. It doesn't get any simpler than that, it doesn't require linking daemons against any library, and it can be made to be compatible with *everything*. If a daemon supports that mechanism, it is very easy to write a systemd-notify program that would wrap that daemon and communicate with systemd via sd_notify to inform it of the daemon's readiness, the way s6-notifywhenup does for s6. Please KISS, and design good interfaces to be adopted, instead of letting yourselves get bullied by systemd forcing its interfaces down your throats and jumping through hoops to adapt to them. With a simpler interface and a trivial wrapper program, the influence of systemd only extends to the wrapper program, and not to the daemons themselves. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng