Re: [DNG] BUG: zombies increase while running netman
Hi,
OK, poWaitOnExit added and zombies creation has been reduced. However,
I am still getting these:
3584 ?00:00:00 kworker/u8:0
3586 ?00:00:00 kworker/1:3
3588 ?00:00:01 netman
3623 ?00:00:00 ifdown
3644 ?00:00:00 kworker/0:0
3645 ?00:00:00 kworker/0:3
3898 ?00:00:00 ifup
4142 ?00:00:00 ifdown
4163 ?00:00:00 kworker/0:4
4186 pts/000:00:00 ps
This means, I have to also add code to the backend to properly clean
up after terminating on every run.
It looks like the culprit is execl which is used in core_functions.c.
We must add some code to rid ourselves of zombies.
I found that to get rid of zombies this function is used:
int status;
waitpid(pid, &status, 0);
However, I need the child's pid.
I also found this code snippet using fork() to create a child process
and record its pid:
int status;
pid_t pid;
pid = fork ();
if (pid == 0)
{
/* This is the child process. Execute the shell command. */
execl (SHELL, SHELL, "-c", command, NULL);
_exit (EXIT_FAILURE);
}
else if (pid < 0)
/* The fork failed. Report failure. */
status = -1;
else
/* This is the parent process. Wait for the child to complete. */
if (waitpid (pid, &status, 0) != pid)
status = -1;
return status;
Therefore, to properly get rid of zombies, whenever execl is used, I have to:
if (fork() == 0) {
execl("/sbin/ifup", "ifup", ethx, (char *) NULL); // example from
core_functions.c
} else {
// failure of fork()
}
waitpid (pid, &status, 0); // this removes the zombie
Thanks.
On 30/08/2015, tilt! wrote:
> Hi Edward,
>
> every subprocess that is started must be "waited on" for proper
> completion, or else it never terminates and becomes a zombie.
>
> In backend.pas, in function run_backend(), either use the option
> poWaitOnExit when creating AProcess or use the method
> WaitOnExit() after the output has been read from the backend.
>
> Kind regards,
> T.
>
>
> On 08/29/2015 10:41 PM, Edward Bartolo wrote:
>> Running "ps -e" while netman runs for a some time results in zombies as
>> follows:
>>
>> edbarx@edbarx-pc:~$ ps -e
>>PID TTY TIME CMD
>> 1 ?00:00:00 init
>> 2 ?00:00:00 kthreadd
>> 3 ?00:00:05 ksoftirqd/0
>> 5 ?00:00:00 kworker/0:0H
>> 7 ?00:00:12 rcu_sched
>> 8 ?00:00:00 rcu_bh
>> 9 ?00:00:00 migration/0
>> 10 ?00:00:00 watchdog/0
>> 11 ?00:00:00 watchdog/1
>> 12 ?00:00:00 migration/1
>> 13 ?00:00:06 ksoftirqd/1
>> 15 ?00:00:00 kworker/1:0H
>> 16 ?00:00:00 khelper
>> 17 ?00:00:00 kdevtmpfs
>> 18 ?00:00:00 netns
>> 19 ?00:00:00 khungtaskd
>> 20 ?00:00:00 writeback
>> 21 ?00:00:00 ksmd
>> 22 ?00:00:00 khugepaged
>> 23 ?00:00:00 crypto
>> 24 ?00:00:00 kintegrityd
>> 25 ?00:00:00 bioset
>> 26 ?00:00:00 kblockd
>> 29 ?00:00:00 kswapd0
>> 30 ?00:00:00 fsnotify_mark
>> 36 ?00:00:00 kthrotld
>> 37 ?00:00:00 ipv6_addrconf
>> 39 ?00:00:00 deferwq
>> 75 ?00:00:00 khubd
>> 76 ?00:00:00 acpi_thermal_pm
>> 77 ?00:00:00 ata_sff
>> 78 ?00:00:00 scsi_eh_0
>> 79 ?00:00:00 scsi_tmf_0
>> 80 ?00:00:00 scsi_eh_1
>> 81 ?00:00:00 scsi_tmf_1
>> 85 ?00:00:00 scsi_eh_2
>> 86 ?00:00:00 scsi_tmf_2
>> 87 ?00:00:00 scsi_eh_3
>> 88 ?00:00:00 scsi_tmf_3
>> 95 ?00:00:00 kworker/1:1H
>> 96 ?00:00:00 kworker/0:1H
>>118 ?00:00:00 jbd2/sda9-8
>>119 ?00:00:00 ext4-rsv-conver
>>309 ?00:00:00 udevd
>>359 ?00:00:00 hd-audio0
>>368 ?00:00:00 kpsmoused
>>389 ?00:00:00 cfg80211
>> 1277 ?00:00:00 rpcbind
>> 1305 ?00:00:00 rpc.statd
>> 1310 ?00:00:00 rpciod
>> 1312 ?00:00:00 nfsiod
>> 1319 ?00:00:00 rpc.idmapd
>> 1555 ?00:00:00 rsyslogd
>> 1597 ?00:00:00 atd
>> 1643 ?00:00:00 acpid
>> 1665 ?00:00:00 cron
>> 1726 ?00:00:00 dbus-daemon
>> 1919 ?00:00:05 xchat
>> 1965 ?00:00:00 exim4
>> 1985 ?00:00:00 slim
>> 2011 tty7 00:09:19 Xorg
>> 2012 tty1 00:00:00 getty
>> 2013 tty2 00:00:00 getty
>> 2014 tty3 00:00:00 getty
>> 2015 tty4 00:00:00 getty
>> 2016 tty5 00:00:00 getty
>> 2017 tty6 00:00:00 getty
>> 2030 ?00:00:00 kauditd
>> 2032 ?00:00:00 console-kit-dae
>> 2099 ?00:00:00 polkitd
>> 2110 ?00:00:00 sh
>> 2162 ?00:00:00 ssh-agent
>> 2165 ?00:00:00 dbus-launch
>> 2166 ?00:00:00 dbus-daemon
>> 2176 ?
Re: [DNG] BUG: zombies increase while running netman
Hi Edward, every subprocess that is started must be "waited on" for proper completion, or else it never terminates and becomes a zombie. In backend.pas, in function run_backend(), either use the option poWaitOnExit when creating AProcess or use the method WaitOnExit() after the output has been read from the backend. Kind regards, T. On 08/29/2015 10:41 PM, Edward Bartolo wrote: Running "ps -e" while netman runs for a some time results in zombies as follows: edbarx@edbarx-pc:~$ ps -e PID TTY TIME CMD 1 ?00:00:00 init 2 ?00:00:00 kthreadd 3 ?00:00:05 ksoftirqd/0 5 ?00:00:00 kworker/0:0H 7 ?00:00:12 rcu_sched 8 ?00:00:00 rcu_bh 9 ?00:00:00 migration/0 10 ?00:00:00 watchdog/0 11 ?00:00:00 watchdog/1 12 ?00:00:00 migration/1 13 ?00:00:06 ksoftirqd/1 15 ?00:00:00 kworker/1:0H 16 ?00:00:00 khelper 17 ?00:00:00 kdevtmpfs 18 ?00:00:00 netns 19 ?00:00:00 khungtaskd 20 ?00:00:00 writeback 21 ?00:00:00 ksmd 22 ?00:00:00 khugepaged 23 ?00:00:00 crypto 24 ?00:00:00 kintegrityd 25 ?00:00:00 bioset 26 ?00:00:00 kblockd 29 ?00:00:00 kswapd0 30 ?00:00:00 fsnotify_mark 36 ?00:00:00 kthrotld 37 ?00:00:00 ipv6_addrconf 39 ?00:00:00 deferwq 75 ?00:00:00 khubd 76 ?00:00:00 acpi_thermal_pm 77 ?00:00:00 ata_sff 78 ?00:00:00 scsi_eh_0 79 ?00:00:00 scsi_tmf_0 80 ?00:00:00 scsi_eh_1 81 ?00:00:00 scsi_tmf_1 85 ?00:00:00 scsi_eh_2 86 ?00:00:00 scsi_tmf_2 87 ?00:00:00 scsi_eh_3 88 ?00:00:00 scsi_tmf_3 95 ?00:00:00 kworker/1:1H 96 ?00:00:00 kworker/0:1H 118 ?00:00:00 jbd2/sda9-8 119 ?00:00:00 ext4-rsv-conver 309 ?00:00:00 udevd 359 ?00:00:00 hd-audio0 368 ?00:00:00 kpsmoused 389 ?00:00:00 cfg80211 1277 ?00:00:00 rpcbind 1305 ?00:00:00 rpc.statd 1310 ?00:00:00 rpciod 1312 ?00:00:00 nfsiod 1319 ?00:00:00 rpc.idmapd 1555 ?00:00:00 rsyslogd 1597 ?00:00:00 atd 1643 ?00:00:00 acpid 1665 ?00:00:00 cron 1726 ?00:00:00 dbus-daemon 1919 ?00:00:05 xchat 1965 ?00:00:00 exim4 1985 ?00:00:00 slim 2011 tty7 00:09:19 Xorg 2012 tty1 00:00:00 getty 2013 tty2 00:00:00 getty 2014 tty3 00:00:00 getty 2015 tty4 00:00:00 getty 2016 tty5 00:00:00 getty 2017 tty6 00:00:00 getty 2030 ?00:00:00 kauditd 2032 ?00:00:00 console-kit-dae 2099 ?00:00:00 polkitd 2110 ?00:00:00 sh 2162 ?00:00:00 ssh-agent 2165 ?00:00:00 dbus-launch 2166 ?00:00:00 dbus-daemon 2176 ?00:00:00 xfce4-session 2178 ?00:00:00 xfconfd 2182 ?00:00:00 gpg-agent 2183 ?00:00:02 xfwm4 2185 ?00:00:03 xfce4-panel 2187 ?00:00:00 xfsettingsd 2189 ?00:00:00 syndaemon 2191 ?00:00:00 xfdesktop 2195 ?00:00:00 xfce4-power-man 2199 ?00:00:01 xscreensaver 2202 ?00:00:00 xfce4-power-man 2203 ?00:00:00 xfce4-volumed 2208 ?00:00:00 upowerd 2210 ?00:00:00 panel-6-systray 2213 ?00:00:00 panel-2-actions 2264 ?00:00:45 netman 2271 ?00:00:00 backend 2272 ?00:00:00 cat 2280 ?00:00:00 ifup 2416 ?00:00:00 at-spi-bus-laun 2743 ?00:00:00 kworker/1:1 3809 ?00:00:00 kworker/0:1 4106 ?00:00:00 kworker/u8:0 4595 ?00:00:00 kworker/1:0 4834 ?00:00:00 kworker/u8:2 5130 ?00:00:00 kworker/0:2 5207 ?00:00:00 kworker/1:2 5732 ?00:00:00 xfce4-terminal 5736 ?00:00:00 gnome-pty-helpe 5737 pts/000:00:00 bash 5755 ?00:00:00 ps 5756 pts/000:00:00 ps 7389 ?00:00:00 ifdown 16124 ?00:00:00 ifup 16135 ?00:00:00 wpa_supplicant 16189 ?00:00:00 dhclient 18393 ?00:00:28 medit 26622 ?00:00:00 backend 26853 ?00:00:00 backend 26886 ?00:00:00 backend 26908 ?00:00:00 backend 31536 ?00:08:11 iceweasel I found this suggestion to get rid of zombies. The link is this: https://www.daniweb.com/software-development/cpp/threads/364407/handling-sigchld-to-prevent-zombie-processes What do you suggest? Edward. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglis
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Hi Matteo, On 08/29/2015 02:53 PM, Matteo Panella wrote: [...] On a server, tough, it just does its job nicely (unless you need strict audit of root-level actions, in which case sudo with a MAC system should be your starting point). So much noise (and security-critical code) for nothing. If systemd needs an own program "get me a shell for user X" for their scripts, that accomplishes a very specific setup, specific envvar filtering and such, why not? The developers are free to create what they want and need. As a C programmer, i code stuff like that all the time, when i need specific signal handling, a clean environment, fd and terminal setup... and if i had a lot of work with it, on a bad day, I probably ranted on some existing software in a release note as well (why can't it do this, why do i have to code this at all, blahblah). As a shell script programmer, i use "su" rarely; interactively i use it quite often, and i have no problem with it, if i distinguish "su" from "su -" and keep in mind when to use which. If i personally wanted to write such a "give me a shell" command, i would have different priorities, and it would do different stuff that exactly fits they way i want to work. It would be less universal than what "su" is now, and, being tested just by me, probably less secure. Therefore i would not think of it as a replacement of the "su" command, and if i published it, i would not label it as such. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: ???su??? command replacement merged into systemd on Fedora Rawhide
On Sun, Aug 30, 2015 at 02:20:41AM +0200, Laurent Bercot wrote: > [snip] Alpine Linux, for instance, makes Docker > containers a breeze to use, and makes the images a lot smaller. > Alpine is runit-based, and people have also found success running Docker > containers under s6; systemd is very unnecessary, and anyone pretending > it is is either ignorant or malicious. Correction for this: Alpine Linux is OpenRC based. There is some level of runit integration, but I'm pretty sure it's not the base of the primary rc system (unless they did some *big* changes with no discussion on either list over the last couple weeks). HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 30/08/2015 01:13, Simon Hobson wrote: I don't think anyone has suggested it's for servers only. But, there is an argument for picking the low hanging fruit - and that means trying to do the "easy" bits first. I've not really followed it in detail, but from what I've read it does seem that the desktop environments have been the most tightly bound to systemd. IMO it makes sense to try and get a "non desktop" system sorted, and then tackle the harder problem of getting the desktop stuff cleansed. Honestly, servers are easy, and a few distros have always gone pretty far with what they're doing with servers: Alpine Linux, Void Linux, and many others I'm not following as closely. The "big" or "mainstream" distributions are called that way because they're the ones that people install on their desktops. I'm interested in Devuan because I view it as a replacement for Debian, which I had on my desktop at some point. If it's about a server, I already have lots of distributions to pick from, including not using one in the first place. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 29/08/2015 23:11, Steve Litt wrote: in my LUG, the most pro-systemd guys are the mega-metal admins administering hundreds of boxes with hundreds of Docker containers. These guys are telling me systemd is necessary to efficiently manage the Dockers. They're telling you that because they've been brainwashed with that idea, and since it's working for them, they're too lazy to try anything else. But they're wrong. Alpine Linux, for instance, makes Docker containers a breeze to use, and makes the images a lot smaller. Alpine is runit-based, and people have also found success running Docker containers under s6; systemd is very unnecessary, and anyone pretending it is is either ignorant or malicious. Yeah, whatever, give me the budget Redhat gave the systemd cabal, so I can hire good programmers, and I'll make it work efficiently without breaking Linux and entangling everything. If you have 1/10 of that budget and are hiring, I'm available and willing to full-time this. ;) -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sun, Aug 30, 2015 at 12:13:43AM +0100, Simon Hobson wrote: > > I don't think it's so much a packaging decision by Debian, more a case of > what the upstream devs have done. The Debian decision was (AIUI) "we don't > have the resources to remove the crap" - not a decision to add it, just a > realisation that the project couldn't remove it with the time and resources > available. > I did note some rather naive suggestions that somehow it would be > possible to remove it later. We're the later. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sun, Aug 30, 2015 at 12:13:43AM +0100, Simon Hobson wrote: [cut] > > > Right now with Debian Jessie systemd must be installed to make the > > desktop anywhere near functional, but that is a result of packaging > > decisions by Debian ... > > I don't think it's so much a packaging decision by Debian, more a case of > what the upstream devs have done. The Debian decision was (AIUI) "we don't > have the resources to remove the crap" - not a decision to add it, just a > realisation that the project couldn't remove it with the time and resources > available. I'm sorry but it does not seem to me that the story went like you say. Debian deliberately decided to go for systemd, at a time when no tight systemd dependency existed anywhere in Debian. Please do not forget that the first versions of jessie (testing) were still using sysvinit by default, and none of the packages required systemd to be there. AFAIR there was no mention about the amount of resources needed to "remove the crap" as you say. There were instead specific and identifiable responsabilities by the Debian Project Leader and by the Technical Committee, who decided to ignore all the pressures to stay with sysvinit that came from the userbase and from the developers. Those decisions were not made on the basis of the amount of work needed to contain systemd (which became really a problem *after* Debian chose it as a default), but following an unspecified "need" to go for the best technical solution available on the market. Once systemd was declared the standard in Debian, packagers had to adapt to the new riff and to go all-in in supporting systemd. Those who didn't like it, resigned and moved elsewhere. The present is crap and the future is foggy, so there is no reason at all to mess up with the past as well... HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Nate Bargmann wrote: > I'll add my voice to the chorus objecting to the idea that removal of > systemd is for servers only. I don't think anyone has suggested it's for servers only. But, there is an argument for picking the low hanging fruit - and that means trying to do the "easy" bits first. I've not really followed it in detail, but from what I've read it does seem that the desktop environments have been the most tightly bound to systemd. IMO it makes sense to try and get a "non desktop" system sorted, and then tackle the harder problem of getting the desktop stuff cleansed. > Right now with Debian Jessie systemd must be installed to make the > desktop anywhere near functional, but that is a result of packaging > decisions by Debian ... I don't think it's so much a packaging decision by Debian, more a case of what the upstream devs have done. The Debian decision was (AIUI) "we don't have the resources to remove the crap" - not a decision to add it, just a realisation that the project couldn't remove it with the time and resources available. I did note some rather naive suggestions that somehow it would be possible to remove it later. I'd be surprised if the resources increased, and it'll be a lot harder to remove stuff now they've allowed packagers to add "gratuitous" systemd dependencies. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sun, Aug 30, 2015 at 12:31:44AM +0200, Tobias Hunger wrote: > Hi Jaromil, > > On Sat, Aug 29, 2015 at 9:32 PM, Jaromil wrote: > >>Hi Rainer, do you know that you are feeding a troll ? > >>tobias.hun...@gmail.com appears to be a systemd developer > > I tend to send patches to open source projects that I get into contact > with. It is a really annoying habit I picked up in that free software > scene you might have heard of before. > > Yes, I have a hand full of tiny patches in systemd. Got a few more in > firefox and a couple other places, but would still not call myself a > mozilla developer. A few patches does not at troll make. -- hendrik > > > if that is even a legitimate account, > > Yes. > > Did we get to the point where we need fake emails to follow up on free > software projects now? > > > is he getting paid for his time spent here? > > Sure, I am going to buy a new villa with the millions of euros I make > following a bunch of nerds doing yet another Linux distribution! Can > you recommend a nice place with enough room to mount a 16t mind > control ray on the roof? > > > I find it disturbing. systemd has plenty of avenues for propaganda in Linux > > related tradeshows and some very insisting, annoying and intrusive sorts of > > door-to-door sales people like Tobias. > > Seriously? I was answering to a direct technical question on systemd > raised on this very list. > > > perhaps it should be more clear that they are not welcome here, especially > > if they look for another space to lecture on how systemd works better than > > other "lesser init systems". > > I personally try to understand code that I am going to remove from the > projects I work on and for that reason I am happy to have some people > around that actually are willing and able to answer questions on that > code. > > If you prefer to muck around in the dark here, then I will heed that > wish and lurk only. > > Best Regards, > Tobias > ___ > 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
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
* On 2015 29 Aug 16:14 -0500, Steve Litt wrote: > Yeah, that isn't a problem, and shouldn't be a problem. Interestingly, > in my LUG, the most pro-systemd guys are the mega-metal admins > administering hundreds of boxes with hundreds of Docker containers. > These guys are telling me systemd is necessary to efficiently manage > the Dockers. Okay, then the big official unanswered question is why don't RH, et. al. just target that use case and leave the rest of us alone? Why does the rest of the ecosystem need this big sucking sound? It's one thing to develop a tool that makes life easier in some case and quite another to preach that it's needed *everywhere* and pull in the gullible with influence that then dictate this shiny thing is to be valued above all else. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Hi Jaromil, actually I was not replying to a technical question on systemd, that was my other mail to the question of tilt! I replied to earlier. You are right in that I should have known better than to get into this thread. A bad case of https://xkcd.com/386/ :-) Sorry, and now going to lurk-mode in earnest;-) Best Regards, Tobias On Sun, Aug 30, 2015 at 12:31 AM, Tobias Hunger wrote: > Hi Jaromil, > > On Sat, Aug 29, 2015 at 9:32 PM, Jaromil wrote: >>>Hi Rainer, do you know that you are feeding a troll ? >>>tobias.hun...@gmail.com appears to be a systemd developer > > I tend to send patches to open source projects that I get into contact > with. It is a really annoying habit I picked up in that free software > scene you might have heard of before. > > Yes, I have a hand full of tiny patches in systemd. Got a few more in > firefox and a couple other places, but would still not call myself a > mozilla developer. > >> if that is even a legitimate account, > > Yes. > > Did we get to the point where we need fake emails to follow up on free > software projects now? > >> is he getting paid for his time spent here? > > Sure, I am going to buy a new villa with the millions of euros I make > following a bunch of nerds doing yet another Linux distribution! Can > you recommend a nice place with enough room to mount a 16t mind > control ray on the roof? > >> I find it disturbing. systemd has plenty of avenues for propaganda in Linux >> related tradeshows and some very insisting, annoying and intrusive sorts of >> door-to-door sales people like Tobias. > > Seriously? I was answering to a direct technical question on systemd > raised on this very list. > >> perhaps it should be more clear that they are not welcome here, especially >> if they look for another space to lecture on how systemd works better than >> other "lesser init systems". > > I personally try to understand code that I am going to remove from the > projects I work on and for that reason I am happy to have some people > around that actually are willing and able to answer questions on that > code. > > If you prefer to muck around in the dark here, then I will heed that > wish and lurk only. > > Best Regards, > Tobias ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Hi Jaromil, On Sat, Aug 29, 2015 at 9:32 PM, Jaromil wrote: >>Hi Rainer, do you know that you are feeding a troll ? >>tobias.hun...@gmail.com appears to be a systemd developer I tend to send patches to open source projects that I get into contact with. It is a really annoying habit I picked up in that free software scene you might have heard of before. Yes, I have a hand full of tiny patches in systemd. Got a few more in firefox and a couple other places, but would still not call myself a mozilla developer. > if that is even a legitimate account, Yes. Did we get to the point where we need fake emails to follow up on free software projects now? > is he getting paid for his time spent here? Sure, I am going to buy a new villa with the millions of euros I make following a bunch of nerds doing yet another Linux distribution! Can you recommend a nice place with enough room to mount a 16t mind control ray on the roof? > I find it disturbing. systemd has plenty of avenues for propaganda in Linux > related tradeshows and some very insisting, annoying and intrusive sorts of > door-to-door sales people like Tobias. Seriously? I was answering to a direct technical question on systemd raised on this very list. > perhaps it should be more clear that they are not welcome here, especially if > they look for another space to lecture on how systemd works better than other > "lesser init systems". I personally try to understand code that I am going to remove from the projects I work on and for that reason I am happy to have some people around that actually are willing and able to answer questions on that code. If you prefer to muck around in the dark here, then I will heed that wish and lurk only. Best Regards, Tobias ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, 29 Aug 2015 15:20:01 -0500 Nate Bargmann wrote: > * On 2015 29 Aug 10:15 -0500, poitr pogo wrote: > > So let them build desktop oriented linux, and let us focus on the > > server oriented version. > > I'll add my voice to the chorus objecting to the idea that removal of > systemd is for servers only. So will I. Bad architecture is something I don't want on my possessions, whether server, desktop or sewing machine. Because unlike the chumps shelling out money for Red Hat support, I fix my own stuff. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, 29 Aug 2015 20:34:29 +0200 Laurent Bercot wrote: > Oh, I'm not blaming some abstract entity called "su". When I say > that su is not good (anymore), it's obviously on us. > There's a reason why I have written programs performing privilege > gain without bit s executables. ;) > Now let me ask you this Laurent. Your programs performing privilege gain without bit s executables: Did you tie them into the init system? Did you tie them into (not allow them to be called from, but tie them into) lots of other executables? Does the system break if someone replaces your execuables with (almost) equivalents? Didn't think so, and that's the whole point. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, 29 Aug 2015 17:45:01 +0200 Tobias Hunger wrote: > Hi Rainer, > > On Sat, Aug 29, 2015 at 3:48 PM, Rainer Weikusat > wrote: > > If not, then not. But > > the reason why su is only of limited usefulness is not because the > > hardcoded policy isn't complicated enough to include > > > > $random_thing_someone_called_lennart_also_wants > > > > for every conceivable value of the variable but because it has a > > hardcoded policy at all and the solution is not "implement another, > > random environment munger more to tastes of ..." but split it apart: > > That is exactly what systemd implemented: The uid/gid gets changed and > then you get exactly the same environment that gets set up for you > during login. Nothing is merged, no munching of anything is happening > anymore. [snip] > > So you have to worry about users sneaking in a "muncher" (e.g. by > manipulating PATH, LD_PRELOAD or whatnot) that will be run with the > new uid/gid and can attack the user and system to its hearts content. > Very bad idea. Some things are not as dynamic as they could be for a > reason. Regardless of all this theoretical stuff, su works beautifully in some peoples' use cases. If the Redhats want to make a parallel thing, fine. But don't contaminate su, and don't fix it so programs that used to work with su now only work with PoetterPermissions or whatever it's called. It's called halloween code for a reason. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, 29 Aug 2015 08:22:23 -0700 Go Linux wrote: > On Sat, 8/29/15, poitr pogo wrote: > > Subject: Re: [DNG] The show goes on: “su” command replacement > merged into systemd on Fedora Rawhide To: "dng" > Date: Saturday, August 29, 2015, 10:14 AM > > > > > So let them build desktop oriented linux, and let us focus on the > > server oriented version. > > > > > > G . . . How about a systemd-free Linux that can be the base for > server or desktop use . . . > > golinux Yeah, that isn't a problem, and shouldn't be a problem. Interestingly, in my LUG, the most pro-systemd guys are the mega-metal admins administering hundreds of boxes with hundreds of Docker containers. These guys are telling me systemd is necessary to efficiently manage the Dockers. Yeah, whatever, give me the budget Redhat gave the systemd cabal, so I can hire good programmers, and I'll make it work efficiently without breaking Linux and entangling everything. Back to sane desktop linux, basically, we could run a panel with Openbox, and if either Openbox or the panel get poetterized, we can fork. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, 29 Aug 2015 16:38:33 +0200 Laurent Bercot wrote: > On 29/08/2015 14:43, Rainer Weikusat wrote: > > 'su' is not a concept, it's a program. > >Okay, let's clarify. > A program is the implementation of an idea. The idea is often > unwritten or unspoken, or forgotten, and people will only refer > to the implementation; but good design always starts with the idea, > the concept, of what the program is supposed to do. > > When Lennart says "su is a broken concept", he's saying "the > concept behind the su program is not clear or well-defined, and > it was not a good idea to implement it"; and I agree with that. > (Then he naturally branches onto his NIH obsession and decides > that UNIX is bad and systemd must reinvent everything, which I > obviously disagree with.) > > As you're saying, the correct design is to separate the tasks > that the su program accomplishes, if one doesn't need a full- > environment root shell. > But if a full-environment root shell is needed, logging in as > root works. That's exactly what the "login" _concept_ is. The point is this: If su is a broken concept, write a substitute. Publicize the substitute. Proclaim from the town square that su is depricated. But leave su functional for those who make the choice to use it! SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, 29 Aug 2015 15:03:00 +0100 Edward Bartolo wrote: > This is heartbreaking rather than a show. Replace everything that used > to work reliably for so many years with what clueless beginners want! > > The plague has come, but not in the form of a deadly bacterium, but in > the new trend of, "sacrificing function for fashion". Speaking of which: https://www.youtube.com/watch?v=TQAR-nx4w88 I especially like the line: = Eagerly persuing all the latest fads and trends = SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] BUG: zombies increase while running netman
Running "ps -e" while netman runs for a some time results in zombies as follows: edbarx@edbarx-pc:~$ ps -e PID TTY TIME CMD 1 ?00:00:00 init 2 ?00:00:00 kthreadd 3 ?00:00:05 ksoftirqd/0 5 ?00:00:00 kworker/0:0H 7 ?00:00:12 rcu_sched 8 ?00:00:00 rcu_bh 9 ?00:00:00 migration/0 10 ?00:00:00 watchdog/0 11 ?00:00:00 watchdog/1 12 ?00:00:00 migration/1 13 ?00:00:06 ksoftirqd/1 15 ?00:00:00 kworker/1:0H 16 ?00:00:00 khelper 17 ?00:00:00 kdevtmpfs 18 ?00:00:00 netns 19 ?00:00:00 khungtaskd 20 ?00:00:00 writeback 21 ?00:00:00 ksmd 22 ?00:00:00 khugepaged 23 ?00:00:00 crypto 24 ?00:00:00 kintegrityd 25 ?00:00:00 bioset 26 ?00:00:00 kblockd 29 ?00:00:00 kswapd0 30 ?00:00:00 fsnotify_mark 36 ?00:00:00 kthrotld 37 ?00:00:00 ipv6_addrconf 39 ?00:00:00 deferwq 75 ?00:00:00 khubd 76 ?00:00:00 acpi_thermal_pm 77 ?00:00:00 ata_sff 78 ?00:00:00 scsi_eh_0 79 ?00:00:00 scsi_tmf_0 80 ?00:00:00 scsi_eh_1 81 ?00:00:00 scsi_tmf_1 85 ?00:00:00 scsi_eh_2 86 ?00:00:00 scsi_tmf_2 87 ?00:00:00 scsi_eh_3 88 ?00:00:00 scsi_tmf_3 95 ?00:00:00 kworker/1:1H 96 ?00:00:00 kworker/0:1H 118 ?00:00:00 jbd2/sda9-8 119 ?00:00:00 ext4-rsv-conver 309 ?00:00:00 udevd 359 ?00:00:00 hd-audio0 368 ?00:00:00 kpsmoused 389 ?00:00:00 cfg80211 1277 ?00:00:00 rpcbind 1305 ?00:00:00 rpc.statd 1310 ?00:00:00 rpciod 1312 ?00:00:00 nfsiod 1319 ?00:00:00 rpc.idmapd 1555 ?00:00:00 rsyslogd 1597 ?00:00:00 atd 1643 ?00:00:00 acpid 1665 ?00:00:00 cron 1726 ?00:00:00 dbus-daemon 1919 ?00:00:05 xchat 1965 ?00:00:00 exim4 1985 ?00:00:00 slim 2011 tty7 00:09:19 Xorg 2012 tty1 00:00:00 getty 2013 tty2 00:00:00 getty 2014 tty3 00:00:00 getty 2015 tty4 00:00:00 getty 2016 tty5 00:00:00 getty 2017 tty6 00:00:00 getty 2030 ?00:00:00 kauditd 2032 ?00:00:00 console-kit-dae 2099 ?00:00:00 polkitd 2110 ?00:00:00 sh 2162 ?00:00:00 ssh-agent 2165 ?00:00:00 dbus-launch 2166 ?00:00:00 dbus-daemon 2176 ?00:00:00 xfce4-session 2178 ?00:00:00 xfconfd 2182 ?00:00:00 gpg-agent 2183 ?00:00:02 xfwm4 2185 ?00:00:03 xfce4-panel 2187 ?00:00:00 xfsettingsd 2189 ?00:00:00 syndaemon 2191 ?00:00:00 xfdesktop 2195 ?00:00:00 xfce4-power-man 2199 ?00:00:01 xscreensaver 2202 ?00:00:00 xfce4-power-man 2203 ?00:00:00 xfce4-volumed 2208 ?00:00:00 upowerd 2210 ?00:00:00 panel-6-systray 2213 ?00:00:00 panel-2-actions 2264 ?00:00:45 netman 2271 ?00:00:00 backend 2272 ?00:00:00 cat 2280 ?00:00:00 ifup 2416 ?00:00:00 at-spi-bus-laun 2743 ?00:00:00 kworker/1:1 3809 ?00:00:00 kworker/0:1 4106 ?00:00:00 kworker/u8:0 4595 ?00:00:00 kworker/1:0 4834 ?00:00:00 kworker/u8:2 5130 ?00:00:00 kworker/0:2 5207 ?00:00:00 kworker/1:2 5732 ?00:00:00 xfce4-terminal 5736 ?00:00:00 gnome-pty-helpe 5737 pts/000:00:00 bash 5755 ?00:00:00 ps 5756 pts/000:00:00 ps 7389 ?00:00:00 ifdown 16124 ?00:00:00 ifup 16135 ?00:00:00 wpa_supplicant 16189 ?00:00:00 dhclient 18393 ?00:00:28 medit 26622 ?00:00:00 backend 26853 ?00:00:00 backend 26886 ?00:00:00 backend 26908 ?00:00:00 backend 31536 ?00:08:11 iceweasel I found this suggestion to get rid of zombies. The link is this: https://www.daniweb.com/software-development/cpp/threads/364407/handling-sigchld-to-prevent-zombie-processes What do you suggest? Edward. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
* On 2015 29 Aug 10:15 -0500, poitr pogo wrote: > So let them build desktop oriented linux, and let us focus on the > server oriented version. I'll add my voice to the chorus objecting to the idea that removal of systemd is for servers only. My first use of Linux (Slackware specifically) was as a desktop system 19 years ago. I have some Raspberry Pi computers doing some dedicated tasks (not certain if they are "servers" but they are headless). Right now with Debian Jessie systemd must be installed to make the desktop anywhere near functional, but that is a result of packaging decisions by Debian and not any intrinsic need for systemd on a desktop system at this time. I am looking forward to being able to install pulseaudio and lightdm without a dependency on systemd. I had to install all of them last night to get all of my amateur radio software to play together again. systemd brought in 53 MB of cruft (after installation) I didn't exactly need. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] strange characters when using 'examine' in aptitude
On Sat, Aug 29, 2015 at 03:01:26PM +0100, Dave Turner wrote: > On 29/08/15 01:37, Isaac Dunham wrote: > >On Fri, Aug 28, 2015 at 08:45:51AM +0100, Dave Turner wrote: > >>I run devuan unstable 'ceres' on my Toshiba laptop and my iMac. > >>It all works with just a bit of weirdness. > >>I use apt-get update apt-get upgrade and then use aptitude to fix those > >>upgrades that get held back for various reasons. > >>Whenever I highlight one of the held back packages and press 'e' to examine > >>the various possibilities the names of the packages to be removed or > >>installed are mangled with block characters and/or assorted characters from > >>other non-Latin1 character sets. Upside down question marks etc. > >> > >>Any ideas what is going on? > >What's your terminal? > >Are ncurses-term and ncurses-base installed? > >What does this command output: > > env |grep -e TERM -e LC -e LANG -e LOCALE > > > >I ask these because I'm *guessing* that it's one of the following: > >-you don't have TERM pointing to an installed & correct termcap/terminfo > >database > >-your localization is screwy > >-you have the wrong fonts (not likely unless it's a plain xlib terminal) > ncurses-term and ncurses-base are installed. > the output of > > env |grep -e TERM -e LC -e LANG -e LOCALE > > TERM=xterm > LANG=en_GB.UTF-8 > LANGUAGE=en_GB:en > COLORTERM=xfce4-terminal Maybe try running aptitude with TERM=xfce and COLORTERM=xfce or go ls /usr/share/terminfo/x/xfce4-terminal? (Here, terminfo only has "xfce".) Check that you're using a UTF8 font? These are my bestt guesses; if they don't work, I'd be stumped. HTH, Isaac PS: A: Because it messes up the reading order. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On August 29, 2015 6:54:44 PM GMT+02:00, Rowland Penny wrote: >Hi Rainer, do you know that you are feeding a troll ? >tobias.hun...@gmail.com appears to be a systemd developer if that is even a legitimate account, is he getting paid for his time spent here? I find it disturbing. systemd has plenty of avenues for propaganda in Linux related tradeshows and some very insisting, annoying and intrusive sorts of door-to-door sales people like Tobias. perhaps it should be more clear that they are not welcome here, especially if they look for another space to lecture on how systemd works better than other "lesser init systems". ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Let's package an Alpha version of 'netman'.
Dear Devuan developers and users, Since I am already using netman as my network manager in XFCE4, let us not 'waste' more time and package an ALPHA version, so that users of Devuan would be able to use it. I am attaching a howto, so that whoever packages it would know what to do. I chose /usr/bin/netman as an installation directory, and have it installed that way on this same computer. Edward packagers.readme Description: Binary data ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 29/08/2015 20:10, KatolaZ wrote: Well, I wouldn't say that su is a broken concept on its own. In assessing the quality of ideas and software one should always take into account the motivations which led to a certain solution. su appeared in AT&T Unix Version 1: Yes. However, Unix has evolved in 40 years, sometimes in a good way, sometimes in a not so good way. And piling on more functionality into su wasn't exactly the best idea: from a simple privilege-gaining tool, it mutated into something between what it was and a complete login - it lost the clarity of concept it had at first. The fact that we have gone a bit further than that with su, asking it to do things it was not conceived for, is our problem, not su's one. Oh, I'm not blaming some abstract entity called "su". When I say that su is not good (anymore), it's obviously on us. There's a reason why I have written programs performing privilege gain without bit s executables. ;) -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, Aug 29, 2015 at 04:38:33PM +0200, Laurent Bercot wrote: > On 29/08/2015 14:43, Rainer Weikusat wrote: > >'su' is not a concept, it's a program. > > Okay, let's clarify. > A program is the implementation of an idea. The idea is often > unwritten or unspoken, or forgotten, and people will only refer > to the implementation; but good design always starts with the idea, > the concept, of what the program is supposed to do. > > When Lennart says "su is a broken concept", he's saying "the > concept behind the su program is not clear or well-defined, and > it was not a good idea to implement it"; and I agree with that. > (Then he naturally branches onto his NIH obsession and decides > that UNIX is bad and systemd must reinvent everything, which I > obviously disagree with.) Well, I wouldn't say that su is a broken concept on its own. In assessing the quality of ideas and software one should always take into account the motivations which led to a certain solution. su appeared in AT&T Unix Version 1: http://man.cat-v.org/unix-1st/1/su and by reading the original manpage one realises that the rationale for having such a command was quite understandable and sound: if you alredy have a working session (and you are behind a teletype), and you want to execute a few commands as root, there is no reason to logout, login as root, execute the command, logout from root, login again on your account. Nowadays it might seem to somebody a broken concept, but that's just because they have in mind a different use case. And they want to do more than su with something like su. After all, pens did not become a "broken concept" when typewriters were invented... The fact that we have gone a bit further than that with su, asking it to do things it was not conceived for, is our problem, not su's one. The "solution" proposed by systemd is (as usual) against the original principles behind unix, since from the interface: $ machinectl shell (16 characters) $ su (2 characters) Yes, they will say that with the former command you can do better, smarter and more marvellous things, but if you just need to become root to install one package, you would probably be better off with su anyway. HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 29/08/15 17:50, Rainer Weikusat wrote:
Tobias Hunger writes:
On Sat, Aug 29, 2015 at 3:48 PM, Rainer Weikusat
wrote:
'su' is a somewhat generic setuid-0 program: It changes the uid and the
gids associated with itself to the ones for a certain user and then
executes a shell. In addition to that, it contains another "random
environment munger" with features someone happend to consider useful for
the su use cases he envisioned. If this happens to be what enables
someone else to achieve something he wanted to achieve, 'su' can
obviously be used for that. If not, then not. But the reason why su is
only of limited usefulness is not because the hardcoded policy isn't
complicated enough to include
$random_thing_someone_called_lennart_also_wants
for every conceivable value of the variable but because it has a
hardcoded policy at all and the solution is not "implement another,
random environment munger more to tastes of ..." but split it apart:
That is exactly what systemd implemented:
No, that's not "exactly what systemd implemented", as
The uid/gid gets changed and then you get exactly the same environment
that gets set up for you during login.
and I wasn't writing about emulating/ simulating a "login environment"
(BTW, what's that?) for the sake of doing so. Pretty much the opposite,
actually: Instead of a "new and improved" hard-coded policy someone
associated with the 'shadow password suite' happened to dream up, get
rid of the policy altogether.
Have a program which changes uids and gids and executes another
program. Another program for the become root via setuid and execute
... part. And a third program (or any number of such programs) to
perform other modifications of the execution environment.
So you have to worry about users sneaking in a "muncher" (e.g. by
manipulating PATH, LD_PRELOAD or whatnot) that will be run with the
new uid/gid and can attack the user and system to its hearts content.
*If* manipulating the environment (here supposed to refer to "what
environ points to") in a certain way is considered necessary, programs
doing that can be employed, eg (I didn't need these two particular tools
so far so this is sort-of a demo):
--- kill-env.c -
#include
#include
extern char **environ;
int main(int argc, char **argv)
{
environ = NULL;
execv(argv[1], argv + 1);
perror("execv");
return 1;
}
set-path.c
#include
#include
#include
int main(int argc, char **argv)
{
int rc;
rc = setenv("PATH", argv[1], 1);
if (rc == -1) {
perror("setenv");
exit(1);
}
execvp(argv[2], argv + 2);
perror("execv");
return 1;
}
Assuming both programs have been compiled into binaries named in the
indicated way and reside in the current directory, they could be used
like this:
[rw@doppelsaurus]/tmp#./kill-env ./set-path /usr/bin env
PATH=/usr/bin
A real 'environment initialization program' should probably support
reading the environment from a file and another which interprets some of
its arguments as name-value pairs could be useful, too. A complete command
could then look like this:
/bin/replace-env /etc/daemon-env set-env USER blafasel TERM vt100 -- env
NB: This approach is not intended to be convenient for interactive use, it
should just also enable that. It's supposed to enable creating complex
'process startup commands' by combining simple parts.
NB^2: I'm also absolutely not concerned with "fork and exec overhead"
unless there's an actual use case I need to handle where it demonstrably
makes a relevant difference.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Hi Rainer, do you know that you are feeding a troll ?
tobias.hun...@gmail.com appears to be a systemd developer
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Tobias Hunger writes:
> On Sat, Aug 29, 2015 at 3:48 PM, Rainer Weikusat
> wrote:
>> 'su' is a somewhat generic setuid-0 program: It changes the uid and the
>> gids associated with itself to the ones for a certain user and then
>> executes a shell. In addition to that, it contains another "random
>> environment munger" with features someone happend to consider useful for
>> the su use cases he envisioned. If this happens to be what enables
>> someone else to achieve something he wanted to achieve, 'su' can
>> obviously be used for that. If not, then not. But the reason why su is
>> only of limited usefulness is not because the hardcoded policy isn't
>> complicated enough to include
>>
>> $random_thing_someone_called_lennart_also_wants
>>
>> for every conceivable value of the variable but because it has a
>> hardcoded policy at all and the solution is not "implement another,
>> random environment munger more to tastes of ..." but split it apart:
>
> That is exactly what systemd implemented:
No, that's not "exactly what systemd implemented", as
> The uid/gid gets changed and then you get exactly the same environment
> that gets set up for you during login.
and I wasn't writing about emulating/ simulating a "login environment"
(BTW, what's that?) for the sake of doing so. Pretty much the opposite,
actually: Instead of a "new and improved" hard-coded policy someone
associated with the 'shadow password suite' happened to dream up, get
rid of the policy altogether.
>> Have a program which changes uids and gids and executes another
>> program. Another program for the become root via setuid and execute
>> ... part. And a third program (or any number of such programs) to
>> perform other modifications of the execution environment.
>
> So you have to worry about users sneaking in a "muncher" (e.g. by
> manipulating PATH, LD_PRELOAD or whatnot) that will be run with the
> new uid/gid and can attack the user and system to its hearts content.
*If* manipulating the environment (here supposed to refer to "what
environ points to") in a certain way is considered necessary, programs
doing that can be employed, eg (I didn't need these two particular tools
so far so this is sort-of a demo):
--- kill-env.c -
#include
#include
extern char **environ;
int main(int argc, char **argv)
{
environ = NULL;
execv(argv[1], argv + 1);
perror("execv");
return 1;
}
set-path.c
#include
#include
#include
int main(int argc, char **argv)
{
int rc;
rc = setenv("PATH", argv[1], 1);
if (rc == -1) {
perror("setenv");
exit(1);
}
execvp(argv[2], argv + 2);
perror("execv");
return 1;
}
Assuming both programs have been compiled into binaries named in the
indicated way and reside in the current directory, they could be used
like this:
[rw@doppelsaurus]/tmp#./kill-env ./set-path /usr/bin env
PATH=/usr/bin
A real 'environment initialization program' should probably support
reading the environment from a file and another which interprets some of
its arguments as name-value pairs could be useful, too. A complete command
could then look like this:
/bin/replace-env /etc/daemon-env set-env USER blafasel TERM vt100 -- env
NB: This approach is not intended to be convenient for interactive use, it
should just also enable that. It's supposed to enable creating complex
'process startup commands' by combining simple parts.
NB^2: I'm also absolutely not concerned with "fork and exec overhead"
unless there's an actual use case I need to handle where it demonstrably
makes a relevant difference.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 08/28/2015 11:00 AM, Michael Bütow wrote: > Article here: > > https://tlhp.cf/lennart-poettering-su/ > > I for one look forward to not having any of this madness one day when I > transition completely to Devuan! > su --> machinectl shell Obviously, too many people were getting root too easily. This should slow them down. --setenv="SYSTEMD_TEST=777" That's a slightly disturbing choice for an example value, given the context. What was on his mind? fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Hi Rainer, On Sat, Aug 29, 2015 at 3:48 PM, Rainer Weikusat wrote: > 'su' is a somewhat generic setuid-0 program: It changes the uid and the > gids associated with itself to the ones for a certain user and then > executes a shell. In addition to that, it contains another "random > environment munger" with features someone happend to consider useful for > the su use cases he envisioned. If this happens to be what enables > someone else to achieve something he wanted to achieve, 'su' can > obviously be used for that. If not, then not. But the reason why su is > only of limited usefulness is not because the hardcoded policy isn't > complicated enough to include > > $random_thing_someone_called_lennart_also_wants > > for every conceivable value of the variable but because it has a > hardcoded policy at all and the solution is not "implement another, > random environment munger more to tastes of ..." but split it apart: That is exactly what systemd implemented: The uid/gid gets changed and then you get exactly the same environment that gets set up for you during login. Nothing is merged, no munching of anything is happening anymore. > Have a program which changes uids and gids and executes another > program. Another program for the become root via setuid and execute > ... part. And a third program (or any number of such programs) to > perform other modifications of the execution environment. So you have to worry about users sneaking in a "muncher" (e.g. by manipulating PATH, LD_PRELOAD or whatnot) that will be run with the new uid/gid and can attack the user and system to its hearts content. Very bad idea. Some things are not as dynamic as they could be for a reason. Best Regards, Tobias ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, Aug 29, 2015 at 05:14:50PM +0200, poitr pogo wrote: ... > So let them build desktop oriented linux, and let us focus on the > server oriented version. I'm completely happy with devuan as a desktop system. Plaeas don't abandon the desktop. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
It's the NSA. Sneaking binary logs into linux and so forth. Taking over the system. Redhat's corporate and just down the pike from Fort Meade. Lennart's a mole. Seems obvious to me, anyway. On 2015-08-29 22:14, poitr pogo wrote: Hi, On Fri, Aug 28, 2015 at 5:00 PM, Michael Bütow wrote: Article here: https://tlhp.cf/lennart-poettering-su/ I for one look forward to not having any of this madness one day when I transition completely to Devuan! This is rather good news, as this is extension to systemd not to su. As systemd is it's own echosystem of some kind, with all that new session/terminal/process management using cgroups, etc. it is natural that it needs su-like feature, which will handle all this systemd internals properly. IMHO systemd is some kind of an android like layer between kernel and desktop applications, providing it's own api/libraties/sdk. I bet gnome will became a GUI part of systemd at some point. With API allowing building linux based applications using html5 :D It would be perfect if it develops own tools (like this one) instead of modifying the existing ones. So let them build desktop oriented linux, and let us focus on the server oriented version. regards piotr ___ 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
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, 8/29/15, poitr pogo wrote: Subject: Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide To: "dng" Date: Saturday, August 29, 2015, 10:14 AM > > So let them build desktop oriented linux, and let us focus on the > server oriented version. > G . . . How about a systemd-free Linux that can be the base for server or desktop use . . . golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Hi, On Fri, Aug 28, 2015 at 5:00 PM, Michael Bütow wrote: > Article here: > > https://tlhp.cf/lennart-poettering-su/ > > I for one look forward to not having any of this madness one day when I > transition completely to Devuan! > This is rather good news, as this is extension to systemd not to su. As systemd is it's own echosystem of some kind, with all that new session/terminal/process management using cgroups, etc. it is natural that it needs su-like feature, which will handle all this systemd internals properly. IMHO systemd is some kind of an android like layer between kernel and desktop applications, providing it's own api/libraties/sdk. I bet gnome will became a GUI part of systemd at some point. With API allowing building linux based applications using html5 :D It would be perfect if it develops own tools (like this one) instead of modifying the existing ones. So let them build desktop oriented linux, and let us focus on the server oriented version. regards piotr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
As it is netman works. I think, it can be packaged and made useful for some people, but users have to be warned that automated connections are not yet implemented. I am realising that 'connect on request' is more attractive to my preferences, but I will provide the magical button to automatically select a wifi and to connect to it. On 29/08/2015, Edward Bartolo wrote: > I am thinking about adding yet another operation to backend.c to > attempt automatic connection with a wifi. > > The algorithm can work as follows: > a) read all filenames from /etc/network/wifi > b) scan for wifi essids and strengths > c) sort wifi essids according to strength, starting from the strongest > d) iterate wifi as follows: > i) if wifi essid is configured attempt connection > ii) if wifi essid is not configured skip it > e) if all wifi essids are exhausted, prompt the user or change colour > of the GUI from default to some other colour to draw the user's > attention without being a nuisance. > > Should I modify the existing functions that already work, to be able > to use them in the above algorithm, or write a new function which does > not use any services from the previous functions? Including all > functionality in new function adds more code but avoids potential > breakage of already tested functions. > >> >> On 29/08/2015, Go Linux wrote: >>> >>> Congrats on getting git to play nice! :) >>> >>> >>> On Fri, 8/28/15, Edward Bartolo wrote: >>> >>> Subject: Re: [DNG] netman GIT project >>> To: "Steve Litt" >>> Cc: "dng" >>> Date: Friday, August 28, 2015, 2:35 PM >>> >>> But now, it looks like I succeeded with this commit: >>> >>> --- >>> commit 799957ad4007aa8e272d18508e59f33903b7c44d >>> Author: edbarx >>> Date: Fri Aug 28 19:43:42 2015 +0100 >>> >>> GUI frontend: now supports wireless and wired connections. Code >>> added to protect the defaults in /etc/network/interfaces. >>> >>> Backend C code: add another function connect_wired() and another >>> operation to backend code number 9. This is to connect a wired >>> connection. Both the frontend and the backend now refuse to disconnect >>> multiple connections. netman is now designed to handle one connection >>> at a time. Code has been added to minimize situations where multiple >>> instances of the backend are running. >>> >>> >> > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 29/08/2015 14:43, Rainer Weikusat wrote: 'su' is not a concept, it's a program. Okay, let's clarify. A program is the implementation of an idea. The idea is often unwritten or unspoken, or forgotten, and people will only refer to the implementation; but good design always starts with the idea, the concept, of what the program is supposed to do. When Lennart says "su is a broken concept", he's saying "the concept behind the su program is not clear or well-defined, and it was not a good idea to implement it"; and I agree with that. (Then he naturally branches onto his NIH obsession and decides that UNIX is bad and systemd must reinvent everything, which I obviously disagree with.) As you're saying, the correct design is to separate the tasks that the su program accomplishes, if one doesn't need a full- environment root shell. But if a full-environment root shell is needed, logging in as root works. That's exactly what the "login" _concept_ is. Now, is 1. Build systems suck and git isn't exactly the greatest tool on the planet for working with more than one source tree, so lets add the code we want to write to systemd 2. goto 1 a concept? Of course it is! I'm surprised systemd-versioncontrol isn't a thing yet. XD -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On Sat, 29 Aug 2015 15:03:00 +0100 Edward Bartolo wrote: > The plague has come, but not in the form of a deadly bacterium, but in > the new trend of, "sacrificing function for fashion". Or the megalomaniac "We are Systemd of Borg, resistance is futile..." Cheers, Ron. -- One should always be in love. That is the reason one should never marry. -- Oscar Wilde -- http://www.olgiati-in-paraguay.org -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] does systemd set runlevel 0 in utmp on shutdown?
On 08/29/2015 01:02 PM, Tobias Hunger wrote: 8...] The init system should stop such services and you should fix the init system and not add clutches all over the place to work around its limitations. Best Regards, Tobias Hi, I'm not 100% sure what you want, but I think I have no time for it. :-) Thanks anyway. Best regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
This is heartbreaking rather than a show. Replace everything that used to work reliably for so many years with what clueless beginners want! The plague has come, but not in the form of a deadly bacterium, but in the new trend of, "sacrificing function for fashion". On 29/08/2015, Rainer Weikusat wrote: > Matteo Panella writes: >> On 28/08/2015 17:32, Laurent Bercot wrote: >>> On 28/08/2015 17:00, Michael Bütow wrote: https://tlhp.cf/lennart-poettering-su/ >>> >>> The thing is, he's not entirely wrong: su *is*, really, a >>> broken concept. >> >> On a desktop system with current constraints (XDG env vars, X11 >> sockets...) I'd agree, but that's hardly su's fault. >> >> On a server, tough, it just does its job nicely (unless you need strict >> audit of root-level actions, in which case sudo with a MAC system should >> be your starting point). > > 'su' is a somewhat generic setuid-0 program: It changes the uid and the > gids associated with itself to the ones for a certain user and then > executes a shell. In addition to that, it contains another "random > environment munger" with features someone happend to consider useful for > the su use cases he envisioned. If this happens to be what enables > someone else to achieve something he wanted to achieve, 'su' can > obviously be used for that. If not, then not. But the reason why su is > only of limited usefulness is not because the hardcoded policy isn't > complicated enough to include > > $random_thing_someone_called_lennart_also_wants > > for every conceivable value of the variable but because it has a > hardcoded policy at all and the solution is not "implement another, > random environment munger more to tastes of ..." but split it apart: > Have a program which changes uids and gids and executes another > program. Another program for the become root via setuid and execute > ... part. And a third program (or any number of such programs) to > perform other modifications of the execution environment. > ___ > 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
Re: [DNG] strange characters when using 'examine' in aptitude
Isaac, ncurses-term and ncurses-base are installed. the output of env |grep -e TERM -e LC -e LANG -e LOCALE is TERM=xterm LANG=en_GB.UTF-8 LANGUAGE=en_GB:en COLORTERM=xfce4-terminal my laptop is now only running xfce4, and slim is gone because I prefer to login into a terminal and then startx when I want to / need to. DaveT On 29/08/15 01:37, Isaac Dunham wrote: On Fri, Aug 28, 2015 at 08:45:51AM +0100, Dave Turner wrote: I run devuan unstable 'ceres' on my Toshiba laptop and my iMac. It all works with just a bit of weirdness. I use apt-get update apt-get upgrade and then use aptitude to fix those upgrades that get held back for various reasons. Whenever I highlight one of the held back packages and press 'e' to examine the various possibilities the names of the packages to be removed or installed are mangled with block characters and/or assorted characters from other non-Latin1 character sets. Upside down question marks etc. Any ideas what is going on? I am using the slim login manager and then depending on my mood fluxbox, xfce, or lumina - the new desktop from pc-bsd. What's your terminal? Are ncurses-term and ncurses-base installed? What does this command output: env |grep -e TERM -e LC -e LANG -e LOCALE I ask these because I'm *guessing* that it's one of the following: -you don't have TERM pointing to an installed & correct termcap/terminfo database -your localization is screwy -you have the wrong fonts (not likely unless it's a plain xlib terminal) HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] strange characters when using 'examine' in aptitude
Another step forward, apt-get dist-upgrade fixed two of the held-back packages. On 28/08/15 20:13, info at smallinnovations.nl wrote: I do not know a solution for this behavior but you do not need aptitude in this situation you can do apt-get dist-upgrade to fix those upgrades that get held back for various reasons. Date: Fri, 28 Aug 2015 08:45:51 +0100 From: Dave Turner To:dng@lists.dyne.org Subject: [DNG] strange characters when using 'examine' in aptitude Message-ID:<55e011af.6050...@barradas.free-online.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed I run devuan unstable 'ceres' on my Toshiba laptop and my iMac. It all works with just a bit of weirdness. I use apt-get update apt-get upgrade and then use aptitude to fix those upgrades that get held back for various reasons. Whenever I highlight one of the held back packages and press 'e' to examine the various possibilities the names of the packages to be removed or installed are mangled with block characters and/or assorted characters from other non-Latin1 character sets. Upside down question marks etc. Any ideas what is going on? I am using the slim login manager and then depending on my mood fluxbox, xfce, or lumina - the new desktop from pc-bsd. ___ 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
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Matteo Panella writes: > On 28/08/2015 17:32, Laurent Bercot wrote: >> On 28/08/2015 17:00, Michael Bütow wrote: >>> https://tlhp.cf/lennart-poettering-su/ >> >> The thing is, he's not entirely wrong: su *is*, really, a >> broken concept. > > On a desktop system with current constraints (XDG env vars, X11 > sockets...) I'd agree, but that's hardly su's fault. > > On a server, tough, it just does its job nicely (unless you need strict > audit of root-level actions, in which case sudo with a MAC system should > be your starting point). 'su' is a somewhat generic setuid-0 program: It changes the uid and the gids associated with itself to the ones for a certain user and then executes a shell. In addition to that, it contains another "random environment munger" with features someone happend to consider useful for the su use cases he envisioned. If this happens to be what enables someone else to achieve something he wanted to achieve, 'su' can obviously be used for that. If not, then not. But the reason why su is only of limited usefulness is not because the hardcoded policy isn't complicated enough to include $random_thing_someone_called_lennart_also_wants for every conceivable value of the variable but because it has a hardcoded policy at all and the solution is not "implement another, random environment munger more to tastes of ..." but split it apart: Have a program which changes uids and gids and executes another program. Another program for the become root via setuid and execute ... part. And a third program (or any number of such programs) to perform other modifications of the execution environment. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
I am thinking about adding yet another operation to backend.c to attempt automatic connection with a wifi. The algorithm can work as follows: a) read all filenames from /etc/network/wifi b) scan for wifi essids and strengths c) sort wifi essids according to strength, starting from the strongest d) iterate wifi as follows: i) if wifi essid is configured attempt connection ii) if wifi essid is not configured skip it e) if all wifi essids are exhausted, prompt the user or change colour of the GUI from default to some other colour to draw the user's attention without being a nuisance. Should I modify the existing functions that already work, to be able to use them in the above algorithm, or write a new function which does not use any services from the previous functions? Including all functionality in new function adds more code but avoids potential breakage of already tested functions. > > On 29/08/2015, Go Linux wrote: >> >> Congrats on getting git to play nice! :) >> >> >> On Fri, 8/28/15, Edward Bartolo wrote: >> >> Subject: Re: [DNG] netman GIT project >> To: "Steve Litt" >> Cc: "dng" >> Date: Friday, August 28, 2015, 2:35 PM >> >> But now, it looks like I succeeded with this commit: >> >> --- >> commit 799957ad4007aa8e272d18508e59f33903b7c44d >> Author: edbarx >> Date: Fri Aug 28 19:43:42 2015 +0100 >> >> GUI frontend: now supports wireless and wired connections. Code >> added to protect the defaults in /etc/network/interfaces. >> >> Backend C code: add another function connect_wired() and another >> operation to backend code number 9. This is to connect a wired >> connection. Both the frontend and the backend now refuse to disconnect >> multiple connections. netman is now designed to handle one connection >> at a time. Code has been added to minimize situations where multiple >> instances of the backend are running. >> >> > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] does systemd set runlevel 0 in utmp on shutdown?
"tilt!" writes: > I use xfce-session with nodm, a (very) lightweight display manager. > It essentially puts a user's x session into an endless loop. > > When shutting down the system via logout dialog (utilizing pm-utils), > at least on my installation (utilizing sysvinit), nodm fails to > recognize that the system is in shutdown and restarts xfce-session > after xfce-session has received SIGTERM from the shutdown procedure. > > I have fixed this behavior by letting nodm evaluate utmp to determine > if the current runlevel is 0, and if yes, not restart the x session. In the process monitor I've been using so far, this can be accomplished by sending a SIGTERM directly to the process monitor. It will then terminate the managed application (SIGTERM plus timeout followed by SIGKILL in case the application didn't terminate) and then terminate itself. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
On 28/08/2015 17:32, Laurent Bercot wrote: > On 28/08/2015 17:00, Michael Bütow wrote: >> https://tlhp.cf/lennart-poettering-su/ > > The thing is, he's not entirely wrong: su *is*, really, a > broken concept. On a desktop system with current constraints (XDG env vars, X11 sockets...) I'd agree, but that's hardly su's fault. On a server, tough, it just does its job nicely (unless you need strict audit of root-level actions, in which case sudo with a MAC system should be your starting point). So much noise (and security-critical code) for nothing. -- Matteo Panella signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Laurent Bercot writes: > On 28/08/2015 17:00, Michael Bütow wrote: >> https://tlhp.cf/lennart-poettering-su/ > > The thing is, he's not entirely wrong: su *is*, really, a > broken concept. 'su' is not a concept, it's a program. This means one can use it to accomplish what it was written to do. And one can't use it to accomplish what it doesn't support. If something su doesn't support has to be done, and there's no other reasonable way to accomplish it, code will need to be written to implement the desired behaviour. Now, is 1. Build systems suck and git isn't exactly the greatest tool on the planet for working with more than one source tree, so lets add the code we want to write to systemd 2. goto 1 a concept? [SCNR] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] does systemd set runlevel 0 in utmp on shutdown?
Am 29.08.2015 10:26 vorm. schrieb "tilt!" : > My wording was biased there. To put it in clear terms: > > I think it's wrong that nodm attempts to (re)start an interactive > X session when the system is already scheduled for shutdown. > > I find it wrong, because it is misleading the user into interactive use > of a system that can power off (or halt, or reboot) at any moment. > > What I am trying to do is to put a check into nodm that prevents > it from doing so. I got that. I just do not think such a test makes sense. The init system should stop such services and you should fix the init system and not add clutches all over the place to work around its limitations. Best Regards, Tobias ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirroring Devuan
Hi Hendrik,
I just started working on that. But just started.
The following script generates the pool and dists folders:
find ./DEBIAN -name "*.dsc" -exec reprepro --ask-passphrase -b . -V -C
main includedsc jessie {} \;
find ./DEBIAN -name "*.deb" -exec reprepro --ask-passphrase -b . -V -C
main includedeb jessie {} \;
find ./DEBIAN -name "*.udeb" -exec reprepro --ask-passphrase -b . -V -C
main includeudeb jessie {} \;
from the content of ./DEBIAN folder, searching all the 'deb', 'udeb' and
'dsc' located in it.
One of the issues arising is how to automatize the signing proccess, if
it is possible.
Aitor.
El 27/08/15 a las 16:36, Hendrik Boom escribió:
> On Tue, Aug 25, 2015 at 10:34:42PM +0200, k...@aspodata.se wrote:
>> > Jaromil:
>>> > > we haven't yet worked on the mirroring mechanism, but we will
>>> > >
>>> > > once done, there will be a script and it will be easy
>>> > > I guess it will be a sort of amprolla satellite process
>>> > > so that the mirror redirection will be handled by nextime's software
>> > ...
>> >
>> > I would be good if one could have a local mirror with just file://
>> > entries i sources.list.
>> >
>> > It would be a great overhead if I needed apache at.al. when accessing
>> > files on the local disk.
>> >
>> > ///
>> >
>> > According to amprolla/nginx/rewrites.conf:
>> >
>> > rewrite /merged/pool/DEVUAN/(.*) http://packages.devuan.org/devuan/pool/$1;
>> > rewrite /merged/pool/DEBIAN/(.*) http://http.debian.net/debian/pool/$1;
>> > rewrite /merged/pool/MARILLAT/(.*) http://www.deb-multimedia.org/pool/$1;
>> > rewrite /merged/dists/(.*)/main/(installer-.*)/(.*)
>> > /devuan/dists/$1/main/$2/$3;
>> >
>> > I guess that this means that if the file is in devouan, use it,
>> > else use the debian one etc. That could be handled by using the
>> > right order in sources.list something in preferences.
>> > So if I have a copy of http://packages.devuan.org/devuan/ and
>> > a debian mirror, all I need is to prioritize them, am I right ?
> If you carefully order the sources.list entries,
> might there wtill be a problem if the debian package is slightly more
> up-to-date than the devuan one?
>
> -- hendrik
>
>> >
>> > Regards,
>> > /Karl Hammar
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] does systemd set runlevel 0 in utmp on shutdown?
Hi Tobias, On 08/29/2015 09:50 AM, Tobias Hunger wrote: > [...] > >>> I do not think you would need it anyway as systemd will stop the display >>> manager all by itself. >> >> Given the unclarity I tried to express in my previous questions, i admit >> that i am currently not too confident about that. Just to be on the safe >> side: > > Giving the clean way forward a try before heading down into a rabbit hole of > hacks (as apparently required by lesser init systems) seems worthwhile to me. > Especially considering that you probably do not care for systemd support > anyway. [...] My wording was biased there. To put it in clear terms: I think it's wrong that nodm attempts to (re)start an interactive X session when the system is already scheduled for shutdown. I find it wrong, because it is misleading the user into interactive use of a system that can power off (or halt, or reboot) at any moment. What I am trying to do is to put a check into nodm that prevents it from doing so. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] does systemd set runlevel 0 in utmp on shutdown?
Hi tilt!, Am 29.08.2015 07:53 schrieb "tilt!" : > thanks a lot for these hints! Please understand the following questions not > directed specifically to you, it's just that I am not very much into systemd, > and i appreciate every piece of clarification a lot. I post this here, because > this is one forum I know that cares about portability between *different* init > systems, and that's just what i would like to ensure for my nodm patch before > proposing it anywhere. Then test it on a couple of systemd systems. > That makes things difficult: With systemd 217 or later installed, > > (1) if utmp is there (it's in POSIX), but the utmp support (being optional) > is not there, will utmp simply remain not updated? My *guess* is that the distribution packaging needs to remove the file. Of they don't (and the system is stateful, which by far the most are), then systemd won't care about that file one way or the other and leave it unchanged. My arch Linux box still has the systemd-update-utmp.service enabled, so no idea. > (2) If the answer to (1) was "yes" then, how to determine if I am dealing with > an utmp that is not actually being maintained but just remains there as sort of > a compatibility placeholder (again, it's in POSIX)? Check for installed systemd > and its version being >= 217? The systemd version is *not* a good test, considering that (at least) arch still has that file in systemd 224. You could check for the update-utmp unit being active if you really cared. > (3) In the light of questions (1) and (2), does systemd care about POSIX at all? My understanding is: Only where it makes sense. Utmp is a binary file anyway and should not exist in an nice unix system anyway! Unix philosophy and all that:) > > I do not think you would need it anyway as systemd will stop the display > > manager all by itself. > > Given the unclarity I tried to express in my previous questions, i admit that i > am currently not too confident about that. Just to be on the safe side: Giving the clean way forward a try before heading down into a rabbit hole of hacks (as apparently required by lesser init systems) seems worthwhile to me. Especially considering that you probably do not care for systemd support anyway. > (4) Am I right in understanding that the systemd way of determining if a system > is in shutdown is to check for a special target "shutdown.target" in the list > of "jobs"? Searching the web, I find shellscript examples using the "systemctl" > service executable, something along the lines of I'd check "State" in the output of systemctl status. Or systemctl show for similar output that is meant for parsing. > /usr/bin/systemctl list-jobs | egrep -q 'shutdown.target.*start' && >echo "shutting down" || >echo "not shutting down" Systemd in general has way nicer commands, at least for common things like this. > Is there a C API for that, too? There should be, considering that systemctl gives the state in its output:-) It is all C. Best Regards, Tobias ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] does systemd set runlevel 0 in utmp on shutdown?
As i found out, utmpx.h is in POSIX, but it (of course) has no notion of a runlevel (RUN_LVL is not defined, it's only in utmp.h). This somehow makes my questions less applicable to the actual problem I'm trying to solve. It still is generally interesting, but for a "POSIX-portable" solution to my specific (nodm) problem, i had to find a different approach anyway. Kind regards, T. On 08/29/2015 07:53 AM, i wrote myself: > [...] > (1) if utmp is there (it's in POSIX), but the utmp support (being > optional) is not there, will utmp simply remain not updated? > > (2) If the answer to (1) was "yes" then, how to determine if I am > dealing with an utmp that is not actually being maintained but just > remains there as sort of a compatibility placeholder (again, it's in > POSIX)? Check for installed systemd and its version being >= 217? > > (3) In the light of questions (1) and (2), does systemd care about > POSIX at all? > [...] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] does systemd set runlevel 0 in utmp on shutdown?
On Fri, Aug 28, 2015 at 11:09:08PM +0200, tilt! wrote: > Does systemd write RUN_LVL utmp entries in a compliant fashion; > especially, when entering shutdown, does it generate an entry of > ut_type RUN_LVL with ut_pid set to 0? https://github.com/systemd/systemd/blob/master/src/shared/utmp-wtmp.c#L173 -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
