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 12
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
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 Sat, Jun 13, 2015 at 09:42:34AM -0400, Steve Litt wrote: On Sat, 13 Jun 2015 10:37:19 +0100 KatolaZ kato...@freaknet.org 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 script-file 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
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 process 1 requires process 2 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 fd, where fd
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 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 process 1 requires process 2 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 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
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
On Sat, 13 Jun 2015 10:43:52 +0200 marc marc...@welz.org.za 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
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 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 control-A d. 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
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 (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
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
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 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 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 (was: One issue with ongoing depoetterization)
On Fri, 12 Jun 2015 19:37:21 +0200 Laurent Bercot ska-de...@skarnet.org 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
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, 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
