Re: [Dng] Readiness notification
Le 13/06/2015 01:15, Laurent Bercot a écrit : Encouraging daemon writers to use another API and providing a wrapper to make daemons using the simpler API work with the sd_notify mechanism is clearly the better ideological solution, and also technologically preferable because more compatible with other notification frameworks; but it's harder, because it requires communication with daemon authors, and the systemd proponents have more communication power than we do (read: $$$). But I think authors can be convinced if we show that our API is simpler to use and will work under any framework, systemd included. Yes, daemon writers are good-willing developpers; they want their software to serve as many users as possible; and users install distros. This gives power to the distros. But if someone provides them with a KISS readyness-signaling method, along with a systemd wrapper, then they can satisfy RedHat's requests at no cost. The question now is who will develop, maintain and package this wrapper? Will Devuan be the official developper of "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who else to take the job? Or are the daemon's developper powerfull enough to tell RH "do it yourself."? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] task-xfce-desktop, task-mate-desktop task-lxde-desktop proposed changes.
Hi, I'm currently looking at patching the desktop tasks in taskselect to use slim instead of lightdm (atleast until lightdm has been cleaned up to not depend on systemd). Also I'm planning to replace gnome-network-manager in those tasks with wicd. These changes bring us closer to our goal of not needing to install any systemd dependencies. (There still are packages like cups and lxsession that need to have the tie-ins to systemd excised. Also, these changes only effect from scratch installation of Devuan, where tasksel is used. Installing the removed packages manually will work just fine. Regards, Daniel. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
Le 13/06/2015 01:53, Laurent Bercot a écrit : On 12/06/2015 22:21, marc...@welz.org.za wrote: The trick is for the daemon process to only background when it is ready to service requests (ie its parent process exits when the child is ready). You already mentioned it in a reply to me, indeed. I intentionally did not follow up, and here is why. This is bad design, for several reasons. It's actually worse design than sd_notify(), and I'd rather have every daemon use sd_notify() and write a sd_notify server myself than recommend your solution. The reasons why it's bad are mostly described here: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html Your solution enforces forking, i.e. auto-backgrounding, and prevents logging to stderr; in doing so, it prevents daemons from ever being used with a supervision framework. systemd may be able to supervise it, using cgroups, but that's about it, unless the admin is using foreground hacks. Moreover, the method you are using to transmit one bit of information, i.e. readiness of the service, is *the death of a process*. This is pretty heavy on the system; a simple write() does the job just as well, and hundreds of times faster. If auto-backgrounding was an absolute necessity, then sure, the parent would need to die anyway, and you could time its death so it transmits readiness. Why not. But auto-backgrounding is not good design in the first place; it comes from ancient Unix times when we did not know better, and the daemon() function should either disappear into oblivion, or have a place in the museum of medieval programming as an example of how not to write Unix software. Thanks Laurent, I hope you explain it better than me. The point was already discussed on this list. It will take time before people are convinced because I think a lot of tutorials around still present auto-daemonization as the way to go. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On Fri, 12 Jun 2015 22:21:06 +0200 marc...@welz.org.za wrote: > The trick is for the daemon process to only background when > it is ready to service requests (ie its parent process exits > when the child is ready). For those of us who use daemontools-inspired process managers or inits, the preceding does not work. We need our daemons to be able to run in the foreground. Just because today Devuan uses sysvinit doesn't mean that will always be true. One day, for all we know, Devuan will use runit or S6. And if that day comes, we will rue the day when the decision was made to have daemons be like dhclient and signal readiness by backgrounding at that particular time. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 12/06/2015 22:21, marc...@welz.org.za wrote: The trick is for the daemon process to only background when it is ready to service requests (ie its parent process exits when the child is ready). You already mentioned it in a reply to me, indeed. I intentionally did not follow up, and here is why. This is bad design, for several reasons. It's actually worse design than sd_notify(), and I'd rather have every daemon use sd_notify() and write a sd_notify server myself than recommend your solution. The reasons why it's bad are mostly described here: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html Your solution enforces forking, i.e. auto-backgrounding, and prevents logging to stderr; in doing so, it prevents daemons from ever being used with a supervision framework. systemd may be able to supervise it, using cgroups, but that's about it, unless the admin is using foreground hacks. Moreover, the method you are using to transmit one bit of information, i.e. readiness of the service, is *the death of a process*. This is pretty heavy on the system; a simple write() does the job just as well, and hundreds of times faster. If auto-backgrounding was an absolute necessity, then sure, the parent would need to die anyway, and you could time its death so it transmits readiness. Why not. But auto-backgrounding is not good design in the first place; it comes from ancient Unix times when we did not know better, and the daemon() function should either disappear into oblivion, or have a place in the museum of medieval programming as an example of how not to write Unix software. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 12/06/2015 20:09, Tomasz Torcz wrote:
Hey, it's almost exactly what sd_notify() does. Instead of one character,
it writes "READY=1" to a socket. Nothing more, no D-Bus, no additional
libraries needed. In basic form it few lines of C code.
Of course
https://github.com/systemd/systemd/blob/0e4061c4d5de6b41326740ee8f8f13c168eea28d/src/libsystemd-daemon/sd-daemon.c#L414
looks much worse, but it packs more functionality than simply
readiness signalling.
Which is exactly the problem: it packs more functionality.
More functionality, that can be added to at a developer's whim, is
something that a stub has to support - if only to not crash on
functionality it doesn't understand.
More functionality means that daemon authors will rely on it, and
use the readiness notification mechanism for things entirely unrelated.
More functionality means feature creep that you will have to follow
to remain compatible.
It's easy to write a notification server that listens to connections
from sd_notify() and does things when it reads READY=1. It's not so
easy to implement all the sd_notify protocol, even right now, and with
all the random stuff that will inevitably get added over the years,
when daemons start relying on it.
Instead of those 68 lines of code, I suggest the following:
void notify_readiness (void)
{
write(1, "\n", 1) ;
close(1) ;
}
You really don't need anything more.
--
Laurent
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 12/06/2015 19:46, Steve Litt wrote: I agree with every single thing you write above, but have one question for you: What does Devuan do when daemons like cupsd and sshd make sd_notify calls, and these don't condition the call on sd_notify being available, and sd_notify cannot be conditionally recompiled out of the program? Is Devuan going to rewrite every single daemon? Short answer: yes. That's exactly the point of a distribution, as Katola says. A bit longer answer: it doesn't even have to be hard. You don't have to rewrite anything - just patch; it shouldn't be too difficult to edit out the parts calling sd_notify. Even better, suggest alternative software that you don't have to patch. cupsd and sshd have been infected by systemd? Well, maybe you should inform the users, and provide similar functionality in a systemd-free way. Isn't that the goal of Devuan? sshd servers are not lacking. As for printing servers, I don't know, but I'd be surprised if cupsd was the only possibility. And if it actually is the only possibility, then we have a bigger problem than just sd_notify: it means that monopolies exist in free software - real, existing monopolies, albeit more inconspicuous than systemd's obvious attempts at a monopoly - and it is taking away from users' freedom. And that is what needs to be fought first and foremost. I firmly believe that in 20ish years, we have lost most of the awareness of what free software is and what it means. If we cannot actually dive into the code and take out what we don't want, then it's de facto not free software anymore, no matter the reason. systemd is proprietary software despite its licensing because it's too complex to be tinkered with at an individual level, it's controlled by a company, and it uses embrace and extend methods to establish market domination. But I don't think sshd and cupsd are there yet - they can still be worked with. Same with most daemons that have already succumbed to the sirens of sd_notify. And I certainly hope that those are few and far between. By the way, if there *were* a stub sd_notify, I'd have nothing against it doing nothing but passing the info to S6-notifywhenup or something like it. The issue is complex because it's both technical and ideological. Stubbing the sd_notify client, i.e. writing a library that daemons can link against, is easier because it doesn't depend on anyone else than the person writing it - but it is ideologically worse because it gives ground to systemd, and does nothing to incentivize daemon writers to stop usingthe sd_notify API. Encouraging daemon writers to use another API and providing a wrapper to make daemons using the simpler API work with the sd_notify mechanism is clearly the better ideological solution, and also technologically preferable because more compatible with other notification frameworks; but it's harder, because it requires communication with daemon authors, and the systemd proponents have more communication power than we do (read: $$$). But I think authors can be convinced if we show that our API is simpler to use and will work under any framework, systemd included. If there were a stub sd_notify, I'd rather have it output the info in the simplest possible format so that it can then be used by *any* notification reader, and so that it's actually easier for a daemon author to output the notification directly than to call sd_notify(). I'm a bit uncomfortable treading these grounds, because it's technical talk that ultimately has a political goal, and I don't like to mix the two, but when stubbing is involved it's unfortunately unavoidable. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
On Fri, 12 Jun 2015 17:15:25 -0400, Fsmithred wrote: > On 06/12/2015 10:45 AM, Irrwahn wrote: >> FWIW, I've got three Devuan installations running: jessie VM, ascii VM, >> ascii on real hardware. In all of them I was able to get everything >> (including shutdown et. al) working without systemd, except libsystemd0 >> is ATM still needed for gvfs, pulse, cups, sane, syslog - until those >> packages are disinfected as well. > > HOW??? I've only been able to do that by pulling in packages from the > angband repo (or by renaming the above named file). Are you running xfce > and lightdm? Oh yeah, I did it a third way - give user sudo privs with > nopasswd for shutdown and reboot. Yes, all setups are running xfce4, one with slim, the other two with lightdm. I actually planned to do another install using the alpha2 installer, logging all the necessary steps and write up a walk-through. Alas, I couldn't find the time yet, hopefully I'll get it done this weekend. In the meantime, just in case you might be interested in using it for reference, at http://www.pastebin.ca/3025993 you can find the output of dpgk --list, produced on one up-to-date, frugal (has no cups, pulse, sane, but has gvfs) Devuan jessie install. HTH, Cheers Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
On 06/12/2015 10:45 AM, Irrwahn wrote: > When there's a /lib/systemd/systemd-logind, then not all the systemd > packages were purged properly. :-) Anyway, IIRC dimkr is already working > on a fix for the logind/consolekit clash. Yeah, I know. That file was gone after I removed the systemd packages, and it returned when I reinstalled them. I'm going to repeat the installation and make before and after package lists, to see if I can figure out why the login buttons don't work after reinstalling the systemd packages. I can at least rule out the possibility that some important package didn't get reinstalled. > > FWIW, I've got three Devuan installations running: jessie VM, ascii VM, > ascii on real hardware. In all of them I was able to get everything > (including shutdown et. al) working without systemd, except libsystemd0 > is ATM still needed for gvfs, pulse, cups, sane, syslog - until those > packages are disinfected as well. HOW??? I've only been able to do that by pulling in packages from the angband repo (or by renaming the above named file). Are you running xfce and lightdm? Oh yeah, I did it a third way - give user sudo privs with nopasswd for shutdown and reboot. fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A nice candidate substitute to network-manager
On 12/06/15 22:15, Anto wrote: On 12/06/15 18:34, Marlon Nunes wrote: On 2015-06-12 10:03, Steve Litt wrote: On Fri, 12 Jun 2015 07:50:25 -0300 Marlon Nunes wrote: Hi, i've been testing connman for a while and found it to handle very well my network connections. https://01.org/connman The following sentence from the preceding link made me sweat a little bit: = ConnMan is optimized through open source for embedded and client focused Intel® Quark technology, Intel® Atom™ processors and Intel® Core™ processors. = I'm an AMD guy. I found it ok just for the fact that its completely independent of systemd. https://wiki.archlinux.org/index.php/Connman Those Arch guys are the biggest bunch of systemd jingoists on the planet but you've got to admit, they write far and away the best documentation on the planet. Their wiki help pages are almost complete. In my view, we can forget about network-manager completely for desktop usage. Whether we stay with Wicd, which Devuan Alpha 2 does such a great job with, or switch to ConnMan, either way, you're right: network-manager is too entangled in dbus and systemd to be useful on Devuan, and it also requires you be in X, and that's not always true. I think that whether Wicd or ConnMan is our default network "make it easier machine", it should be easy to switch between the two, and part of that ease could be good documentation. By the way, I was going to answer Bardot Jérôme's query about Devuan Network-Manager similarly: Better to be rid of Network-Manager than to wonder if it's going to drag in systemd on an update. Network-Manager's wonderful for the one use case Debian envisions, but turns into a stumbling block when you go offroad. That's why a wrote about it. =) I doubt that connman is free of systemd. I was just in the middle of preparing to compile connman 1.29, and I saw 2 files which are definitely meant for systemd. And they are in http://git.kernel.org. http://git.kernel.org/cgit/network/connman/connman.git/tree/src/connman.service.in [Unit] Description=Connection service Requires=dbus.socket After=dbus.socket Before=remote-fs-pre.target Wants=remote-fs-pre.target [Service] Type=dbus BusName=net.connman Restart=on-failure ExecStart=@sbindir@/connmand -n StandardOutput=null [Install] WantedBy=multi-user.target http://git.kernel.org/cgit/network/connman/connman.git/plain/vpn/connman-vpn.service.in [Unit] Description=ConnMan VPN service Requires=dbus.socket After=dbus.socket [Service] Type=dbus BusName=net.connman.vpn ExecStart=@sbindir@/connman-vpnd -n StandardOutput=null [Install] WantedBy=multi-user.target I know that they are harmless. But that tells me the intention to allow it to be locked-in into systemd. So I always want to remove everything related to systemd including the unit, service and socket files. I got the impression that a lot of people find my attempt to do that ridiculous. But I really don't care :) I just purged all connman files that I downloaded tonight. I think t is not worth trying to compile and install it. The title of the commit below clearly says that connman is definitely being locked-in to systemd. machine: Integrate ConnMan with systemd-hostnamed http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=d5acb39e80b40d2b21eed37506523e73fcd8956f ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
> For months, literally, the supervision list > has been wringing its hands over the very real problem that, for process > dependency purposes, one must know that process X is not only running, > but ready to handle its business. Knowing process X is running isn't > sufficent, because some processes take a long time between running > and being ready for business. At the risk of sounding like a broken record, this problem has been known for decades, and has been solved for decades (eg, see the sysklogd sources). The trick is for the daemon process to only background when it is ready to service requests (ie its parent process exits when the child is ready). And I am pretty sure I did (apologies for the repeated spam) mention my writeup at welz.org.za/notes/on-starting-daemons.html on this very list. It even contains a bit of sample code to reduce things to a single function call, and later a close() to stderr Actually, looking at the devuan archives, I actually mentioned it in a reply to you - not sure if this is sad or funny. regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A nice candidate substitute to network-manager
On 12/06/15 18:34, Marlon Nunes wrote: On 2015-06-12 10:03, Steve Litt wrote: On Fri, 12 Jun 2015 07:50:25 -0300 Marlon Nunes wrote: Hi, i've been testing connman for a while and found it to handle very well my network connections. https://01.org/connman The following sentence from the preceding link made me sweat a little bit: = ConnMan is optimized through open source for embedded and client focused Intel® Quark technology, Intel® Atom™ processors and Intel® Core™ processors. = I'm an AMD guy. I found it ok just for the fact that its completely independent of systemd. https://wiki.archlinux.org/index.php/Connman Those Arch guys are the biggest bunch of systemd jingoists on the planet but you've got to admit, they write far and away the best documentation on the planet. Their wiki help pages are almost complete. In my view, we can forget about network-manager completely for desktop usage. Whether we stay with Wicd, which Devuan Alpha 2 does such a great job with, or switch to ConnMan, either way, you're right: network-manager is too entangled in dbus and systemd to be useful on Devuan, and it also requires you be in X, and that's not always true. I think that whether Wicd or ConnMan is our default network "make it easier machine", it should be easy to switch between the two, and part of that ease could be good documentation. By the way, I was going to answer Bardot Jérôme's query about Devuan Network-Manager similarly: Better to be rid of Network-Manager than to wonder if it's going to drag in systemd on an update. Network-Manager's wonderful for the one use case Debian envisions, but turns into a stumbling block when you go offroad. That's why a wrote about it. =) I doubt that connman is free of systemd. I was just in the middle of preparing to compile connman 1.29, and I saw 2 files which are definitely meant for systemd. And they are in http://git.kernel.org. http://git.kernel.org/cgit/network/connman/connman.git/tree/src/connman.service.in [Unit] Description=Connection service Requires=dbus.socket After=dbus.socket Before=remote-fs-pre.target Wants=remote-fs-pre.target [Service] Type=dbus BusName=net.connman Restart=on-failure ExecStart=@sbindir@/connmand -n StandardOutput=null [Install] WantedBy=multi-user.target http://git.kernel.org/cgit/network/connman/connman.git/plain/vpn/connman-vpn.service.in [Unit] Description=ConnMan VPN service Requires=dbus.socket After=dbus.socket [Service] Type=dbus BusName=net.connman.vpn ExecStart=@sbindir@/connman-vpnd -n StandardOutput=null [Install] WantedBy=multi-user.target I know that they are harmless. But that tells me the intention to allow it to be locked-in into systemd. So I always want to remove everything related to systemd including the unit, service and socket files. I got the impression that a lot of people find my attempt to do that ridiculous. But I really don't care :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification (was: One issue with ongoing depoetterization)
On Fri, Jun 12, 2015 at 07:37:21PM +0200, Laurent Bercot wrote: > Please don't do this. > The more you bend to the systemd interfaces, the more it gets a foot > in the door. By implementing a dummy sd_notify, you acknowledge the > validity of the interface; you accept that the systemd people have > created something worth using, and you validate the existence of > (a part of) systemd. If systemd has some good parts but systemd is bad cause it has a lot of other bad parts, and even the good parts are bad implemented, i don't see why we can't get only the good parts and reimplement them in a better way. For example, in this specific sd_notify, i can see a good thing to have a little "do only one thing" little daemon+library that implement the sd_notify call and the open compile an ascii text pseudofile somewhere in /sys with a list of "ready to use" daemons, and maybe also a unix socket where other daemons, a script, an init can connect to to have real time notifications of daemon getting ready. This way we have a great feature, one of the few good features of systemd, but implemented in a unix, kiss and indipendent (and good) way. So, why not? -- Franco (nextime) Lanza Lonate Pozzolo (VA) - Italy SIP://c...@casa.nexlab.it web: http://www.nexlab.net NO TCPA: http://www.no1984.org you can download my public key at: http://danex.nexlab.it/nextime.asc || Key Servers Key ID = D6132D50 Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50 --- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc --- signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification (was: One issue with ongoing depoetterization)
On Fri, Jun 12, 2015 at 07:37:21PM +0200, Laurent Bercot wrote: > On 12/06/2015 19:01, Steve Litt wrote: > >The one thing I *do* know is that we need to provide a sd_notify > >interface, even if it does nothing at all and drops passed information > >on the floor. > > > There's a much simpler mechanism that can be used to provide > readiness notification, and that I suggest in >http://skarnet.org/software/s6/notifywhenup.html > and that is: write a given character on a descriptor, then close that > descriptor. Hey, it's almost exactly what sd_notify() does. Instead of one character, it writes "READY=1" to a socket. Nothing more, no D-Bus, no additional libraries needed. In basic form it few lines of C code. Of course https://github.com/systemd/systemd/blob/0e4061c4d5de6b41326740ee8f8f13c168eea28d/src/libsystemd-daemon/sd-daemon.c#L414 looks much worse, but it packs more functionality than simply readiness signalling. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification (was: One issue with ongoing depoetterization)
On Fri, Jun 12, 2015 at 01:46:41PM -0400, Steve Litt wrote: [cut] > > Hi Laurent, > > I agree with every single thing you write above, but have one question > for you: What does Devuan do when daemons like cupsd and sshd make > sd_notify calls, and these don't condition the call on sd_notify being > available, and sd_notify cannot be conditionally recompiled out of the > program? Is Devuan going to rewrite every single daemon? > You can always patch-out the calls to sd_notify, can't you? Patching vanilla software to adhere to a set of requirements is exactly what distributions normally do, after all -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
On 12/06/2015 19:46, Steve Litt wrote: I agree with every single thing you write above, but have one question for you: What does Devuan do when daemons like cupsd and sshd make sd_notify calls, and these don't condition the call on sd_notify being available, and sd_notify cannot be conditionally recompiled out of the program? Is Devuan going to rewrite every single daemon? I have a detailed answer to this but I have to go out right now for a few hours. Sorry about that and stay tuned. ;) -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification (was: One issue with ongoing depoetterization)
On Fri, 12 Jun 2015 19:37:21 +0200 Laurent Bercot wrote: > On 12/06/2015 19:01, Steve Litt wrote: > > The one thing I *do* know is that we need to provide a sd_notify > > interface, even if it does nothing at all and drops passed > > information on the floor. > > Please don't do this. > The more you bend to the systemd interfaces, the more it gets a foot > in the door. By implementing a dummy sd_notify, you acknowledge the > validity of the interface; you accept that the systemd people have > created something worth using, and you validate the existence of > (a part of) systemd. > > The thing is, the sd_notify interface is not *too* bad, but like > the rest of systemd, it is overengineered, too complex, and mixes > several different things in a monolithic way so that people who are > trying to actually implement real support for sd_notify are bound > to reinvent systemd one way or another. > > It's absolutely like the old Microsoft "embrace and extend" > strategy, you know. They get one foot in the door by providing > something useful, but then pile their own crap onto it, and people > are already relying on it, so you want to implement support for it, > and then you're captive, and the only way to be 100%-compatible is to > use the original product. > > There's a much simpler mechanism that can be used to provide > readiness notification, and that I suggest in > http://skarnet.org/software/s6/notifywhenup.html > and that is: write a given character on a descriptor, then close that > descriptor. > It doesn't get any simpler than that, it doesn't require linking > daemons against any library, and it can be made to be compatible > with *everything*. If a daemon supports that mechanism, it is very > easy to write a systemd-notify program that would wrap that daemon and > communicate with systemd via sd_notify to inform it of the daemon's > readiness, the way s6-notifywhenup does for s6. > > Please KISS, and design good interfaces to be adopted, instead of > letting yourselves get bullied by systemd forcing its interfaces down > your throats and jumping through hoops to adapt to them. With a > simpler interface and a trivial wrapper program, the influence of > systemd only extends to the wrapper program, and not to the daemons > themselves. Hi Laurent, I agree with every single thing you write above, but have one question for you: What does Devuan do when daemons like cupsd and sshd make sd_notify calls, and these don't condition the call on sd_notify being available, and sd_notify cannot be conditionally recompiled out of the program? Is Devuan going to rewrite every single daemon? By the way, if there *were* a stub sd_notify, I'd have nothing against it doing nothing but passing the info to S6-notifywhenup or something like it. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Readiness notification (was: One issue with ongoing depoetterization)
On 12/06/2015 19:01, Steve Litt wrote: The one thing I *do* know is that we need to provide a sd_notify interface, even if it does nothing at all and drops passed information on the floor. Please don't do this. The more you bend to the systemd interfaces, the more it gets a foot in the door. By implementing a dummy sd_notify, you acknowledge the validity of the interface; you accept that the systemd people have created something worth using, and you validate the existence of (a part of) systemd. The thing is, the sd_notify interface is not *too* bad, but like the rest of systemd, it is overengineered, too complex, and mixes several different things in a monolithic way so that people who are trying to actually implement real support for sd_notify are bound to reinvent systemd one way or another. It's absolutely like the old Microsoft "embrace and extend" strategy, you know. They get one foot in the door by providing something useful, but then pile their own crap onto it, and people are already relying on it, so you want to implement support for it, and then you're captive, and the only way to be 100%-compatible is to use the original product. There's a much simpler mechanism that can be used to provide readiness notification, and that I suggest in http://skarnet.org/software/s6/notifywhenup.html and that is: write a given character on a descriptor, then close that descriptor. It doesn't get any simpler than that, it doesn't require linking daemons against any library, and it can be made to be compatible with *everything*. If a daemon supports that mechanism, it is very easy to write a systemd-notify program that would wrap that daemon and communicate with systemd via sd_notify to inform it of the daemon's readiness, the way s6-notifywhenup does for s6. Please KISS, and design good interfaces to be adopted, instead of letting yourselves get bullied by systemd forcing its interfaces down your throats and jumping through hoops to adapt to them. With a simpler interface and a trivial wrapper program, the influence of systemd only extends to the wrapper program, and not to the daemons themselves. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] One issue with ongoing depoetterization
dear Steve, On Fri, 12 Jun 2015, Steve Litt wrote: > Hi all, > > When Irrwahn mentioned that cups needed depoetterization I would really prefer if we avoid such a... "personalising neologism" lets talk about systemd? we all need to continue working to avoid personal attacks. If we don't do that now, in a way or another we'll also be victims of that and it will bring no good to anyone. I kindly ask you and other fine contributors to this discussion space to somehow "disarm" the discussion around the systemd avalanche. thanks, ciao signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] One issue with ongoing depoetterization
On Fri, 12 Jun 2015 17:31:10 +0100 Matthew Melton wrote: > > > Steve Litt wrote > > > Hi all, > > > > When Irrwahn mentioned that cups needed depoetterization, my first > > thought was "what in the world does cups need with systemd? And > > then I realized the problem. > > > > Like a lot of us, I'm on the supervis...@list.skarnet.org mailing > > list, where they discuss all things init, mainly from the > > perspective of daemontools-inspired inits. For months, literally, > > the supervision list has been wringing its hands over the very real > > problem that, for process dependency purposes, one must know that > > process X is not only running, but ready to handle its business. > > Knowing process X is running isn't sufficent, because some > > processes take a long time between running and being ready for > > business. Cough, cough, dhclient, cough cough. I mean, look at the > > kludge I use to make sure the network's running before running > > sshd, for instance: > > > > == > > #!/bin/sh > > if ! ifconfig | grep "\s*inet addr:"; then > > sleep 5 > > exit 1 > > fi > > exec /usr/sbin/sshd -d -q > > == > > > > Systemd "offers" daemons the sd_notify(3) call, by which they can > > inform systemd that they're ready. I said "offers", because as soon > > as a critical mass of daemons have drunk the Kool Aid, it will be > > about as much of an "offer" as "Windows certified" is an "offer". > > In fact, I fully expect that, before long, daemons will need to > > become "systemd certified" to be included in some distros. > > > > The tough thing is, this ready-notification is actually a good idea > > that solves a lot of problems and presents a lot of opportunities. > > It's just too bad it was "standardized" by an atrocity like > > systemd. Over and over again, you can expect every single daemon to > > become poetterized as it adopts sd_notify(3). > > > > In the beginning, depoetterization of these daemons might consist > > solely of removing package dependencies, but sooner or later > > non-optional sd_notify will become manditory for systemd > > certification. Why? You know why. > > > > So we play their silly game and code a stub sd_notify, that does > > nothing. Or perhaps even better, lists the daemon as ready for > > business in some kind of table that init can refer to. > > > > I don't know much about sysvinit, but with daemontools-encore, and > > probably runit, it wouldn't be super-hard to have a table of all > > services with all of their dependencies, and when all a service's > > dependencies become ready for business, the service is run > > affirmatively. This is probably what systemd had in mind in the > > first place: Too bad they had to tack on all the other crap. > > > > So, if we code up a dummy sd_notify to interface replace the one > > from systemd, we can make ongoing future depoetterization easier, > > and very possibly give ourselves a better, easier to administer > > init. > > > > SteveT > > > > Steve Litt > > June 2015 featured book: The Key to Everyday Excellence > > http://www.troubleshooters.com/key > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > Could a convention be to use the logs to notify any listeners that > the service has been successfully started? Since most services use > the logs anyway would it be trivial to have a /var/log/running log? > > A scripted dependency can check the log using grep or whatever. > Before starting. No need for another binary. > > A bit like how fail2ban does its magic... > > I'll go back to lurking. > > Matt Hi Matt, I don't know. How's that for an authoritative answer? The one thing I *do* know is that we need to provide a sd_notify interface, even if it does nothing at all and drops passed information on the floor. Later, if we decide to actually *use* the info sent us via sd_notify, I don't know whether the proper venue for that use would be logs or something else. Personally, I'd really prefer we *don't* use dbus for these notifications. I know that's theoretically what dbus is for, but I don't trust dbus as far as I can throw the rocky mountains. I'm at a disadvantage here because the only process management I really understand is daemontools and daemontools-encore. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] One issue with ongoing depoetterization
Hi Steve, So, if we code up a dummy sd_notify to interface replace the one from > systemd, we can make ongoing future depoetterization easier, and very > possibly give ourselves a better, easier to administer init. > If you're referring to this API [1], it doesn't look too bad. In most cases, it looks like we should be able to create a library that simply wrote the relevant information to a well-known location in the filesystem (such as "/run/srv/$SERVICE/..."). Other processes interested in the state of $SERVICE would just read it directly, and use inotify(2) to watch for state changes. Tooting my own horn here, but if we mounted runfs [2] on /run/srv/, we could also be guaranteed that /run/srv/$SERVICE/... automatically disappears if $SERVICE dies unexpectedly. Thanks, Jude [1] http://www.freedesktop.org/software/systemd/man/sd_notify.html [2] https://github.com/jcnelson/runfs ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A nice candidate substitute to network-manager
On 2015-06-12 10:03, Steve Litt wrote: On Fri, 12 Jun 2015 07:50:25 -0300 Marlon Nunes wrote: Hi, i've been testing connman for a while and found it to handle very well my network connections. https://01.org/connman The following sentence from the preceding link made me sweat a little bit: = ConnMan is optimized through open source for embedded and client focused Intel® Quark technology, Intel® Atom™ processors and Intel® Core™ processors. = I'm an AMD guy. I found it ok just for the fact that its completely independent of systemd. https://wiki.archlinux.org/index.php/Connman Those Arch guys are the biggest bunch of systemd jingoists on the planet but you've got to admit, they write far and away the best documentation on the planet. Their wiki help pages are almost complete. In my view, we can forget about network-manager completely for desktop usage. Whether we stay with Wicd, which Devuan Alpha 2 does such a great job with, or switch to ConnMan, either way, you're right: network-manager is too entangled in dbus and systemd to be useful on Devuan, and it also requires you be in X, and that's not always true. I think that whether Wicd or ConnMan is our default network "make it easier machine", it should be easy to switch between the two, and part of that ease could be good documentation. By the way, I was going to answer Bardot Jérôme's query about Devuan Network-Manager similarly: Better to be rid of Network-Manager than to wonder if it's going to drag in systemd on an update. Network-Manager's wonderful for the one use case Debian envisions, but turns into a stumbling block when you go offroad. That's why a wrote about it. =) -- Stop slacking you lazy bum! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] One issue with ongoing depoetterization
Steve Litt wrote > Hi all, > > When Irrwahn mentioned that cups needed depoetterization, my first > thought was "what in the world does cups need with systemd? And then I > realized the problem. > > Like a lot of us, I'm on the supervis...@list.skarnet.org mailing list, > where they discuss all things init, mainly from the perspective of > daemontools-inspired inits. For months, literally, the supervision list > has been wringing its hands over the very real problem that, for process > dependency purposes, one must know that process X is not only running, > but ready to handle its business. Knowing process X is running isn't > sufficent, because some processes take a long time between running > and being ready for business. Cough, cough, dhclient, cough cough. I > mean, look at the kludge I use to make sure the network's running before > running sshd, for instance: > > == > #!/bin/sh > if ! ifconfig | grep "\s*inet addr:"; then > sleep 5 > exit 1 > fi > exec /usr/sbin/sshd -d -q > == > > Systemd "offers" daemons the sd_notify(3) call, by which they can > inform systemd that they're ready. I said "offers", because as soon as > a critical mass of daemons have drunk the Kool Aid, it will be about as > much of an "offer" as "Windows certified" is an "offer". In fact, I > fully expect that, before long, daemons will need to become "systemd > certified" to be included in some distros. > > The tough thing is, this ready-notification is actually a good idea > that solves a lot of problems and presents a lot of opportunities. It's > just too bad it was "standardized" by an atrocity like systemd. Over > and over again, you can expect every single daemon to become > poetterized as it adopts sd_notify(3). > > In the beginning, depoetterization of these daemons might consist > solely of removing package dependencies, but sooner or later > non-optional sd_notify will become manditory for systemd certification. > Why? You know why. > > So we play their silly game and code a stub sd_notify, that does > nothing. Or perhaps even better, lists the daemon as ready for business > in some kind of table that init can refer to. > > I don't know much about sysvinit, but with daemontools-encore, and > probably runit, it wouldn't be super-hard to have a table of all > services with all of their dependencies, and when all a service's > dependencies become ready for business, the service is run > affirmatively. This is probably what systemd had in mind in the first > place: Too bad they had to tack on all the other crap. > > So, if we code up a dummy sd_notify to interface replace the one from > systemd, we can make ongoing future depoetterization easier, and very > possibly give ourselves a better, easier to administer init. > > SteveT > > Steve Litt > June 2015 featured book: The Key to Everyday Excellence > http://www.troubleshooters.com/key > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Could a convention be to use the logs to notify any listeners that the service has been successfully started? Since most services use the logs anyway would it be trivial to have a /var/log/running log? A scripted dependency can check the log using grep or whatever. Before starting. No need for another binary. A bit like how fail2ban does its magic... I'll go back to lurking. Matt___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A nice candidate substitute to network-manager
I'm using it on Funtoo. On 2015-06-12 12:30, Anto wrote: On 12/06/15 12:50, Marlon Nunes wrote: Hi, i've been testing connman for a while and found it to handle very well my network connections. https://01.org/connman https://wiki.archlinux.org/index.php/Connman In my view, we can forget about network-manager completely for desktop usage. Hello Marlon, Do you use it on Devuan or Debian jessie? If so, would it be possible to let us know how you get that working? I remember that I had problems trying to make econnman compiled and installed on Debian wheezy. Cheers, Anto ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Stop slacking you lazy bum! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] One issue with ongoing depoetterization
Hi all, When Irrwahn mentioned that cups needed depoetterization, my first thought was "what in the world does cups need with systemd? And then I realized the problem. Like a lot of us, I'm on the supervis...@list.skarnet.org mailing list, where they discuss all things init, mainly from the perspective of daemontools-inspired inits. For months, literally, the supervision list has been wringing its hands over the very real problem that, for process dependency purposes, one must know that process X is not only running, but ready to handle its business. Knowing process X is running isn't sufficent, because some processes take a long time between running and being ready for business. Cough, cough, dhclient, cough cough. I mean, look at the kludge I use to make sure the network's running before running sshd, for instance: == #!/bin/sh if ! ifconfig | grep "\s*inet addr:"; then sleep 5 exit 1 fi exec /usr/sbin/sshd -d -q == Systemd "offers" daemons the sd_notify(3) call, by which they can inform systemd that they're ready. I said "offers", because as soon as a critical mass of daemons have drunk the Kool Aid, it will be about as much of an "offer" as "Windows certified" is an "offer". In fact, I fully expect that, before long, daemons will need to become "systemd certified" to be included in some distros. The tough thing is, this ready-notification is actually a good idea that solves a lot of problems and presents a lot of opportunities. It's just too bad it was "standardized" by an atrocity like systemd. Over and over again, you can expect every single daemon to become poetterized as it adopts sd_notify(3). In the beginning, depoetterization of these daemons might consist solely of removing package dependencies, but sooner or later non-optional sd_notify will become manditory for systemd certification. Why? You know why. So we play their silly game and code a stub sd_notify, that does nothing. Or perhaps even better, lists the daemon as ready for business in some kind of table that init can refer to. I don't know much about sysvinit, but with daemontools-encore, and probably runit, it wouldn't be super-hard to have a table of all services with all of their dependencies, and when all a service's dependencies become ready for business, the service is run affirmatively. This is probably what systemd had in mind in the first place: Too bad they had to tack on all the other crap. So, if we code up a dummy sd_notify to interface replace the one from systemd, we can make ongoing future depoetterization easier, and very possibly give ourselves a better, easier to administer init. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A nice candidate substitute to network-manager
On 12/06/15 17:47, Anto wrote: On 12/06/15 17:39, Irrwahn wrote: On Fri, 12 Jun 2015 17:30:58 +0200, Anto wrote: On 12/06/15 12:50, Marlon Nunes wrote: Hi, i've been testing connman for a while and found it to handle very well my network connections. https://01.org/connman https://wiki.archlinux.org/index.php/Connman In my view, we can forget about network-manager completely for desktop usage. Do you use it on Devuan or Debian jessie? If so, would it be possible to let us know how you get that working? I remember that I had problems trying to make econnman compiled and installed on Debian wheezy. There are connman and related packages available in Debian since squeeze. Just mentioning - not that I ever tried it, though. Cheers, Urban Thanks Urban, I have been using wicd since the infections started on Debian wheezy and after I failed to try other alternatives to network-manager. As far as I remember, I couldn't get connman to work on Debian wheezy and there was no GUI interface for XFCE. I tried econnman on Enlightenment, but I got the problems that I mentioned above. Cheers, Anto I should have written my previous sentence properly like "there was no connman GUI interface for XFCE in Debian wheezy when I tried it". :) I just double checked. There is actually connman gui on Devuan/Debian jessie as shown below. But I have not tried that yet. Does anybody try that on XFCE? Cheers, Anto root@hp8530w:~# apt-cache policy connman-ui connman-ui: Installed: (none) Candidate: 0~20130115-1 Version table: 0~20130115-1 0 90 http://packages.devuan.org/merged/ jessie/main amd64 Packages root@hp8530w:~# root@hp8530w:~# apt-cache show connman-ui Package: connman-ui Version: 0~20130115-1 Installed-Size: 365 Maintainer: Shawn Landden Architecture: amd64 Depends: connman, libatk1.0-0 (>= 1.12.4), libc6 (>= 2.4), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.2.4), libdbus-1-3 (>= 1.1.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.28.0), libgtk-3-0 (>= 3.0.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0) Description: Full-featured GTK-based tray icon UI for ConnMan Multi-Arch: foreign Homepage: https://github.com/tbursztyka/connman-ui Description-md5: b1a08eec2ed99c044b2ef6eadf250cf8 Tag: interface::x11, role::program, uitoolkit::gtk, x11::application Section: net Priority: optional Filename: pool/DEBIAN/main/c/connman-ui/connman-ui_0~20130115-1_amd64.deb Size: 74070 MD5sum: f634526109471bcebe4611467a6c21ce SHA1: 7a82293addcaa3b41e68dc4484fc2c7a4e6cc657 SHA256: c5c74443c830cd67cd8175cb64680a423569faebe754006457cbafc8ee6a8a1e root@hp8530w:~# ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A nice candidate substitute to network-manager
On 12/06/15 17:39, Irrwahn wrote: On Fri, 12 Jun 2015 17:30:58 +0200, Anto wrote: On 12/06/15 12:50, Marlon Nunes wrote: Hi, i've been testing connman for a while and found it to handle very well my network connections. https://01.org/connman https://wiki.archlinux.org/index.php/Connman In my view, we can forget about network-manager completely for desktop usage. Do you use it on Devuan or Debian jessie? If so, would it be possible to let us know how you get that working? I remember that I had problems trying to make econnman compiled and installed on Debian wheezy. There are connman and related packages available in Debian since squeeze. Just mentioning - not that I ever tried it, though. Cheers, Urban Thanks Urban, I have been using wicd since the infections started on Debian wheezy and after I failed to try other alternatives to network-manager. As far as I remember, I couldn't get connman to work on Debian wheezy and there was no GUI interface for XFCE. I tried econnman on Enlightenment, but I got the problems that I mentioned above. Cheers, Anto ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A nice candidate substitute to network-manager
On Fri, 12 Jun 2015 17:30:58 +0200, Anto wrote: > On 12/06/15 12:50, Marlon Nunes wrote: >> Hi, i've been testing connman for a while and found it to handle very >> well my network connections. >> >> https://01.org/connman >> https://wiki.archlinux.org/index.php/Connman >> >> In my view, we can forget about network-manager completely for desktop >> usage. > > Do you use it on Devuan or Debian jessie? If so, would it be possible to > let us know how you get that working? > > I remember that I had problems trying to make econnman compiled and > installed on Debian wheezy. There are connman and related packages available in Debian since squeeze. Just mentioning - not that I ever tried it, though. Cheers, Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A nice candidate substitute to network-manager
On 12/06/15 12:50, Marlon Nunes wrote: Hi, i've been testing connman for a while and found it to handle very well my network connections. https://01.org/connman https://wiki.archlinux.org/index.php/Connman In my view, we can forget about network-manager completely for desktop usage. Hello Marlon, Do you use it on Devuan or Debian jessie? If so, would it be possible to let us know how you get that working? I remember that I had problems trying to make econnman compiled and installed on Debian wheezy. Cheers, Anto ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] LightDM and Xfce issues
On 12/06/15 10:33, Dima Krasner wrote: Hello, I'm currently investigating various reports of session/power management related issues. Please let me know if you see either: - Greyed-out shutdown/reboot buttons in LightDM or Xfce - Shutdown/reboot buttons which do nothing when clicked Thank you, Dima Hello Dima, I have never experienced the problem with shut down and restart buttons on LightDM and XFCE. But I had problems with suspend and hibernate buttons, either they greyed out or they completely disappeared. I think I solved them by re-compiling and installed upower 0.9.23. As far as I remember, upower versions after that have got "infected" so it forced me to use the packages that I really don't want to use and I wish that they do not exist on the face of the earth. Cheers, Anto ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
On Fri, 12 Jun 2015 09:54:06 -0400, Fsmithred wrote: > On 06/12/2015 09:33 AM, Irrwahn wrote: >> - Make sure you're using sysvinit-core as init system, and slim or lightdm >> as >> your display manager. >> >> - Purge everything *systemd*! However, you may want to keep libsystemd0, in >> case you want to use gvfs, cups, pulse or anything else that (still) >> depends >> on it. >> >> - Install: policykit-1, consolekit, libpam-ck-connector, upower >> >> - A reboot at this point should be in order, not sure if it's exactly >> necessary. > > policykit-1, consolekit, libpam-ck-connector, upower were all installed > already. What I don't understand is why the shutdown/reboot didn't start > working again when I reinstalled systemd, libpam-systemd and systemd-shim > (and rebooted). PID1 is init, and /sbin/init is not a symlink. Also, > libsystemd0 was not removed at any time. > > What does fix it is to do something dimkr had me do when I was testing > alpha1 - rename/move /lib/systemd/systemd-logind. All the buttons work > after that. When there's a /lib/systemd/systemd-logind, then not all the systemd packages were purged properly. :-) Anyway, IIRC dimkr is already working on a fix for the logind/consolekit clash. FWIW, I've got three Devuan installations running: jessie VM, ascii VM, ascii on real hardware. In all of them I was able to get everything (including shutdown et. al) working without systemd, except libsystemd0 is ATM still needed for gvfs, pulse, cups, sane, syslog - until those packages are disinfected as well. Cheers, Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
On 06/12/2015 09:33 AM, Irrwahn wrote: > fsmithred wrote on 12.06.2015 14:40: >> >> Not the OP here, and not exactly what you're asking, but here's what I did >> yesterday: >> >> Installed devuan-alpha2-amd64 netinstall iso in virtualbox. At tasksel, I >> un-checked Print Server and Devuan Desktop Environment, and I checked >> XFCE. All seemed to be working well after install. >> >> >> dpkg -l | grep systemd >> ii libpam-systemd:amd64 215-17+deb8u1 >> amd64system and service manager - PAM module >> ii libsystemd0:amd64 215-17+deb8u1 >> amd64systemd utility library >> ii systemd 215-17+deb8u1 >> amd64system and service manager >> ii systemd-shim 9-1 >> amd64shim for systemd >> >> >> 'aptitude why' pointed to task-xfce-desktop as the reason for systemd >> packages, so I attempted to remove that. >> >> 'apt-get -s remove task-xfce-desktop libpam-systemd systemd' gave me a >> long list of packages that were no longer needed and were set to >> autoremove. (See below for the full list.) So I apt-get installed that >> list of packages and then I could remove systemd, systemd-shim and >> libpam-systemd without losing my whole desktop environment. >> >> After that, shutdown and reboot buttons stopped working in xfce and >> lightdm. Only logout from the desktop worked, bringing me to the login >> screen. >> >> Then I added back systemd, systemd-shim and libpam-systemd. Desktop >> buttons are no longer gray, but shutdown and reboot only bring me to the >> lightdm login screen. Power button choices in lightdm are all grayed out. >> That's not what I expected, and I don't know what's different from the >> original install. If I get a chance to do it again, I can make full >> packages lists before and after to see if something else got removed but >> not reinstalled. > > The following might help (no guarantees, it's from the top of my head - don't > have my notes at hand right now): > > - Make sure you're using sysvinit-core as init system, and slim or lightdm as > your display manager. > > - Purge everything *systemd*! However, you may want to keep libsystemd0, in > case you want to use gvfs, cups, pulse or anything else that (still) > depends > on it. > > - Install: policykit-1, consolekit, libpam-ck-connector, upower > > - A reboot at this point should be in order, not sure if it's exactly > necessary. > > HTH, Regards, > Urban policykit-1, consolekit, libpam-ck-connector, upower were all installed already. What I don't understand is why the shutdown/reboot didn't start working again when I reinstalled systemd, libpam-systemd and systemd-shim (and rebooted). PID1 is init, and /sbin/init is not a symlink. Also, libsystemd0 was not removed at any time. What does fix it is to do something dimkr had me do when I was testing alpha1 - rename/move /lib/systemd/systemd-logind. All the buttons work after that. fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
fsmithred wrote on 12.06.2015 14:40: > > Not the OP here, and not exactly what you're asking, but here's what I did > yesterday: > > Installed devuan-alpha2-amd64 netinstall iso in virtualbox. At tasksel, I > un-checked Print Server and Devuan Desktop Environment, and I checked > XFCE. All seemed to be working well after install. > > > dpkg -l | grep systemd > ii libpam-systemd:amd64 215-17+deb8u1 > amd64system and service manager - PAM module > ii libsystemd0:amd64 215-17+deb8u1 > amd64systemd utility library > ii systemd 215-17+deb8u1 > amd64system and service manager > ii systemd-shim 9-1 > amd64shim for systemd > > > 'aptitude why' pointed to task-xfce-desktop as the reason for systemd > packages, so I attempted to remove that. > > 'apt-get -s remove task-xfce-desktop libpam-systemd systemd' gave me a > long list of packages that were no longer needed and were set to > autoremove. (See below for the full list.) So I apt-get installed that > list of packages and then I could remove systemd, systemd-shim and > libpam-systemd without losing my whole desktop environment. > > After that, shutdown and reboot buttons stopped working in xfce and > lightdm. Only logout from the desktop worked, bringing me to the login screen. > > Then I added back systemd, systemd-shim and libpam-systemd. Desktop > buttons are no longer gray, but shutdown and reboot only bring me to the > lightdm login screen. Power button choices in lightdm are all grayed out. > That's not what I expected, and I don't know what's different from the > original install. If I get a chance to do it again, I can make full > packages lists before and after to see if something else got removed but > not reinstalled. The following might help (no guarantees, it's from the top of my head - don't have my notes at hand right now): - Make sure you're using sysvinit-core as init system, and slim or lightdm as your display manager. - Purge everything *systemd*! However, you may want to keep libsystemd0, in case you want to use gvfs, cups, pulse or anything else that (still) depends on it. - Install: policykit-1, consolekit, libpam-ck-connector, upower - A reboot at this point should be in order, not sure if it's exactly necessary. HTH, Regards, Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
On Fri, Jun 12, 2015 at 04:11:12AM +0200, Franco Lanza wrote: > > Anyway, differently from debian, even in the alpha stage in devuan you > can, right now and avoiding some packages like gnome things, have a > completely systemd install. But it's NOT ready, it's NOT release, it's Might you mean "completely systemd-free install"? > an alpha! -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
On Fri, 12 Jun 2015 08:40:44 -0400 fsmithred wrote: > After that, shutdown and reboot buttons stopped working in xfce and > lightdm. Only logout from the desktop worked, bringing me to the > login screen. This has been the bane of my existence since long before systemd. Sometimes my logout and reboot buttons worked, sometimes they were gray, and sometimes they just exited the wm/de. And like fsmithred, once systemd came along and I jumpered across it with another pid1, those buttons almost never worked. I think Devuan should create four can't-miss shellscripts, for these four use cases: * poweroff * reboot * hybernate * suspend On our supported wm/de's that have buttons for these things, those buttons should invoke those shellscripts directly. Obviously, there would need to be a way for those shellscripts to access policykit. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] A nice candidate substitute to network-manager
On Fri, 12 Jun 2015 07:50:25 -0300 Marlon Nunes wrote: > Hi, i've been testing connman for a while and found it to handle very > well my network connections. > > https://01.org/connman The following sentence from the preceding link made me sweat a little bit: = ConnMan is optimized through open source for embedded and client focused Intel® Quark technology, Intel® Atom™ processors and Intel® Core™ processors. = I'm an AMD guy. > https://wiki.archlinux.org/index.php/Connman Those Arch guys are the biggest bunch of systemd jingoists on the planet but you've got to admit, they write far and away the best documentation on the planet. > > In my view, we can forget about network-manager completely for > desktop usage. Whether we stay with Wicd, which Devuan Alpha 2 does such a great job with, or switch to ConnMan, either way, you're right: network-manager is too entangled in dbus and systemd to be useful on Devuan, and it also requires you be in X, and that's not always true. I think that whether Wicd or ConnMan is our default network "make it easier machine", it should be easy to switch between the two, and part of that ease could be good documentation. By the way, I was going to answer Bardot Jérôme's query about Devuan Network-Manager similarly: Better to be rid of Network-Manager than to wonder if it's going to drag in systemd on an update. Network-Manager's wonderful for the one use case Debian envisions, but turns into a stumbling block when you go offroad. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Devuan and sneaker-net
I started with Debian Squeeze on my desktop computer (since it was one of the few Linux distributions that would work with my hardware) and when it came time to update to Wheezy I did so by sneaker-net. I'd heard that Debian Jessie was out but I just didn't get around to trying to update my system again and from what I've been reading about the switch to systemd, I'm glad I didn't. I had been considering switching to file-rc or runit or busybox's init program (something less complex than sysvinit) not something more complex like systemd. I would like to try my sneaker-net process with Devuan instead of Debian and hope it will work in a similar fashion. I download all my dependencies by sneaker-net and check them over before installing. I want to know exactly what's on my system. I'd probably be running a distribution like Slackware right now where the user handles the dependencies rather than the package manager, except that there were some hardware installation issues with getting it working with my desktop. I hope Devuan will be as friendly to people who use sneaker-net for installation as Debian has been in the past. My documentation on the techniques I use to sneaker-net and control what is installed on my system is at: http://www.distasis.com/cpp/snet.htm Hope the Devuan project is successful in providing an alternative to Debian that supplies applications that truly attempt to do one task well. I'm a C/C++ developer and I've also done documentation for a number of Open Source projects. I have several ports/modified versions of lightweight program alternatives. One of my goals is to eventually have a working desktop system that runs in framebuffer using mainly sdl, fltk and pdcurses/ncurses based applications. If I can help the project out with programming and/or documentation, I would certainly be interested in doing so. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
On 06/11/2015 02:17 PM, Jude Nelson wrote: > Hi Clarke, > > Can you: > * give us a listing of which systemd packages are installed (something like > "aptitude search systemd | egrep ^i")? > * use "apt-cache rdepends" to show us which packages depend on them? > > Thanks, > Jude > Not the OP here, and not exactly what you're asking, but here's what I did yesterday: Installed devuan-alpha2-amd64 netinstall iso in virtualbox. At tasksel, I un-checked Print Server and Devuan Desktop Environment, and I checked XFCE. All seemed to be working well after install. dpkg -l | grep systemd ii libpam-systemd:amd64 215-17+deb8u1 amd64system and service manager - PAM module ii libsystemd0:amd64 215-17+deb8u1 amd64systemd utility library ii systemd 215-17+deb8u1 amd64system and service manager ii systemd-shim 9-1 amd64shim for systemd 'aptitude why' pointed to task-xfce-desktop as the reason for systemd packages, so I attempted to remove that. 'apt-get -s remove task-xfce-desktop libpam-systemd systemd' gave me a long list of packages that were no longer needed and were set to autoremove. (See below for the full list.) So I apt-get installed that list of packages and then I could remove systemd, systemd-shim and libpam-systemd without losing my whole desktop environment. After that, shutdown and reboot buttons stopped working in xfce and lightdm. Only logout from the desktop worked, bringing me to the login screen. Then I added back systemd, systemd-shim and libpam-systemd. Desktop buttons are no longer gray, but shutdown and reboot only bring me to the lightdm login screen. Power button choices in lightdm are all grayed out. That's not what I expected, and I don't know what's different from the original install. If I get a chance to do it again, I can make full packages lists before and after to see if something else got removed but not reinstalled. HTH, fsr crda dns-root-data dnsmasq-base espeak-data exfalso fonts-freefont-ttf gimp 25gimp-data gir1.2-atspi-2.0 gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 26gir1.2-gtksource-3.0 gir1.2-keybinder-3.0 gir1.2-wnck-3.0 27gnome-accessibility-themes gnome-orca gnome-themes-standard 28gnome-themes-standard-data gtk2-engines-pixbuf hyphen-en-us iputils-arping 29iw javascript-common libamd2.3.1 libao-common libao4 libass5 libatk-adaptor 30libaudio2 libavformat56 libbabl-0.1-0 libbasicusageenvironment0 31libbluetooth3 libbrlapi0.6 libcamd2.3.1 libccolamd2.8.0 libcddb2 32libcholmod2.1.2 libchromaprint0 libdc1394-22 libdca0 libdirectfb-1.2-9 33libdiscid0 libdotconf0 libdvbpsi9 libebml4 libenca0 libespeak1 libfaad2 34libflite1 libfreerdp-cache1.1 libfreerdp-client1.1 libfreerdp-codec1.1 35libfreerdp-common1.1.0 libfreerdp-core1.1 libfreerdp-crypto1.1 36libfreerdp-gdi1.1 libfreerdp-locale1.1 libfreerdp-primitives1.1 37libfreerdp-utils1.1 libgail-common libgail18 libgegl-0.2-0 libgimp2.0 38libgme0 libgpod-common libgpod4 libgroupsock4 libgtksourceview-3.0-1 39libgtksourceview-3.0-common libilmbase6 libiso9660-8 libjs-jquery 40libjs-sphinxdoc libjs-underscore libkate1 libkeybinder-3.0-0 41liblightdm-gobject-1-0 liblircclient0 liblivemedia42 liblouis-data liblouis2 42liblua5.2-0 libmatroska6 libmbim-glib4 libmbim-proxy libmm-glib0 libmng1 43libmodplug1 libmpcdec6 libmtp-common libmtp-runtime libmtp9 libndp0 44libnetfilter-conntrack3 libnl-3-200 libnl-genl-3-200 libnl-route-3-200 45libnm-glib-vpn1 libnm-glib4 libnm-gtk-common libnm-gtk0 libnm-util2 46libopenexr6 libopenraw1 libportaudio2 libpostproc53 libqmi-glib1 47libqmi-proxy libqt4-dbus libqt4-xml libqtcore4 libqtdbus4 libqtgui4 48libreoffice-gtk libresid-builder0c2a libsdl-image1.2 libsdl1.2debian 49libsgutils2-2 libshine3 libsidplay2 libsonic0 libspeechd2 libswscale3 50libteamdctl0 libtidy-0.99-0 libumfpack5.6.2 libupnp6 libusageenvironment2 51libva-drm1 libva-x11-1 libvcdinfo0 libvlc5 libvlccore8 libvncclient0 52libwinpr-crt0.1 libwinpr-crypto0.1 libwinpr-dsparse0.1 53libwinpr-environment0.1 libwinpr-file0.1 libwinpr-handle0.1 libwinpr-heap0.1 54libwinpr-input0.1 libwinpr-interlocked0.1 libwinpr-library0.1 55libwinpr-path0.1 libwinpr-pool0.1 libwinpr-registry0.1 libwinpr-rpc0.1 56libwinpr-sspi0.1 libwinpr-synch0.1 libwinpr-sysinfo0.1 libwinpr-thread0.1 57libwinpr-utils0.1 libwmf0.2-7 libwnck-3-0 libwnck-3-common libxcb-composite0 58libxcb-keysyms1 libxcb-randr0 libxcb-xv0 lightdm lightdm-gtk-greeter 59media-player-info mobile-broadband-provider-info modemmanager python-cddb 60python-feedparser python-musicbrainz2 python-mutagen python-pyinotify 61python-utidylib python3-brlapi python3-cairo python3-gi python3-lou
[Dng] A nice candidate substitute to network-manager
Hi, i've been testing connman for a while and found it to handle very well my network connections. https://01.org/connman https://wiki.archlinux.org/index.php/Connman In my view, we can forget about network-manager completely for desktop usage. -- Stop slacking you lazy bum! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Systemd sneaks in was file download zone
On Fri, Jun 12, 2015 at 02:38:30PM +0530, Gautam Nath wrote: > We all are sure that you will take care of those things in case of fresh > installation. This will take some more time only. Heartfull of thanks. > > I am a general user and sourcing devuan/merged repositary. This might be > better that all bad stuff will be deleted on regular (upgrade)dist-upgrade. > For final pruning on update there may be a wellcome massage to galaxy. And > a todo/wiki is also desiarable. > Any sugar or milk in your coffee? :D -- [ 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
Re: [Dng] Systemd sneaks in was file download zone
We all are sure that you will take care of those things in case of fresh installation. This will take some more time only. Heartfull of thanks. I am a general user and sourcing devuan/merged repositary. This might be better that all bad stuff will be deleted on regular (upgrade)dist-upgrade. For final pruning on update there may be a wellcome massage to galaxy. And a todo/wiki is also desiarable. Cheers gnath On Fri, Jun 12, 2015 at 8:07 AM, Steve Litt wrote: > On Fri, 12 Jun 2015 04:11:12 +0200 > Franco Lanza wrote: > > > > Anyway, differently from debian, even in the alpha stage in devuan you > > can, right now and avoiding some packages like gnome things, have a > > completely systemd install. > > Even more to the point, unlike Debian, with Devuan Alpha 2 you can run > an OS whose PID1 isn't systemd. I think tying everything else to PID1 > was most peoples' major complaint, although by now most of us want to > completely purge the init that shall not be mentioned. > > > Let's the haters hate, and > > Man, and they do hate, don't they. On my local LUG I posted how I > created LittKit to give Daemontools ordered startup capability, never > mentioning any init system, and right away it turned into a cheering > session for systemd, and dissing of anyone who wasn't with the program. > Sheesh, all I did was write about Free Software to make daemontools > more capable. > > > let's us all work for the good. > > Yeah, that's why I'm proud to be friends with you guys. > > SteveT > > Steve Litt > June 2015 featured book: The Key to Everyday Excellence > http://www.troubleshooters.com/key > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello everybody My schedule was full, i want to know if we can migrate from stretch and what how can i do this. Do you know if there is a version of network-manager-gnome and co without systemd ? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVeqApAAoJECB96dtv16eGp7AH/iveli/KzGgMtCbZM2RDolw/ KvFHE4/t59p9GcMMB/uPKi4exZ4A2irmOpg1YCjyMlYFQk92Kdq/p8pjFGDD1W4+ L60xvYzNIYhzY7KFUmMonF4NDLafiDnv/mz9R6U0ya5aI6riyD/QSWWq7CxiUSt/ TIQ2VKlg7a7Qip4vyFzD5RcK5p4fRGnw0K3PQypiYVLsqouuDmYNB4eh5pyEQJP/ gMP1Bj+KDN9W829YZ0jwQ6hiFGvldKU96T+uHMjRbLy2e4h8GUCAY5py6xAyZek1 JBG3ja4Zsr8LQVBFbCIbo1WNkY55Qz31bcRb6qlOdrIech+QFmyVyEENFeUVahA= =7wKc -END PGP SIGNATURE- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] LightDM and Xfce issues
Hello, I'm currently investigating various reports of session/power management related issues. Please let me know if you see either: - Greyed-out shutdown/reboot buttons in LightDM or Xfce - Shutdown/reboot buttons which do nothing when clicked Thank you, Dima -- Dima Krasner ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
