Re: [DNG] Fwd: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]
dear Hendrik, On Wed, 12 Apr 2017, Hendrik Boom wrote: > Well, the official policy, insofar as there is one, appears to be that [...] thanks for writing down such a clear statement on the matter, its helping us to complete the release announcement which now includes this section about Init Freedom: "" At last, Devuan is about choice. We think people should be able to choose whether to use a GNU+Linux system with or without systemd. Two and a half years ago Devuan decided to split off because Debian has made it difficult to avoid systemd, ignoring the needs of half of its population. Devuan is a new start, growing with your help and donations, but still with limited resources compared to Debian, so we focus on providing the missing alternative: a GNU+Linux system without systemd. We support potential Devuan users who wish to use systemd by having them use Debian's installer, Debian's packages, and Debian's mailing lists, all available directly from Debian's mirrors. "" ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On 16.03.2017 12:10, Didier Kryn wrote: > Many free software developper teams proved already they are mostly > working for themselves - eg Gnome, KDE, Firefox. When people develop > software for free, they put a lot of their ego in it, and this goes > against the ability to recognize ones own mistakes or bad decisions; I > think this is the weak point of free software. Well, that also applies to us, also any distro, and I dont see a major problem here. We just need some way to reduce the amount of duplicate work. Several years ago, I started a project called 'oss-qm' which aimed to collect maintenance branches for lots of packages, which solve the common problems in a generic way (instead of all the dist specific patches), so distros can base their branches on that. The problem then wasn't systemd (which handn't been invented yet), but poor upstream QM. Unfortunately, nobody jumped up and it was way too much for me alone. Maybe Devuan could be a good place for giving it a fresh start. We'd also collect all the depotterizing patches (along w/ others) there and regularily post our queues to the upstreams. I'm pretty agnostic on how the process actually works, just a small set of requirements: * always the full trees in a git repo * dist-specific branches should be named w/ / prefix and contain all build files, w/o additional patching (IOW: patches already applied instead of extra files) * for each supported version there should be separate maint branch, where the dists can base theirs on * some (per package) central repo where all branches from around the world are collected. Anybody here interested in that ? > They just don't care, as long as developpers comply with their > requirements. Even some developpers are only concerned with the amount > of work implied for them by the init system, and prefer systemd just > because of that - good example in the thread pointed by > dotcom...@autistici.org: > https://lists.gnu.org/archive/html/libreplanet-discuss/2017-03/msg00017.html. application developers should't ever provide any dist specific stuff like init scripts (except examples). instead should tell what's necessary for running their stuff. > Look, today Devuan lives with using mostly Debian packages, a small > fraction of which being de-poetterized. That's already a good thing, and really should be continued. But the corresponding patches should also go to the upstreams. > Debian will continue living by mirroring Devuan and poetterizing some > of the packages; they'll not give up. That would be quite a fun. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On Fri, Apr 14, 2017 at 09:14:32AM +0200, Enrico Weigelt, metux IT consult wrote: [cut] > > > Look, today Devuan lives with using mostly Debian packages, a small > > fraction of which being de-poetterized. > > That's already a good thing, and really should be continued. But the > corresponding patches should also go to the upstreams. > ...err...by upstream you mean Debian? Then I am lost. Most of the systemd-specific stuff in those packages has been added by the Debian packagers themselves, to abide to the plans of conqering the world with a Blitzkrieg. People are struggling to get those silly deps out, and now you would like those patches to go back to Debian? Again, to what avail? Try to submit a patch like that by yourself, and see how long does it take for the "PLONK" sound to he heard loud and clear, from a distance. Debian has made her decision. I know it's hard to believe for a long-time Debianist, but they have effectively no intention of supporting anything else than systemd. You should try to accept this as a fact, after 30 months, go through the the appropriate bereavement, and move on. KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New documentation on the Surf browser
On 10.03.2017 07:30, Steve Litt wrote: > Hi all, > > I've just finished an extensive and complete document on installing, > modifying and using the Surf browser, and judging from yesterday's > biggest thread, not a moment too soon. Having a little package that glues them all together, to have a small tabbed browser out of the box. One important thing for me is automatic session save/restore, and a way to quickly stash away open tabs (like onetab for chrome does). --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On 14.04.2017 09:49, KatolaZ wrote: > On Fri, Apr 14, 2017 at 09:14:32AM +0200, Enrico Weigelt, metux IT consult > wrote: > ...err...by upstream you mean Debian? Then I am lost. I meant the actual upstreams, but dists like debian too. > Most of the systemd-specific stuff in those packages has been added by > the Debian packagers themselves, to abide to the plans of conqering > the world with a Blitzkrieg. I guess we just wouldn't take those patches into our queues. If those area the only ones, we'll have an empty queue, therefore nothing to be sent. Of course, sooner or later we'd want some kind of tracking, which patches we've already processed, so we eg. never look again on the rejected ones. > Debian has made her decision. I know it's hard to believe for a > long-time Debianist, but they have effectively no intention of > supporting anything else than systemd. Well, let's see. I dont intend to spend much time (as w/ any other distro I'm not using myself). Just some (semi-)automatic posting, just a little glue around git-send-email called by cron ... Actually, I'm seeing that not limited to depotterization (that's just a good usecase to start with), but any patches that some distro (or in embedded case: bsp maintainer) might add ontop certain upstream tree and can be useful for others. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]
On 13.04.2017 09:27, Klaus Ethgen wrote: > Take for example openssh, I provide patched packages on my server that > remove the patches of debian that lower ssh security for just gaining a > bit more comfort. What are they aiming to "improve" here ? > However, in the recent days it was even not possible > anymore to build as it build depend on libsystemd-dev that is starting > to depend on systemd itself. What exactly has happened here ? Is it just the debian package or openssh upstream itself ? BTW: just looking at debian patches (jessie) ... haven't seen anything like that yet. But it seems they still haven't learn that patching autogenerated files isn't a good idea. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 13.04.2017 08:00, Joachim Fahrner wrote: > This is impossible with a binary distribution. systemd is not only an > init system, it pervades the whole system. You can either compile > packages with systemd libraries or without. But you have to decide that > at compile time. That's exactly what I'm trying to solve here by an *tiny* generic API. Let's just take some example: libsrvmgt with funcs like that: * srvmgt_daemonize() --> detach from controlling terminal, etc * srvmgt_droppriv(...) --> drop root privileges (if we are still root) --> several versions, eg. with fetching the target uid/gid from env * srvmgt_report_state(...) --> report the service state to the supervisor --> states could be eg. * SRVMGT_STATE_STARTUP -- still within the startup phase * SRVMGT_STATE_READY_LOCAL -- ready for local clients only * SRVMGT_STATE_READY_ALL -- ready for all clients * SRVMGT_STATE_BUSY-- too busy to process new requests * SRVMGT_STATE_SHUTDOWN-- shutting down, still finishing queued requests * SRVMGT_STATE_DEFERRED-- temporarily can't accept new requests (eg. overload) * SRVMGT_STATE_WAITING -- wait for resource (eg. printer needs paper or ink) * SRVMGT_STATE_OFFLINE -- completely offline (eg. due some fatal error) For start, we'd just write a small library, that logs to syslog, perhaps maintains some pidfiles (maybe even a *compile-time* option to route directly to libsystemd), then patch up packages that currently use libsystemd to use our new one. Actually, that lib would be so small, that it IMHO wouldn't even hurt when upstreams adopted it w/o opt-out. Later on, other folks can easily implement that for the service monitors of their choice. For binary packaging, the distro would at least provide the almost-dummy version above, and additional ones fitting the individual service monitors. Just as w/ many other similar cases, there would be some virtual package 'libsrvmgt' and various real packages, and the individual service monitors / init systems would depend on their supported real packages. At this point, there wouldn't be any technical reason for anybody potterizing a package for the sake of service reporting. Packages can just depend on that API, while nobody is bound to a specific implementation. Thefore no need for any conflict anymore (at least in that area). --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] overriding install paths in debian/rules
On 08.03.2017 15:37, aitor_czr wrote: > But that's good: imagine, for example, someone downloading the sources > of linux-libre from the fsfla's website. He will not be able to add a > binary file using quilt; so, pristine-tar will be enough to verify the > lack of binary blobs. So, you consider adding (binary) pictures a bad idea in general ? --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FF pulseaudio hard dependency is here
On 08.03.2017 18:59, goli...@dyne.org wrote: > Me either and many others on this list - there have been several > pulseaudio threads on dng over the years. But that is not the point. > Unless FF 52 onward is recompiled with the alsa switch enabled, it will > be unusable for most of us. So this is a heads up that someone will > have to step forward to do this if it is not worked out upstream. Care > to take that on? Somebody here who already went through the hell of compiling and packaging FF from upstream sources ? --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FF pulseaudio hard dependency is here
On 08.03.2017 19:30, KatolaZ wrote: > "...WE ARE THE BORG. LOWER YOUR SHIELDS AND SURRENDER YOUR SHIPS. WE > WILL ADD YOUR BIOLOGICAL AND TECHNOLOGICAL DISTINCTIVENESS TO OUR > OWN. YOUR CULTURE WILL ADAPT TO SERVICE US. RESISTANCE IS FUTILE..." We all know the borg can be defeated. Actually, they offer a lot of other attack vectors that never had been played out in the shows. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FF pulseaudio hard dependency is here
On 09.03.2017 07:45, KatolaZ wrote:
> I have made a quick search, and it seems that the problem is, again,
> in the fact that people prefer overkills to simple solutions.
Yeah, they invented their own private "cross platform API" - as there
wouldn't already be enough out there, that just could be used.
OTOH, having an own video streaming within the browser (the same
silliness in chrome) also is just making everything complicated.
They just could have used gstreamer and get hw decoding for free.
> Midori (aside with many other browsers) is using XBEL, an XML format to
> store bookmarks, which was introduced not because another file format
> for bookmarks was needed, but rather to showcase the abilities of the
> PyXML module (google "XBEL bookmarks" to find out more details about
> this unbelievable yet interesting story...).
These folks could just sit together and design an browser agnostic
bookmarks library and let everybody pick the backend he wants.
Could even be done as an small 9P service.
> And it seems that the main developer of Midori finds it quite
> complicated (sic!) to transform a Netscape (html) bookmark files (or
> any other bookmark format, for that matter) into XBEL. There you
> go. You can still export your bookmarks into html format and browse
> that file :\
What's so complicated w/ netscape html bookmarks ?
> The reason why one wants to use XML to store bookmarks still defies my
> very primitive logic, though, since implementing a tag-based bookmark
> systems requires 28 lines of shell script (attached below), of which
> only 9 contain actual shell code...
Maybe, because that would be too easy ? :o
> #!/bin/sh
>
> ##
> ## Simple script to manage bookmarks
> ##
> ## If run without arguments, provide a dmenu list of current
> ## bookmarks, and paste the selection to the primary
> ## clipboard. Otherwise, add a new bookmark, and set the
> ## decription/tag to the arguments provided on the command
> ## line.
> ##
> ## KatolaZ -- 2015
> ##
>
> BKFILE=$(realpath "${HOME}/.surf/bookmarks.txt")
>
>
> if [ $# -ge 1 ]; then
> ## adding a new bookmark from the primary selection
> URL=$(xclip -o)
> echo "${URL} | $@" >> ${BKFILE}
> else
> ## Searching the bookmark file...
> ## Get an URI
> SEL=$(cat ${BKFILE} | dmenu -l 5)
> ##echo "Selected: ${SEL}"
>
> URL=$(echo "${SEL}" | cut -d "|" -f 1)
> echo "${URL}" | xclip -f
> fi
hmm, looks like a nice addition to the surf package.
--mtx
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Fri, Apr 14, 2017 at 10:57:01AM +0200, Enrico Weigelt, metux IT consult wrote: [cut] > * srvmgt_daemonize() > --> detach from controlling terminal, etc > * srvmgt_droppriv(...) > --> drop root privileges (if we are still root) > --> several versions, eg. with fetching the target uid/gid from env > * srvmgt_report_state(...) > --> report the service state to the supervisor > --> states could be eg. > * SRVMGT_STATE_STARTUP -- still within the startup phase > * SRVMGT_STATE_READY_LOCAL -- ready for local clients only > * SRVMGT_STATE_READY_ALL -- ready for all clients > * SRVMGT_STATE_BUSY-- too busy to process new requests > * SRVMGT_STATE_SHUTDOWN-- shutting down, still finishing > queued requests > * SRVMGT_STATE_DEFERRED-- temporarily can't accept new > requests (eg. overload) > * SRVMGT_STATE_WAITING -- wait for resource (eg. printer > needs paper or ink) > * SRVMGT_STATE_OFFLINE -- completely offline (eg. due some > fatal error) > > For start, we'd just write a small library, that logs to syslog, > perhaps maintains some pidfiles (maybe even a *compile-time* option > to route directly to libsystemd), then patch up packages that currently > use libsystemd to use our new one. > I personally don't see why one would like to redo libsystemd0 from scratch, as you seem so kee of doing. Go on down your path, but I suspect not many people would cheer at you in this camp... HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Announcing the git.devuan.org connection
On 07.03.2017 07:15, Ralph Ronnquist wrote: > The Projects forum (https://dev1galaxy.org/viewforum.php?id=18) > organizes Devuan projects into two categories - "devuan-packages / > infrastructure" and "other projects". Both categories are presented as > alphabetical and activity ordered lists. The project lists offer a short > description (if available) and a convenient, single-click access to all > projects at git.devuan.org. > > The Issues forum (https://dev1galaxy.org/viewforum.php?id=19) holds > threads that are automagically created by dev1galaxy's trusty "gdolink" > bot, from all open issues at git.devuan.org. The bot will add newly > opened issues (if any) to the Issue lists, every 30 minutes. Posting > these issues on d1g will give greater exposure to issues that are > currently buried in the gdo 'cave' (which is perceived as inaccessible > by some). Opening parallel forum threads provides opportunity for > discussion and collaborative problem solving that will accelerate > Devuan's progress and usability. Could we bridge it to maillists ? (maybe one list per forum) --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]
goli...@dyne.org wrote on 04/13/2017 12:51 PM: > How about Systemd OS running on a Linux kernel. > > golinux .. or more simply, SOL ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On Fri, 14 Apr 2017, Enrico Weigelt, metux IT consult wrote: > Several years ago, I started a project called 'oss-qm' which aimed to > collect maintenance branches for lots of packages, which solve the > common problems in a generic way (instead of all the dist specific > patches), so distros can base their branches on that. The problem then > wasn't systemd (which handn't been invented yet), but poor upstream QM. [...] > Anybody here interested in that ? being heavily based on git, it could be well compatible with Devuan's architecture. We'd certainly support the project. It could be interesting to make it first and foremost compatible with GUIX packaging, which is something we do want to support in the long term. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Announcing the git.devuan.org connection
On Fri, 14 Apr 2017, Enrico Weigelt, metux IT consult wrote: > On 07.03.2017 07:15, Ralph Ronnquist wrote: > > > The Issues forum (https://dev1galaxy.org/viewforum.php?id=19) holds > > threads that are automagically created by dev1galaxy's trusty "gdolink" > Could we bridge it to maillists ? > (maybe one list per forum) it would be perhaps easier to bridge it to https://bugs.devuan.org now up and running, working as the usual debbugs hence also via email. bugs.do is becoming our central point of collection for bugs (thanks Katolaz!). To be seen if gitlab issues will be useful on the long term ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 14-04-17 11:20, KatolaZ wrote: On Fri, Apr 14, 2017 at 10:57:01AM +0200, Enrico Weigelt, metux IT consult wrote: [cut] * srvmgt_daemonize() --> detach from controlling terminal, etc * srvmgt_droppriv(...) --> drop root privileges (if we are still root) --> several versions, eg. with fetching the target uid/gid from env * srvmgt_report_state(...) --> report the service state to the supervisor --> states could be eg. * SRVMGT_STATE_STARTUP -- still within the startup phase * SRVMGT_STATE_READY_LOCAL -- ready for local clients only * SRVMGT_STATE_READY_ALL -- ready for all clients * SRVMGT_STATE_BUSY-- too busy to process new requests * SRVMGT_STATE_SHUTDOWN-- shutting down, still finishing queued requests * SRVMGT_STATE_DEFERRED-- temporarily can't accept new requests (eg. overload) * SRVMGT_STATE_WAITING -- wait for resource (eg. printer needs paper or ink) * SRVMGT_STATE_OFFLINE -- completely offline (eg. due some fatal error) For start, we'd just write a small library, that logs to syslog, perhaps maintains some pidfiles (maybe even a *compile-time* option to route directly to libsystemd), then patch up packages that currently use libsystemd to use our new one. I personally don't see why one would like to redo libsystemd0 from scratch, as you seem so kee of doing. Go on down your path, but I suspect not many people would cheer at you in this camp... HND KatolaZ I am too do not see a reason to redo libsystemd0 but we can think about maintaining a Devuan version of libsystemd0. To ease the maintenance of packages depending on those basic api requests. We simply cannot trust the debian version but a Devuan version should be trustworthy. Grtz, Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On 14.04.2017 11:37, Jaromil wrote: > being heavily based on git, it could be well compatible with Devuan's > architecture. We'd certainly support the project. maybe you'd like to have a look at my github repos to get a better idea of my approach: https://github.com/oss-qm https://github.com/metux My intention was to use the 'oss-qm' organisation as a central hub. (i don't really care where it's hosted, it just should be easy to use for everybody) > It could be > interesting to make it first and foremost compatible with GUIX > packaging, which is something we do want to support in the long term. What is GUIX ? --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On Fri, 14 Apr 2017, Enrico Weigelt, metux IT consult wrote: > On 14.04.2017 11:37, Jaromil wrote: > > > being heavily based on git, it could be well compatible with Devuan's > > architecture. We'd certainly support the project. > > maybe you'd like to have a look at my github repos to get a better > idea of my approach: > > https://github.com/oss-qm > https://github.com/metux > > My intention was to use the 'oss-qm' organisation as a central hub. > (i don't really care where it's hosted, it just should be easy to > use for everybody) can't look deeper into it now, but well, we can consider it at least as a reference for people preparing and fixing packages. > > > It could be > > interesting to make it first and foremost compatible with GUIX > > packaging, which is something we do want to support in the long term. > > What is GUIX ? distro-agnostic packaging system done right (aka using a functional language) https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Enrico Weigelt: ... > Let's just take some example: libsrvmgt with funcs like that: > > * srvmgt_daemonize() > --> detach from controlling terminal, etc Why do any monitor program need to know if the program has detached or not, the only thing it needs to know is the pid and the state, which would/could be provided by the *_state() functions, or am I wrong ? > * srvmgt_droppriv(...) > --> drop root privileges (if we are still root) > --> several versions, eg. with fetching the target uid/gid from env Given the pid, it isn't that hard for a monitor to find the uid/gid of the process, why has this have to go through the monitor ? Also, given that you can do the above without this lib opens gives the program the option too cheat, say, if the monitor wishes to have a tight control of the process. A reliable (well, we have to trust the kernel) way to get the pid and uid of a sender is through signals, are there any other ways ? > * srvmgt_report_state(...) --> report the service state to the supervisor ... There could be something like *_a_would_like_to_be_monitored() and *_I_wish_to_regain_my_free_will(). > --> states could be eg. > * SRVMGT_STATE_STARTUP -- still within the startup phase > * SRVMGT_STATE_READY_LOCAL -- ready for local clients only > * SRVMGT_STATE_READY_ALL -- ready for all clients > * SRVMGT_STATE_BUSY-- too busy to process new requests > * SRVMGT_STATE_SHUTDOWN-- shutting down, still finishing > queued requests > * SRVMGT_STATE_DEFERRED-- temporarily can't accept new > requests (eg. overload) > * SRVMGT_STATE_WAITING -- wait for resource (eg. printer > needs paper or ink) > * SRVMGT_STATE_OFFLINE -- completely offline (eg. due some > fatal error) Given the choises given, it seems that the target of the monitor is network servers. Couldn't the monitor find out the ready_local, ready_all and shutdown by itself by monitoring which ports are open ? What's the difference between busy and deferred, seems to be the same thing. /// And, what if the monitor cannot trust the program it monitors ? Given the lib suggestion, it seems that we are trusting the program. But what if if we don't know if we can trust the walues provided by the program, the we have to check what the program is really doing, and then the lib have no value, isn't that so ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
KatolaZ wrote: >> For start, we'd just write a small library, that logs to syslog, >> perhaps maintains some pidfiles (maybe even a *compile-time* option >> to route directly to libsystemd), then patch up packages that currently >> use libsystemd to use our new one. >> > > I personally don't see why one would like to redo libsystemd0 from > scratch, as you seem so kee of doing. > > Go on down your path, but I suspect not many people would cheer at you > in this camp... I can see the merit - on two points, technical and political. On the technical side, I can see the usefulness of a system wide standardised service status reporting - making it easy for one process to see if a service it depends on is actually running and ready (as opposed to, "has started"). I have a customer system I've inherited where it regularly fails to startup properly because Asterisk starts before MySQL has finished starting up. For those of us who put consistency above boot speed, simply changing the init script so MySQL doesn't flag as "started" until the daemon is up and ready to accept requests would fix it; I can see how many would love to be able to have each init script just start and do a "wait for service X to be ready" step, so that init could just fire up all the scripts in parallel and they'd start as each dependency reached the available state. On the political side, when the Poetteristas say how horrible startup scripts are, and how they don't support parallel/dependency startup - there's be the response that "actually, you don't need all that furball of crap called SystemD because this simple, clean, minimally interlinked, API does it". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
k...@aspodata.se wrote: > Given the choises given, it seems that the target of the monitor is > network servers. Couldn't the monitor find out the ready_local, > ready_all and shutdown by itself by monitoring which ports are open ? ... > And, what if the monitor cannot trust the program it monitors ? > > Given the lib suggestion, it seems that we are trusting the program. > But what if if we don't know if we can trust the walues provided by > the program, the we have to check what the program is really doing, > and then the lib have no value, isn't that so ? Well there isn't really any easy way round the "don't trust my programs" problem. Your suggestion of monitoring open ports doesn't get round it - what if a program opens up port 80 but just "does nothing" with any connections it gets ? One way you see that "port 80 is open" and assume the service is up, the other way you get a notification that the service is up and assume that it's up. I really don't see how you can work around that at the supervisor level. Also, if you are going to detect a service as up just because it's opened one or more ports, that means the supervisor needs to know in detail what each program does. That goes against all good practice in terms of decoupling functions and leads to the systemd problem of massively interlinking stuff that doesn't need to be linked. Not to mention that there may well be services where a port (or socket) is opened before the service is actually ready to accept requests. So then you are into the supervisor having to know how to talk to each service so as to be able to make a request and see if it gets a sensible answer. But then I'm one of those generally happy with SysVInit style booting. It's easy to understand, it's generally reliable, it's fairly easy to debug if something isn't right. But I also recognise that others aren't happy and if they want to use something else then that's OK by me - as long as what they propose isn't something that "infects" stuff I want to run under SysVInit. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On 14.04.2017 12:05, Jaromil wrote: > can't look deeper into it now, but well, we can consider it at least > as a reference for people preparing and fixing packages. Can we aggree on some common naming scheme ? For now I'm just using / as prefix (which is used by my pbuilder-based packaging tool for detecting the target distro), but I'm open for discussion. The most important point for me is having the whole tree (with all patches and debian/ subdir applied) in one tree, so I never have to cope w/ extra patchqueues anymore. Perhaps we could also move the upstream's master to a different name and use that branch for as some starting point for per-package docs, eg. branch descriptions, etc, etc (maybe as md/textile-based wiki) >> What is GUIX ? > > distro-agnostic packaging system done right (aka using a functional > language) > https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html hmm, yet another package manager ? Why not just using docker+friends ? --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 14.04.2017 12:06, k...@aspodata.se wrote: > Enrico Weigelt: > ... >> Let's just take some example: libsrvmgt with funcs like that: >> >> * srvmgt_daemonize() >> --> detach from controlling terminal, etc > > Why do any monitor program need to know if the program has detached > or not, the only thing it needs to know is the pid and the state, > which would/could be provided by the *_state() functions, > or am I wrong ? That function should also do the daemonizing, so it doesn't need to do be implemented individually anymore. BTW: I'd add pidfile handling here, so it's just done once and for all. Reduces repeated code between individual packages and gives dists a central hook to do whatever tweaks they might wanna do. Might also come handy when somebody wants to have per-user services. >> * srvmgt_droppriv(...) >> --> drop root privileges (if we are still root) >> --> several versions, eg. with fetching the target uid/gid from env > > Given the pid, it isn't that hard for a monitor to find the uid/gid of > the process, why has this have to go through the monitor ? As above. It's not just notifying, it's doing that. If somebody wants an explicit notification for whatever reason (maybe just as simple as a syslog message), he can do it there, instead of within the individal application. >> --> states could be eg. >> * SRVMGT_STATE_STARTUP -- still within the startup phase >> * SRVMGT_STATE_READY_LOCAL -- ready for local clients only >> * SRVMGT_STATE_READY_ALL -- ready for all clients >> * SRVMGT_STATE_BUSY-- too busy to process new requests >> * SRVMGT_STATE_SHUTDOWN-- shutting down, still finishing >> queued requests >> * SRVMGT_STATE_DEFERRED-- temporarily can't accept new >> requests (eg. overload) >> * SRVMGT_STATE_WAITING -- wait for resource (eg. printer >> needs paper or ink) >> * SRVMGT_STATE_OFFLINE -- completely offline (eg. due some >> fatal error) > > Given the choises given, it seems that the target of the monitor is > network servers. Couldn't the monitor find out the ready_local, > ready_all and shutdown by itself by monitoring which ports are open ? That's not easy - the monitor would need a lot of application specific handling. For example sendmail doesn't close the inbound socket if it just cant accept new mails temporarily - instead it just tells that within the smtp handshake. My goal here is to have an simple notification for simple scenarios, where you don't have a full-blown network monitoring (eg. nagios). The whole thing could also be useful for per-user services that might not even be accessible from the outside. > What's the difference between busy and deferred, seems to be the same > thing. A little bit: busy means waiting for some external resource (eg. printer ran out of paper), while deferred is due some load limit (too high load, disk full, ...). Maybe we'd have to find better names. > And, what if the monitor cannot trust the program it monitors ? It's meant to be trusted (regarding security, etc) - it's just for easier notification, so that user/operator has at least an idea what's going on, and allows the monitor to defer startup of other depending services, etc. > But what if if we don't know if we can trust the walues provided by > the program, the we have to check what the program is really doing, > and then the lib have no value, isn't that so ? That would be scenarios where any kind of notification to the service monitor would be useless. My point is that there are indeed some scenarios where notification can be helpful, and that's only what that lib is for. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On Fri, 14 Apr 2017, Enrico Weigelt, metux IT consult wrote: > On 14.04.2017 12:05, Jaromil wrote: > > > distro-agnostic packaging system done right (aka using a functional > > language) > > https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html > > hmm, yet another package manager ? > > Why not just using docker+friends ? because people think different :^) apologies for my 'done right' btw, was teasing and yea I'm an opinionated lambdaboy :^) ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 14.04.2017 12:29, Simon Hobson wrote: > But I also recognise that others aren't happy and if they want to > use something else then that's OK by me - as long as what they > propose isn't something that "infects" stuff I want to run under > SysVInit. Exactly my goal. sysvinit users would probably just have the minimal version installed, that doesn't do more than a tiny bit syslog()'ing, others may install more complex versions fitting the service monitor of their choice. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 14.04.2017 12:17, Simon Hobson wrote: > For those of us who put consistency above boot speed, simply changing > the init script so MySQL doesn't flag as "started" until the daemon > is up and ready to accept requests would fix it; But then you'll have kind of daemon who watches mysql until it's really ready and then signals back to the service monitor, so it can proceed with the other services. In the long run, sounds like a maintenance hell to me. Having an simple status reporting, an application like mysql could at least tell "hey, I'm not ready yet - give a coffee break". Whether to actually use it, should be the decision of the operator (and distro should give a proper default) --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On 14.04.2017 13:16, Jaromil wrote: > because people think different :^) apologies for my 'done right' btw, > was teasing and yea I'm an opinionated lambdaboy :^) I haven't yet understood what the exact problem to solve, and how that actually supposed to work. CMIIW, but to me it looks pretty much like per-user installs. For that to work across distros (guess we're talking about binary packages), it would end up in having yet another distro in your $HOME. In that case we could just do something w/ docker and automatically mounting your home in there (a bit similar as schroot does) - IOW use docker for chroot setup and schroot for running applications. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] pbuilder w/ docker
Hi folks, anyone here already used pbuilder w/ docker ? (instead of, eg. cowbuilder) Or is there anything else that can do that ? --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Hi From my point of view, systemd always tries to keep services running, no matter how hard they fail, and to mask possible problems when starting a service, so the service maintainers don't have to fix their service, which is really unfortunate. In case of those service state notifications with sd_notify, I think they are usually used to signal when a service is starting, but not ready yet. This may seam reasonable at the beginning, but I think it fixes the problem at the wrong place; When a service needs another service, but it's temporary unavailable, it should cause an error or warning to be returned and logged, but it should never be a fatal error which causes the service to stop. When a service needs to handle this situation on it's own, it will become more stable over time. If this task is taken away from it, it will become fragile, and relay on the service manager. I think this would be really dangerous, because it could lead to cascades of failing services once one service fails. At some point, a service manager couldn't possibly handle that anymore and there would just be waves of restarting and failing processes. Daniel Abrecht signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Busybox Init: Was tiny service state api [WAS: Fwd: init system agnosticism]
On Fri, 14 Apr 2017 11:29:12 +0100 Simon Hobson wrote: > k...@aspodata.se wrote: > But then I'm one of those generally happy with SysVInit style > booting. It's easy to understand, it's generally reliable, it's > fairly easy to debug if something isn't right. But I also recognise > that others aren't happy and if they want to use something else then > that's OK by me - as long as what they propose isn't something that > "infects" stuff I want to run under SysVInit. Hi Simon, This is the perfect opportunity to explore this more. Karl is one of the tiny minority of people to have successfully booted using the Busybox Init. Hi Karl, How did you like the Busybox Init? Do you still use Busybox Init, or do you use a different init system for your day to day computing? I think you once made documentation for how you installed Busybox Init. If so, could you please post the URL to your documentation? SteveT Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]
On Fri, Apr 14, 2017 at 09:06:13AM +0200, Jaromil wrote: > dear Hendrik, > > On Wed, 12 Apr 2017, Hendrik Boom wrote: > > > Well, the official policy, insofar as there is one, appears to be that > [...] > > thanks for writing down such a clear statement on the matter, its You are very welcome! -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Keeping services running: was tiny service state api [WAS: Fwd: init system agnosticism]
On Fri, 14 Apr 2017 13:56:32 + Daniel Abrecht wrote: > Hi > > From my point of view, systemd always tries to keep services running, > no matter how hard they fail, and to mask possible problems when > starting a service, so the service maintainers don't have to fix > their service, which is really unfortunate. If you don't like that aspect of systemd, you're REALLY going to hate runit, which always restarts crashed/ended daemons. I think sysvinit or OpenRC would be more to your taste. That being said, runit has the option of using a ./finish script, which could report the malfunction and set a filesystem flag to prevent the service being run again. But that's kinda kludgy. By the way, I think systemd has the option of not rerunning. > > In case of those service state notifications with sd_notify, I think > they are usually used to signal when a service is starting, but not > ready yet. This may seam reasonable at the beginning, but I think it > fixes the problem at the wrong place; When a service needs another > service, but it's temporary unavailable, it should cause an error or > warning to be returned and logged, but it should never be a fatal > error which causes the service to stop. When process dependencies rear their heads, I write my runit run scripts something like the following, which tests for Internet connectivity before running the my_kewl_daemon service: #!/bin/sh if ping -c1 google.com > /dev/null; then exec my_kewl_daemon arg1 arg2 fi sleep 1 If the ping fails, instead of starting the daemon, it waits a second plus any time for runit's supervisor to cycle around, and then tries again. Looking at the preceding, it might seem that with everybody waiting a second to wait for everybody else, you might experience 5 minute gridlock startups. But in fact, for whatever reason, that doesn't happen. The beauty of the way I do it in runit is that I test the actual performance of the dependent daemon, rather than having either the init system or the daemon declare that the daemon is functional. SteveT Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Keeping services running: was tiny service state api [WAS: Fwd: init system agnosticism]
Steve Litt - 14.04.17, 12:07: > On Fri, 14 Apr 2017 13:56:32 + > > Daniel Abrecht wrote: > > Hi > > > > From my point of view, systemd always tries to keep services running, > > no matter how hard they fail, and to mask possible problems when > > starting a service, so the service maintainers don't have to fix > > their service, which is really unfortunate. > > If you don't like that aspect of systemd, you're REALLY going to hate > runit, which always restarts crashed/ended daemons. I think sysvinit or > OpenRC would be more to your taste. > > That being said, runit has the option of using a ./finish script, which > could report the malfunction and set a filesystem flag to prevent the > service being run again. But that's kinda kludgy. > > By the way, I think systemd has the option of not rerunning. systemd doesn´t restart services by default AFAIK. It does so when you add an option to do that to the service file, like in RHEL 7 for SSH daemon with an interval of 42 seconds. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Busybox Init: Was tiny service state api [WAS: Fwd: init system agnosticism]
Steve Litt: ... > This is the perfect opportunity to explore this more. Karl is one of > the tiny minority of people to have successfully booted using the > Busybox Init. Why do you make it sound like it is difficult, it isn't something that you need any advanced skill to solve. It's just that you have to do it yourself, the installer won't do it for you. > How did you like the Busybox Init? I'm perfectly fine with it, it's just like the bsd startup scripts in the 80-ties. There is some issues I havn't bothered solve, /sbin/shutdown doesn't work as is, I have to use busybox poweroff in a root terminal. > Do you still use Busybox > Init, or do you use a different init system for your day to day > computing? On some boxes I use bb init, on some other there is sysv. > I think you once made documentation for how you installed > Busybox Init. If so, could you please post the URL to your > documentation? http://aspodata.se/computing/busybox_init.txt Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
Enrico Weigelt: > On 14.04.2017 12:06, k...@aspodata.se wrote: > > Enrico Weigelt: > > ... > >> Let's just take some example: libsrvmgt with funcs like that: > >> > >> * srvmgt_daemonize() > >> --> detach from controlling terminal, etc > > > > Why do any monitor program need to know if the program has detached > > or not, the only thing it needs to know is the pid and the state, > > which would/could be provided by the *_state() functions, > > or am I wrong ? > > That function should also do the daemonizing, so it doesn't need to do > be implemented individually anymore. What you are requesting is that developers should learn a new api for the same end as the old, I won't support that. What is wrong with daemon(3) ? > BTW: I'd add pidfile handling here, so it's just done once and for all. > Reduces repeated code between individual packages and gives dists a > central hook to do whatever tweaks they might wanna do. Might also come > handy when somebody wants to have per-user services. I'd say that the individual program has no need nor any interest of any pid file, it will be running just as fine without it. A pid file is only in the interest of a monitoring program, so why not let the monitor create it for it's own use, why clutter all idividual programs with it. And, you didn't answer the question, is there anything besides the pid and the state that a monitoring program needs to know ? > >> * srvmgt_droppriv(...) > >> --> drop root privileges (if we are still root) > >> --> several versions, eg. with fetching the target uid/gid from env > > > > Given the pid, it isn't that hard for a monitor to find the uid/gid of > > the process, why has this have to go through the monitor ? > > As above. It's not just notifying, it's doing that. If somebody wants > an explicit notification for whatever reason (maybe just as simple as > a syslog message), he can do it there, instead of within the > individal application. If you "do it there", you are actually doing it within the individual program, and if you are so fond of replacing standard libc calls, why don't you go the fakeroot route: fakeroot works by replacing the file manipulation library functions (chmod(2), stat(2) etc.) by ones that simulate the effect the real library functions would have had, had the user really been root. These wrapper functions are in a shared library /usr/lib/libfakeroot.so* which is loaded through the LD_PRELOAD mechanism of the dynamic loader. (See ld.so(8)) Then you won't need to change any program, your monitor just provides a libc wrapper containing the wrappers for whatever functions it fancy monitoring. Why do I have to modify "my" source code just to please a monitor ? ... > > Given the choises given, it seems that the target of the monitor is > > network servers. Couldn't the monitor find out the ready_local, > > ready_all and shutdown by itself by monitoring which ports are open ? > > That's not easy - the monitor would need a lot of application specific > handling. For example sendmail doesn't close the inbound socket if it > just cant accept new mails temporarily - instead it just tells that > within the smtp handshake. Well there you have your service notification, it is already implemented. Why don't you use it ? And if you really care about the mail server, you look in its logs. And, in parenting a child, you always need to know something about the child. > My goal here is to have an simple notification for simple scenarios, > where you don't have a full-blown network monitoring (eg. nagios). > The whole thing could also be useful for per-user services that might > not even be accessible from the outside. So what are thoose scenarios, if you really want monitoring you could use simple setups of mon or nagios. At the other end is: just start the program, if it dies, you investigate and complain to upstream. > > What's the difference between busy and deferred, seems to be the same > > thing. > > A little bit: busy means waiting for some external resource (eg. > printer ran out of paper), while deferred is due some load limit > (too high load, disk full, ...). Maybe we'd have to find better names. > > > And, what if the monitor cannot trust the program it monitors ? > > It's meant to be trusted (regarding security, etc) - it's just for > easier notification, so that user/operator has at least an idea what's > going on, and allows the monitor to defer startup of other depending > services, etc. So, this is only about staggered startup at root ? Why don't other programs just sleep() and retry till the problem is gone. You have the same problem if your db is on one box, you dns server is on another, etc. Or do you propose that the monitor should run multihost ? > > But what if if we don't know if we can trust the walues provided by > > the program, the we have to check what the program is really doing, > > and then the lib have no value, isn't that so ? > > That would be sc
Re: [DNG] [cairo] cairo packaging and Makefile.am.features
On 14.04.2017 18:33, Uli Schlachter wrote: > configure already generates this. No idea what "complaining", "extra > preparations", nor "special commands" you mean. (Well, ok, perhaps the > empty files: This just Yeah, that was the missing point. turned out that just creating them in the corresponding hook rule was trivial. Not nice, but i can live with that. > So it seems that this needs configure to run. As a side effect this > generates the proper files. Then you need to run automake again so that > the proper Makefile.in is created. Which means you need to run configure > again... Uuuh, i didn't expect that. Could it be that it's magically doing that on its own ? I wonder, because I successfully built it via pbuilder/debuild (but not tested) yet - with my drm queue applied - and the new symbols appeared. If it wouldn't work in one pass, then at least the backends should be missing (if it compiles at all). >> Therefore, these files *really* should always be autogenerated and >> strictly kept out of the src tree / tarball. > > They are autogenerated. "make dist" adds it to tarballs since the file > is included by something. I dont think the tarball should contain any autogenerated stuff. That brings the risk that not everything's regenerated, if some patches applied (especially ugly for distros/packaging). Fortunately it's not in the git repo (otherwise git-buildpackage would break). --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] new cairo w/ drm patches
Hi folks, I've just packaged recent cairo w/ my drm patchqueue applied. For now just on Trusty (as my workstation's still running it), but fixing up for devuan should be trivial. https://github.com/metux/cairo/tree/trusty/master -- mit freundlichen Grüßen -- Enrico, Sohn von Wilfried, a.d.F. Weigelt, metux IT consulting +49-151-27565287 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] grub background image
Am 2017-04-10 00:39, schrieb fsmithred: desktop-base is supposed to handle that, but it's not cooperating. You can bypass it by adding the following (one) line to /etc/default/grub GRUB_THEME=/usr/share/desktop-base/grub-themes/desktop-grub-them/theme.txt Thank you for that hint. The correct entry is: GRUB_THEME=/usr/share/desktop-base/grub-themes/devuan/theme.txt This is a very nice grub theme. I'm wondering why this is not set in the default installation? Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] grub background image
On 2017-04-14 19:27, Joachim Fahrner wrote: > Am 2017-04-10 00:39, schrieb fsmithred: > >> desktop-base is supposed to handle that, but it's not cooperating. >> You can >> bypass it by adding the following (one) line to /etc/default/grub >> >> GRUB_THEME=/usr/share/desktop-base/grub-themes/desktop-grub-them/theme.txt >> > > Thank you for that hint. > The correct entry is: > GRUB_THEME=/usr/share/desktop-base/grub-themes/devuan/theme.txt > > This is a very nice grub theme. I'm wondering why this is not set in > the default installation? > > Jochen I don't have that file. Which package contains it? Daniel Abrecht signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
"Enrico Weigelt, metux IT consult" wrote: >> For those of us who put consistency above boot speed, simply changing >> the init script so MySQL doesn't flag as "started" until the daemon >> is up and ready to accept requests would fix it; > > But then you'll have kind of daemon who watches mysql until it's really > ready and then signals back to the service monitor, so it can proceed > with the other services. In the long run, sounds like a maintenance > hell to me. Which is why I said I can see some value in a simple communication/notification system. Ideally you'd have MySQL itself make status calls along the lines of "I'm starting but not ready" and hopefully end with "I'm now ready for business". The latter would then allow other processes that depend on a working database to continue. At present, IIRC the script starts the MySQL process, then loops round waiting for to appear - at which point it assumes MySQL is ready for action and prints OK on the console. That way, there's a standard way for processes to communicate their status, and a simple and standard way for dependent processes to determine if something they need is ready yet. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We need to speak up
On 2017-04-14 05:44, Enrico Weigelt, metux IT consult wrote: On 14.04.2017 12:05, Jaromil wrote: can't look deeper into it now, but well, we can consider it at least as a reference for people preparing and fixing packages. Can we aggree on some common naming scheme ? Perhaps these pages will help to clarify Devuan's naming scheme and packaging protocol: https://devuan.org/os/filenaming and https://dev1galaxy.org/viewtopic.php?id=549 golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 2017-04-14 20:16, Simon Hobson wrote: > "Enrico Weigelt, metux IT consult" wrote: > >>> For those of us who put consistency above boot speed, simply changing >>> the init script so MySQL doesn't flag as "started" until the daemon >>> is up and ready to accept requests would fix it; >> But then you'll have kind of daemon who watches mysql until it's really >> ready and then signals back to the service monitor, so it can proceed >> with the other services. In the long run, sounds like a maintenance >> hell to me. > Which is why I said I can see some value in a simple > communication/notification system. Ideally you'd have MySQL itself make > status calls along the lines of "I'm starting but not ready" and hopefully > end with "I'm now ready for business". The latter would then allow other > processes that depend on a working database to continue. > At present, IIRC the script starts the MySQL process, then loops round > waiting for to appear - at which point it assumes MySQL is ready > for action and prints OK on the console. > > > That way, there's a standard way for processes to communicate their status, > and a simple and standard way for dependent processes to determine if > something they need is ready yet. I still think this isn't a problem the service manager should attempt to solve. This is a situation where the database is temporary unavailable, for which there are many possible reasons. The services which relay on the database should be able to handle such a situation gracefully, or they are just not yet stable enough. I would expect a service which has to handle a task for which it needs the database to return an error in this situation, but to continue working. Once the database is available, and a new task arrives which requires the database, the service should work as expected. If such a service needs to do some initialization using the database, it can just re-queue that until the first successful database connection. This way, there isn't even a need to start the database first, the service would be rock solid, and there wouldn't be any need for the service manager to handling such edge cases. Just keep it simple. signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] grub background image
On 2017-04-14 14:36, Daniel Abrecht wrote: On 2017-04-14 19:27, Joachim Fahrner wrote: Am 2017-04-10 00:39, schrieb fsmithred: desktop-base is supposed to handle that, but it's not cooperating. You can bypass it by adding the following (one) line to /etc/default/grub GRUB_THEME=/usr/share/desktop-base/grub-themes/desktop-grub-them/theme.txt Thank you for that hint. The correct entry is: GRUB_THEME=/usr/share/desktop-base/grub-themes/devuan/theme.txt This is a very nice grub theme. I'm wondering why this is not set in the default installation? Jochen I don't have that file. Which package contains it? Daniel Abrecht It's in desktop-base. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On Fri, 14 Apr 2017 21:16:18 +0100 Simon Hobson wrote: > "Enrico Weigelt, metux IT consult" wrote: > > >> For those of us who put consistency above boot speed, simply > >> changing the init script so MySQL doesn't flag as "started" until > >> the daemon is up and ready to accept requests would fix it; > > > > But then you'll have kind of daemon who watches mysql until it's > > really ready and then signals back to the service monitor, so it > > can proceed with the other services. In the long run, sounds like a > > maintenance hell to me. > > Which is why I said I can see some value in a simple > communication/notification system. Ideally you'd have MySQL itself > make status calls along the lines of "I'm starting but not ready" and > hopefully end with "I'm now ready for business". Sounds like a good idea, but it's not, for the following reasons: 1) There will be endless arguments about HOW each and every daemon will let its init system know "I'm now ready for business". The number of different ways will make the number of incompatible Unixes of 1985 seem trivial to reconcile. 1.5) The resource daemon's opinion of being "ready for business" might be erroneous, or not reflect how the user daemon will use the resource daemon. 2) The connected and powerful will unilaterally declare one method of "phoning home" is the one true way, thereby driving compatability wedges between various software, and facilitating the defacto banning of some daemons from a distro. 3) If the "one true way" is complex, for instance, if it has to intimately mesh with dbus (sy what?), small daemon projects will be ostricized out of the community. 4) The problem this backward communication purports to solve was solved around the time the Western Roman Empire was conquored by the Barbarians. Regardless of your init system, run your daemons from daemontools, and have your daemontools run scripts refuse to start unless a test of the needed resource indicates it's working. Whatever init system you're using, it's easy to get Daemontools, or preferably Daemontools-Encore, running.[1] A word about the source of this thread: A guy, whom I /dev/nulled over a year ago for making very disturbing political posts in response to technical discussions, magically woke up a few days ago and started resurrecting all sorts of dead threads. My /dev/null log tells me he's sent 20 or 30 emails. I don't begin to know what causes this person to act this way, but he's not a friend of our community, and we might want to think twice about responding to him, even in the few cases where he has a good idea. [1] To run daemontools-encore, download the lastest tarball, untar it, modify its conf-* files to reflect correct directories and compile commands (usually unnecessary if you're using gcc on Linux), make, become root, make install, make the repository for daemontools daemons (I used /etc/daemontools/service), make the symlink directory (I used /var/daemontools/service), then edit the svscanboot file to reflect the actual directories that are being used, run svscanboot, and then make run files under the repository and symlink them to the symlink directory to install daemons. This way, no matter what init system you're using, you have a complete supervisor for daemons you believe need to be supervised. And pay no attention to the guy on Debian-User who tells you not to use the svscanboot file to instantiate your daemontools system.[2] [2] Recently a guy posted on Debian-User that you shouldn't use the svscanboot shellscript to start up daemontools. He states a few edge-case situations where svscanboot has bugs, most of which have nothing to do with Linux or normal Intel/AMD hardware. He links to a few people who have run daemontools by doing various init-foo instead of just spawning svscanboot. He just loves to hear himself hold forth on all things technical, but what he forgets to tell his audience is: 1) svscanboot is by far the simplest way to run daemontools. 2) djb created svscanboot, and although this guy holding forth is very smart (IMHO in a Poettering sort of way), if you're going to criticize djb on technical grounds, your name had better be Einstein or Hawking. 3) Differently named copies of svscanboot, each with its own directories, can implement some degree of startup order in daemontools, even though daemontools is widely regarded as having indeterminate start order. 4) If one were to run into one of those edge cases where a daemontools system has bugs if started with svscanboot, they might be fixable by changing the svscanboot shellscript, and that would be infinitely preferable than all sorts of init-foo. SteveT Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Techno
[DNG] /etc/debian_version
Hi all. So I noticed that on systems upgraded to devuan jessie from debian wheezy, I still have a /etc/debian_version. I don't have this file on a couple devuan systems installed from scratch. I figured I didn't need a /etc/debian_version reading 7.1.1 anymore, so I blew it away on one of my upgraded systems. Nothing exploded when I did this, except that when I do upgrades, I am seeing the message: cat: /etc/debian_version: no such file or directory. I can probably put that file back, and all would be good. However, my question is what is still looking for that file during apt-get dist-upgrade, and more to the point, how can I make this message during upgrades stop without bringing back /etc/debian_version? Thanks in advance for any input. Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
> > Go on down your path, but I suspect not many people would cheer at you > > in this camp... > > I can see the merit - on two points, technical and political. > > > On the technical side, I can see the usefulness of a system > wide standardised service status reporting - making it easy > for one process to see if a service it depends on is actually > running and ready (as opposed to, "has started"). I have a > customer system I've inherited where it regularly fails to > startup properly because Asterisk starts before MySQL has > finished starting up. So it turns out that there exists an subtle yet elegant mechanism for a process to report that it is ready. It has been in use for decades - daemons as old as sysklog from the previous century use it. I have written up the details at http://welz.org.za/notes/on-starting-daemons.html The TLDR is that "A good daemon should fork soon, but have the parent process exit only once the child is ready to service requests" Sadly it seems too subtle for many people and the concept goes un-noticed ... regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
