Re: [DNG] Conversion script: was Formail for managing digests
On Mon, 2 Dec 2019 10:13:01 +0100 Edward Bartolo via Dng wrote: > Dear All, > > Inits need to understand unit files, give them that functionality. > That is far more efficient compared to what you are doing. > > Pseudo Code: > 1) check for the presence of a unit file > 2) if it exists > a) branch to function to read unit file and run daemon > b) if NOT execute shell script to run daemon > > Programming allows to create a configuration text file which tells an > init to be aware of the existence of unit files. This can be used to > minimize the incidence of bugs for cases where no unit files are used. > The extra functionality can be debugged in separate functions. IMHO the preceding is complexity you don't need, at least if I read you correctly and you're suggesting non-systemd inits process Unit Files at boot time. The startup files, be they init scripts, run scripts or Epoch .conf files, can be done offline using a conversion plus testing and touchup, and then used at boot time. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On Tue, 3 Dec 2019 09:02:14 +0100 Denis Roio wrote: > On Sat, 30 Nov 2019, Hendrik Boom wrote: > > > On Fri, Nov 29, 2019 at 07:21:54PM +0100, Massimo Coppola wrote: > > > > > > > > If (assuming that) we are going to lose the source of init scripts > > > upstream, then it's the only way forward. (For those who consider > > > recognizing the unit files as a valid source a defeat: I may agree > > > with you, but sometimes a strategic retreat can lead to victory). > > > > > > > If we are worried about losing init scripts upstream, I suggest we > > maintain a version-controlled collection if initscripts somewhere so > > that if one disappears from a package we can restore it. > > This is what I'm really unsure of, so far. Every time I tried to > debate this with someone knowing Debian better than I do, we ended in > disagreement. > > My opinion however is this: maintaining a *unique package* of version > controlled init scripts in Devuan is much, much easier than > maintaining a sysvinit script in each different package, forking it. You'll get no arguments from me. From the very beginning, I didn't think either "upstreams" or daemon package maintainers should be responsible for init scripts, run scripts, or Epoch conf files. It was this responsibility and the burden thereof that caused the DSs to support systemd and *only* systemd: They were tired of supporting sysvinit scripts, which I think we all admit are atrocities. But to a person familiar with sysvinit, they're probably all similar. Run the dependencies, then run the daemon. Kill means kill the daemon, and then if the dependencies are dependencies only of the daemon, kill them. Reload means sending the proper signal, and restart means stop then start. There are also a few logging issues. I'm not sure why this adds up to more than 200 lines in so many cases, and maybe if we had professional sysvinit init script maintainers, it wouldn't. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On 12/3/19 10:02 AM, Denis Roio wrote: > My opinion however is this: maintaining a *unique package* of version > controlled init scripts in Devuan is much, much easier than > maintaining a sysvinit script in each different package, forking it. > > I'm not sure about pressing counter-arguments against this. maybe i'm wrong, but what if this unique package turns into a single point of failure for all running daemons (?) haven't given it much thought, just sayin'. d. signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On Sat, 30 Nov 2019, Hendrik Boom wrote: > On Fri, Nov 29, 2019 at 07:21:54PM +0100, Massimo Coppola wrote: > > > > > If (assuming that) we are going to lose the source of init scripts > > upstream, then it's the only way forward. (For those who consider > > recognizing the unit files as a valid source a defeat: I may agree > > with you, but sometimes a strategic retreat can lead to victory). > > If we are worried about losing init scripts upstream, I suggest we > maintain a version-controlled collection if initscripts somewhere so > that if one disappears from a package we can restore it. This is what I'm really unsure of, so far. Every time I tried to debate this with someone knowing Debian better than I do, we ended in disagreement. My opinion however is this: maintaining a *unique package* of version controlled init scripts in Devuan is much, much easier than maintaining a sysvinit script in each different package, forking it. I'm not sure about pressing counter-arguments against this. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Conversion script: was Formail for managing digests
Dear All, Inits need to understand unit files, give them that functionality. That is far more efficient compared to what you are doing. Pseudo Code: 1) check for the presence of a unit file 2) if it exists a) branch to function to read unit file and run daemon b) if NOT execute shell script to run daemon Programming allows to create a configuration text file which tells an init to be aware of the existence of unit files. This can be used to minimize the incidence of bugs for cases where no unit files are used. The extra functionality can be debugged in separate functions. -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) If you cannot make abstructions about details you do not understand the concepts underlying them. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On 2019-11-30 14:15, Hendrik Boom wrote: On Fri, Nov 29, 2019 at 07:21:54PM +0100, Massimo Coppola wrote: If (assuming that) we are going to lose the source of init scripts upstream, then it's the only way forward. (For those who consider recognizing the unit files as a valid source a defeat: I may agree with you, but sometimes a strategic retreat can lead to victory). If we are worried about losing init scripts upstream, I suggest we maintain a version-controlled collection if initscripts somewhere so that if one disappears from a package we can restore it. -- hendrik Are you volunteering to build and maintain that collection? golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On Fri, Nov 29, 2019 at 07:21:54PM +0100, Massimo Coppola wrote: > > If (assuming that) we are going to lose the source of init scripts upstream, > then it's the only way forward. > (For those who consider recognizing the unit files as a valid source a > defeat: I may agree with you, but sometimes a strategic retreat can lead to > victory). If we are worried about losing init scripts upstream, I suggest we maintain a version-controlled collection if initscripts somewhere so that if one disappears from a package we can restore it. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
Hi all, long time as a silent lurker, but is seems well time to get up and act. Although today I'm just about writing about doing, so feel free to ignore me. English is not my first language, so if I use inappropriate writing tone, I apologize now and please let me know about my errors. The exchange of ideas on converting init script is needed and I've seen plenty of interesting comments and proposed solutions. On 29/11/2019 18:17, s@po wrote: On Fri, 29 Nov 2019 12:15:29 +0100 Didier Kryn wrote: Le 29/11/2019 à 02:08, s@po a écrit : freedesktop.org, should adress the situation, I don't trust Freedesktop to produce a good quality standard. I don't know who are the people behind Freedesktop, beyond Gnome and KDE, but they have produced Dbus and also the practice to automatically create unwanted directories in your home, unless you disable them explicitely. If "unit" files are something which can be retained (after all, there might be one non-negative outcome of Systemd), they can be used to produce init scripts for various init systems, or these init systems could be made able to, optionnaly, read their configuration from "unit files". If (assuming that) we are going to lose the source of init scripts upstream, then it's the only way forward. (For those who consider recognizing the unit files as a valid source a defeat: I may agree with you, but sometimes a strategic retreat can lead to victory). I don't trust them neither.. But, they should have addressed this problem after all they were waving the flag of standards.. They seems to forgot a Standard Init API mechanism.. shame.. I spoke about that because I took 5 minutes to look at last development of SysVInit, and indeed you find there some stuff about systemd and dbus integration.. I understand the dbus integration as a way, so that SysVinit daemons could coexist with Dbus controlled daemons.. The Idea arrived.. Why not have an Interpreter, for the UnitFiles, that then internally do things as SysVInit does? In this way we could preserve SysVinit daemons functionality, and when impossible( or a "unscallable wall arrive".. ), SysVinit will continue to control, the usual daemons, plus the wave of non SysVinit ones( in the mean time we could have time to port daemons at the speed we can.. ). So this idea is some sort of a patched SysVinit, to have half of the 'Script Injector' idea( the interpreter of unit files part ), and some logic to do it like sysVInit does.. But that would also means.. that we had to have in /etc/init.d/, all the s*tty systemD service files.. which is a bit crazy.. Fascinating, but I'd like to explain my viewpoint about this idea. My impression is that it is viable building a batch init script generator, where package maintainers are able to check and validate the newly generated init scripts *in the maintainer test system*, as well as take care of any peculiar bug of the translation, or quirky behaviour of the unit files. As it's systemd we are talking about, I wouldn't ever place a bet on stable and documented behaviour on its part. Otherwise we wouldn't be here on devuan ML, after all. When new peculiar behaviour is discovered, we can adapt the initscript generator. This would mean a huge effort on repacking debian packages, or having blanket-like packages with init"scripts" for SysV/openrc/any_init that provide the init support to all/groups of debian packages, possibly synced with major revisions of devuan. On the other hand, a unitfile *interpreter* is a different story, I'm not sure this is viable as of now, and the risks look greater to me in this case. IMO there are two scenarios. 1) the interpreter is external to SysVinit/any_init init and is called after each package update (by means of apt ?). Still, any bug that creeps through by leveraging unexpected unit file behaviour will risk of breaking the interpreter *in the devuan user system*, and this would negatively affect devuan reliability. Imagine the backfire of a situation where the interpreter fails after a security update for some obscure change in a unit file, so at service start/stop or at next reboot the system goes astray. 2) the interpreter is run by the init process (bound to it some way) and used each time a script is accessed. I'd rather not see this, more complexity of this kind in the init process is bad for system health. I agree the interpreter idea is technically intriguing, but bot scenarios are a bit too close to reimplementing systemd, IMO. I'd rather develop something useful to the mantainers now, and keep the option to turn it into a package for the end user later on. So I'd first go with 1) the offline translation, 2) get it stable enough that it can run automatically on any debian package updates, 3) monitor the amount of bugs and manual corrections needed, then 4) enable the initscript to be automatically generated and added to packages in devuan, 5) monitor ag
Re: [DNG] Conversion script: was Formail for managing digests
On Fri, 29 Nov 2019 12:15:29 +0100 Didier Kryn wrote: > Le 29/11/2019 à 02:08, s@po a écrit : > > freedesktop.org, should adress the situation, > > I don't trust Freedesktop to produce a good quality standard. I > don't know who are the people behind Freedesktop, beyond Gnome and KDE, > but they have produced Dbus and also the practice to automatically > create unwanted directories in your home, unless you disable them > explicitely. > > If "unit" files are something which can be retained (after all, > there might be one non-negative outcome of Systemd), they can be used to > produce init scripts for various init systems, or these init systems > could be made able to, optionnaly, read their configuration from "unit > files". > I don't trust them neither.. But, they should have addressed this problem after all they were waving the flag of standards.. They seems to forgot a Standard Init API mechanism.. shame.. I spoke about that because I took 5 minutes to look at last development of SysVInit, and indeed you find there some stuff about systemd and dbus integration.. I understand the dbus integration as a way, so that SysVinit daemons could coexist with Dbus controlled daemons.. The Idea arrived.. Why not have an Interpreter, for the UnitFiles, that then internally do things as SysVInit does? In this way we could preserve SysVinit daemons functionality, and when impossible( or a "unscallable wall arrive".. ), SysVinit will continue to control, the usual daemons, plus the wave of non SysVinit ones( in the mean time we could have time to port daemons at the speed we can.. ). So this idea is some sort of a patched SysVinit, to have half of the 'Script Injector' idea( the interpreter of unit files part ), and some logic to do it like sysVInit does.. But that would also means.. that we had to have in /etc/init.d/, all the s*tty systemD service files.. which is a bit crazy.. Best Regards, tux -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
Le 29/11/2019 à 02:08, s@po a écrit : freedesktop.org, should adress the situation, I don't trust Freedesktop to produce a good quality standard. I don't know who are the people behind Freedesktop, beyond Gnome and KDE, but they have produced Dbus and also the practice to automatically create unwanted directories in your home, unless you disable them explicitely. If "unit" files are something which can be retained (after all, there might be one non-negative outcome of Systemd), they can be used to produce init scripts for various init systems, or these init systems could be made able to, optionnaly, read their configuration from "unit files". Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
Hello All, On Thu, 28 Nov 2019 16:30:41 -0500 Steve Litt wrote: > On Wed, 27 Nov 2019 12:18:55 -0600 > goli...@devuan.org wrote: > > > More fiddling while Rome burns . . . sigh . . . > > > > I'm in a bit of a mood because I thought that a script to convert > > systemd units to init style shell scripts would be worthy of at least > > some discussion. > > > > golinux > > I have good news, bad news, and better news. > > Good news. The latest script at http://www.trek.eu.org/devel/sysd2v/ > appears to make good sysvinit init scripts from a unit file. > > Bad news: That script is just for sysvinit, and in my 1/2 hour look at > it I couldn't find an easy way to pick off info necessary to make > facilities for s6, runit or Epoch. > > Better news: Systemd Unit Files are a pretty good specification of what > any process supervisor should do with a daemon, so converters for s6, > runit and Epoch should be pretty easy to make. Because declaratory Unit > Files are by necessity a superset of script based systems, some human > intervention will be necessary, but not a whole lot. > > Better news: There's an already made collection of runit run scripts, > for the usual suspects, at http://smarden.org/runit/runscripts.html . > I've put out a query for a similar collection of s6 scripts. > > SteveT We have a problem that is already a hipotsis of been solved converting the Service Units, to SysVinit daemons.. Since the Unit Files in SystemD, are "unit...", could we theoretically implement the Stub Interface for the Unit Files in SysVInit, and them threat the cases has we want to??? Because the problem with inits, in Unix Like Systems is that is there NO Standars today.. freedesktop.org, should adress the situation, like they have done in the past with other things.. Nowadays Desktop is more or less standardized.. filesystem more or less... For Init Systems.. theres is no public Standard... So or freedesktop.org adress the case or it will be like a jungle( it is now.. ).. We can also have 2 fronts... 1) Convert the unit.files from SystemD to SysVInit daemons 2) Adapt an API like, only for the unit. files that describe the Services, like a stub, an adaptor, and add it to sysVInit In the 2nd case we parse the unit.files and work the meaning as we want to( but without creating SysVinit files, since we already have what is needed to launch the service.. , **The problem is to control this pseudo service after is running**.. ) ofcourse its a lot easier to talk than do it.. but that would give us plenty of time to recreate the SysVInit script we want to, after that.. But that also means that the Unit.Files language used to describe SystemD services will be "more closer to a standard".. Could be a situation were SysVInit can support the traditional SysVInit daemons, usual runlevels, and such, and interprete the unit files of SystemD, but atribute them to this runlevels?? What do you think? I just want to add my 2 cents,. because I think that any one of this 2 cases is a valid case.. -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Conversion script: was Formail for managing digests
On Wed, 27 Nov 2019 12:18:55 -0600 goli...@devuan.org wrote: > More fiddling while Rome burns . . . sigh . . . > > I'm in a bit of a mood because I thought that a script to convert > systemd units to init style shell scripts would be worthy of at least > some discussion. > > golinux I have good news, bad news, and better news. Good news. The latest script at http://www.trek.eu.org/devel/sysd2v/ appears to make good sysvinit init scripts from a unit file. Bad news: That script is just for sysvinit, and in my 1/2 hour look at it I couldn't find an easy way to pick off info necessary to make facilities for s6, runit or Epoch. Better news: Systemd Unit Files are a pretty good specification of what any process supervisor should do with a daemon, so converters for s6, runit and Epoch should be pretty easy to make. Because declaratory Unit Files are by necessity a superset of script based systems, some human intervention will be necessary, but not a whole lot. Better news: There's an already made collection of runit run scripts, for the usual suspects, at http://smarden.org/runit/runscripts.html . I've put out a query for a similar collection of s6 scripts. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
