From: jerry@example.invalid   
      
   Sylvain Robitaille  wrote:   
   > On 2024-04-03, Sam wrote:   
   >   
   >> Well, the future progress would probably be on a steady-but-slow side,   
   >> since  its functionality is complete, and I can't think of anything   
   >> more to add  after one more enhancement that I have in the current   
   >> pipeline.   
   >   
   > ... and that, in my opinion, is ok: it does what it was intended   
   > to do, and assuming you find no major bugs, (and modulo the one   
   > more enhancement) you consider it complete.  Time to move on to a   
   > new project.  In some circles, it seems that if you cease further   
   > development, your software is suddenly obsolete and undesirable.  I   
   > wouldn't agree.   
   >   
   >> ... I have little interest in socket  activation, a cron/timer   
   >> replacement, the whole systemd kitchen sink.   
   >   
   > ... and I thank you for that ...  ;-)   
   >   
   >> initscripts in Slackware 15 have at least one hidden defect. With   
   >> networkmanager enabled with its default dhcpcd configuration: stopping   
   >> it  manually will leave a daemon process hanging.   
   >   
   > Hrmmm... interesting.  I'll need to look into that on my Slackware-15   
   > systems (though I likely won't have any time to for a few weeks at   
   > least; I'm in the middle of a major relocation).  I can see that this   
   > could be missed, though, as for most poeple, networkmanager runs   
   > and stays running until it's time to shut the system down entirely   
   > (or reboot, etc.)  Still, there's certainly a fix for that particular   
   > bug that wouldn't involve replacing initd.   
   >   
      
   2 possible fixes:   
   1) use NM's internal dhcp client (my solutions).   
   2) put a script to kill dhcpcd in   
   '/etc/NetworkManager/dispatcher.d/pre-down.d'   
      
   IIRC it also causes exraneous dhcpcd processes when you   
   sleep/hibernate the system.   
      
   >> Shutdown is not clean.   
   >   
   > Perhaps, but as you point out, it's masked by the call to killall.   
   >   
   >> This is  gets handled by shutdown/reboot running killall, but will   
   >> come to light if  someone were to try to shut things down manually   
   >> (emergency IDS panic comes  to mind).   
   >   
   > Right ... "/etc/rc.d/rc.networkmanager stop", for example; but would it   
   > *matter*, even then, unless you stopped and started rc.networkmanager   
   > repeatedly?   
   >   
   >> A container will catch this, and clean it up. This is one argument in   
   >> favor  of a modern, container-based init replacement.   
   >   
   > Sure; I don't doubt that there are arguments in favour, but as I noted   
   > in an earlier message, folks should be able to *choose* to install   
   > something like this on a case-by-case basis, with a plain-Jane,   
   > ordinary but reliable initd as the default.  Some systems don't make   
   > it an option.   
   >   
   > For what it's worth, I probably would argue that you're addressing   
   > the symptom rather than the cause.  That said, it's not to dissuade   
   > you, nor to suggest that I can't imagine any use cases for your   
   > "containerized initd", but rather to suggest why I might still prefer   
   > to keep the ordinary initd.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)