Re: [Dng] Why daemontools is so cool
> No need to mix doubleforking and PID tracking on your > program. That should be the duty of whatever daemonizes and manages > your program. You know, like Daemontools or s6. So there is a very good reason for a deamon to handle its own backgrounding: The sensible convention is it that it should only background at the instant where it is ready to service requests: If there is a long initialisation phase it should stay in the foreground - so that things that depend on it in turn do not get started too soon. A more detailed description of this problem I wrote up a while ago at welz.org.za/notes/on-starting-daemons.html. More fundamentally: If an application has problems calling the a daemonize() or fork_parent() function or the handful of system calls that make up this, then maybe this a limitation of the development environment or language - if calling these this is regarded to be hard then one wonders how reliable the rest of the program is. regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] libudev-compat
On Sat, 28 Mar 2015, Jude Nelson wrote: >It's not ready yet--it's not yet ABI-compatible with libudev (but it is >API-compatible--Kay Sievers' tests pass when recompiled). ACK >Some background for the rest of the list.* I've managed to extract >the required variables, macros, and headers from systemd 219 to >make libudev compile independently of systemd.* I intend to >maintain a fork of libudev called libudev-compat that will remain >ABI-compatible with systemd's libudev, but will allow programs that >depend on libudev to work without udevd.* sounds great. libudev-compat is the last thing standing to remove systemd packages completely AFAIK >Specifically, I intend to rewrite the udev_monitor implementation >to use inotify(2) to watch /dev and propagate device events to >listeners, instead of connecting to udevd to listen for udevd's >events.* clever approach which puts the filesystem back as authoritative source for events and the permissions on files in /dev as the ACL for them >As a result, users will be able to select whatever device >management daemon they want without breaking other programs.* Even >static /dev will be supported, in which case device events will >only be propagated when the admin creates the device file itself. That's what we want. Freedom! cheers ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Another reason of why I am considering Devuan
Hi! See this one: Bug#761658: Please do not default to using Google nameservers Marco tagged it as "wontfix". Seriously, if I didn´t configure a nameserver I *mean* it. I don´t want it to just choose a Google nameserver then, without even telling me. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Another reason of why I am considering Devuan
dear Martin, On Sun, 29 Mar 2015, Martin Steigerwald wrote: > Bug#761658: Please do not default to using Google nameservers tl;dr - isn't there a preseed directive to change the default?! > Marco tagged it as "wontfix". Seriously, if I didn´t configure a > nameserver I *mean* it. I don´t want it to just choose a Google nameserver > then, without even telling me. you are right in pointing this out. Also the /etc/resolv.conf situation is really sub-optimal as it is already in Wheezy, let me explain: I can understand the advantages of /etc/network/interfaces, but I would expect at least one of the manpages indicated in the generated file notice to detail how to deactivate this behavior and have /etc/resolv.conf generated by hand or another script. Almost a pattern? Once again, no planned way to opt-out from complexity. Adding to the discourse on the general posture and even principles Devuan should stand for: I wish we can formulate that if in Devuan or even in what we inherited from Debian are default wrappers on top of base file, there must be always an easy way to switch them off and circumvent them. This should be the case also with grub and other similar clusterf*. Back to your problem, at the very least there should be a way to deactivate default DNS configuration and simply have *no dns configured* This way there could be whatever pre-seed script to set a default even if there is no default-DNS specific directive. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Another reason of why I am considering Devuan
Am Sonntag, 29. März 2015, 15:26:51 schrieben Sie: > dear Martin, Dear Jaromil, > On Sun, 29 Mar 2015, Martin Steigerwald wrote: > > Bug#761658: Please do not default to using Google nameservers > > tl;dr - isn't there a preseed directive to change the default?! I have no idea, I think I have read it is *hardcoded* into systemd- resolved, but I didn´t check, so take this with a grain of salt. It seems you can only disable this behavior by configuring a DNS server. >From resolved.conf(5): FallbackDNS= A space separated list of IPv4 and IPv6 addresses to be used as the fallback DNS servers. Any per-interface DNS servers obtained from systemd-networkd.service(8) take precedence over this setting, as do any servers set via DNS= above or /etc/resolv.conf. This setting is hence only used if no other DNS server information is known. If this option is not given, a compiled-in list of DNS servers is used instead. Okay, it depends whether it is possible to set this on a zero value. If that doesn´t work it may work with setting it to 127.0.0.1 or even a non existing 127.0.0.0/8 address. I set it to an empty value now. But how do I get confirmation that it works? Do I really have to deconfigure DNS to find out? > > Marco tagged it as "wontfix". Seriously, if I didn´t configure a > > nameserver I *mean* it. I don´t want it to just choose a Google > > nameserver then, without even telling me. > > you are right in pointing this out. Also the /etc/resolv.conf situation > is really sub-optimal as it is already in Wheezy, let me explain: I can > understand the advantages of /etc/network/interfaces, but I would expect > at least one of the manpages indicated in the generated file notice to > detail how to deactivate this behavior and have /etc/resolv.conf > generated by hand or another script. I didn´t even report the bug, but I was surprised how Marco just closed it as wontfix. But on the other hand I see a pattern there. I have seen that with systemd related bug reports as well. Its more this "I won´t fix this, go away" attitude I have seen with systemd upstream and with Debian packagers of systemd than systemd itself that lets me ponder to avoid systemd at least for my server VM. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Why daemontools is so cool
marc wrote: > > No need to mix doubleforking and PID tracking on your > > program. That should be the duty of whatever daemonizes and manages > > your program. You know, like Daemontools or s6. > > So there is a very good reason for a deamon to handle its > own backgrounding: The sensible convention is it that it > should only background at the instant where it is ready to > service requests: If there is a long initialisation phase > it should stay in the foreground - so that things that > depend on it in turn do not get started too soon. A more > detailed description of this problem I wrote up a while ago > at welz.org.za/notes/on-starting-daemons.html. Nice write up. Explains the issues clearly. > More fundamentally: If an application has problems calling the > a daemonize() or fork_parent() function or the handful of system > calls that make up this, then maybe this a limitation of the > development environment or language - if calling these this is regarded > to be hard then one wonders how reliable the rest of the program is. > > regards > > marc > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Why daemontools is so cool
On Sun, 29 Mar 2015 11:15:49 +0200 marc wrote: > > No need to mix doubleforking and PID tracking on your > > program. That should be the duty of whatever daemonizes and manages > > your program. You know, like Daemontools or s6. > > So there is a very good reason for a deamon to handle its > own backgrounding: The sensible convention is it that it > should only background at the instant where it is ready to > service requests: If there is a long initialisation phase > it should stay in the foreground - so that things that > depend on it in turn do not get started too soon. A more > detailed description of this problem I wrote up a while ago > at welz.org.za/notes/on-starting-daemons.html. > > More fundamentally: If an application has problems calling the > a daemonize() or fork_parent() function or the handful of system > calls that make up this, then maybe this a limitation of the > development environment or language - if calling these this is > regarded to be hard then one wonders how reliable the rest of the > program is. > > regards > > marc This is one of the many reasons I enjoy being on the Dng list. While the Debian-User guys wring their hands over how to use NetworkManager, we're discussing stuff like this. First, congrats on writing the excellent resource http://welz.org.za/notes/on-starting-daemons.html . Nice! I never thought about half that stuff before reading your resource. As best I can interpret the trystart() and doit() functions in daemontools' supervise.c, daemontools' supervise executable forks, the parent records the PID of the child, and the child does an execve() on the directory's ./run script. There's no *double*fork because daemontools specifically does *not* want to separate the service (daemon, whatever you want to call it) from its parent supervise command. It wants supervise to have control of the daemon at all times. Your resource clarifies the fact that there are many distinct reasons for having the daemon "in the background", including: 1) Out of sight, out of mind 2) User can't easily accidentally kill it 3) No resources wasted by terminals and the like 4) Backgrounding can serve as a signal that your daemon is ready to service requests 5) Stay foreground long enough to show error messages All 5 are, of course, exactly right. 1-3 really just define "backgrounding" as "no interactive terminal". #5 would show initialization messages on the terminal presumably during boot, and that's a good thing. #4 opens up a big old can of worms when it comes to dependencies ... Let's say my home-grown magic_sync daemon requires my home-grown sync_exchanged daemon to be completely functional, and sync_exchanged has extensive setup before it's ready to exchange. magic_sync shouldn't be run until sync_exchanged is not only running, but ready to service requests. So what you're saying is for sync_exchanged to background itself when ready to handle requests, with suitable plumbing so that sync_exchanged's init and service PIDs are identical. My point is that being background is not the only possible sentinel for "ready to service requests". sync_exchanged could write a sentinel file to indicate that. Or it could have a tiny additional executable that does nothing but query the daemon for readiness to service. Or it could offer a task doable only when ready to service. An example of the latter is that all my network-requiring daemons try pinging 8.8.8.8 before becoming daemons. Being background is one sentinel, but there are many others. Now let's look at how daemontools handles all of this... Daemontools manages a foreground program, because that's the way you can absolutely, positively, nonambiguously track the PID, without artifacts like PID files that can go stale or get erased, and without all sorts of guesswork from parsing ps ax or /proc. Whatever daemontools does, no individual terminal is required, and the service is out of sight, out of mind unless you specifically look at the log file, and the user can't easily accidentally kill it. Daemontools reveals all error messages via its logging mechanism, assuming you write the ./run and log/run scripts right, and doing so is trivial. That leaves the sentinel function. I think you and I agree that a daemon's "ready to service requests" sentinel must be written by the daemon's programmer, whether it be backgrounding, or a sentinel file, or a test. And it must be documented. But of course, we know that few programmers deliberately program in a sentinel, and almost none document it. Most of the time, either the distro or the computer's user/admin must question those sentinels himself. In the case of daemontools, it's usually as simple as making a no-block test that succeeds if the dependency is servicing requests. For instance, to test a network and make sure it blocks for only 1 second, you could use: ping -c1 -W1 8.8.8.8 If a daemon depends on a functional nfs, you could try a mount of something harmless that you kn
Re: [Dng] Another reason of why I am considering Devuan
On Sun, Mar 29, 2015 at 03:07:43PM +0200, Martin Steigerwald wrote: > Hi! > > See this one: > > Bug#761658: Please do not default to using Google nameservers > > Marco tagged it as "wontfix". Seriously, if I didn´t configure a > nameserver I *mean* it. I don´t want it to just choose a Google nameserver > then, without even telling me. > That's most probably another workaround to avoid systemd freezing on boot... And even if the systemd-nonsense would not be involved in this, I still don't want a DNS set by default during installation and I don't want anybody to force me doing that... That's why users chose Debian, once upon a time: because it didn't come with any pre-packed policy to constrain whatever use you would like to make of the system. But apparently time is now flying faster, and things are changing more quickly, and always in the same direction: just for the bad. I couldn't ever imagine that anybody would be able to trash Debian in such a deliberate and lighthearted way, and in such a short timeframe :( Sadness 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
[Dng] nameservers
On Sun, Mar 29, 2015 at 11:22:01PM +, KatolaZ wrote: > On Sun, Mar 29, 2015 at 03:07:43PM +0200, Martin Steigerwald wrote: > > Hi! > > > > See this one: > > > > Bug#761658: Please do not default to using Google nameservers > > > > Marco tagged it as "wontfix". Seriously, if I didn´t configure a > > nameserver I *mean* it. I don´t want it to just choose a Google nameserver > > then, without even telling me. > > > > That's most probably another workaround to avoid systemd freezing on > boot... And even if the systemd-nonsense would not be involved in > this, I still don't want a DNS set by default during installation and > I don't want anybody to force me doing that... Why I've never understood is why it's not the default for a Debian installation to have its own nameserver. Is there a reason to trust anyone else's nameserver? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] nameservers
On Sun, Mar 29, 2015 at 08:27:01PM -0400, Hendrik Boom wrote: > Why I've never understood is why it's not the default for a Debian > installation to have its own nameserver. > > Is there a reason to trust anyone else's nameserver? Without DNSSEC, it's a fair tradeoff (no caching, but you have one less daemon to run) -- and anyone on the path can feed you bogus data anyway. But if we're trying to be secure, running the last mile over an untrusted network means you could as well not bother with DNSSEC. And outside of controlled setups, the only trusted network is localhost. So even with the most benevolent DNS server operator, you should run one locally. But in this case, we're talking of a company whose income relies on gathering tracking data. By defaulting to 8.8.8.8, resolvd effectively feeds metadata on almost any TCP/IP connection you make to Google. In other words, the bug that's being wontfixed here is a massive security/privacy hole. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Another reason of why I am considering Devuan
KatolaZ wrote on 03/29/15 18:22: > On Sun, Mar 29, 2015 at 03:07:43PM +0200, Martin Steigerwald wrote: >> Hi! >> >> See this one: >> >> Bug#761658: Please do not default to using Google nameservers >> >> Marco tagged it as "wontfix". Seriously, if I didn´t configure a >> nameserver I *mean* it. I don´t want it to just choose a Google nameserver >> then, without even telling me. >> What a bizarre thread[1]. It is almost painful to read. I can't imagine a circumstance where I would ever want the system doing the exact opposite of what I've configured it to do. Nor can I imagine a circumstance where anyone would want that. [1] https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1311795.html ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
