DocScrutinizer05 | http://wiki.maemo.org/Community_Council | 01:08 |
---|---|---|
DocScrutinizer05 | warfare: ping | 01:09 |
DocScrutinizer05 | warfare: spam in http://maemo.org/news/planet-maemo/rss.xml | 01:09 |
DocScrutinizer05 | xes: ^^^ | 01:09 |
DocScrutinizer05 | warfare: xes: I have no idea if planet-maemo is of any use, or been of any use during last 10 years | 01:11 |
DocScrutinizer05 | tbh I don't even understand what's the intended purpose. Some maemo specific filter bubble of sorts? | 01:14 |
xes | DocScrutinizer05: there is a task collecting news from maby blogs and other sources | 01:22 |
xes | *many | 01:22 |
pabs3 | DocScrutinizer05: its a very common thing to have for Linux distros, for eg https://planet.debian.org/ http://planet.gnome.org/ http://planetkde.org/ etc | 03:54 |
DocScrutinizer05 | I think it's pointless | 13:29 |
DocScrutinizer05 | particularly when unredacted | 13:29 |
DocScrutinizer05 | SPAM QED | 13:29 |
CatButts | meow | 14:42 |
ceene | I'm having a bit of trouble with one linux related thing, maybe someone has an idea | 15:21 |
ceene | I'm executing via execv something like this: /bin/sh -c "producer | consumer" | 15:21 |
ceene | with that, I have the PID of /bin/sh | 15:22 |
ceene | but if I kill this sh instance, both producer and consumer keep on running | 15:22 |
KotCzarny | you can always do 2 execvs' and copy data between processes yourself | 15:22 |
ceene | shouldn't sh be killing its children? | 15:22 |
ceene | i'd rather not do that | 15:22 |
ceene | :/ | 15:22 |
KotCzarny | maybe it waits for the children to finish | 15:23 |
inz | KotCzarny, no need to copy data manually, one can just pipe() | 15:23 |
ceene | these children won't end unless someone kills them, that's the reason I want to kill sh | 15:24 |
ceene | I expected them to die, but it seems they are happy to keep on living forever | 15:24 |
KotCzarny | do the killed sh vanishes from process list? | 15:25 |
ceene | yes, it becomes a zombie, and after waitpid it disappears | 15:27 |
inz | Som'n like htis: int pfd[2]; pipe(pfd); if (!(prodpid = fork())) { close(STDOUT_FILENO); dup2(pfd[1], STDOUT_FILENO); producer execve; } if (!(conpid = fork())) { close(STDIN_FILENO); dup2(pfd[0], STDIN_FILENO); consumer execve; } close(pfd[0]); close(pfd[1]); | 15:27 |
KotCzarny | kill the producer or receiver then? | 15:27 |
inz | I believe the problem was that their pids are not known | 15:28 |
ceene | inz: exactly | 15:29 |
ceene | my C program only knows about sh, because I fork+execv, so I know the pid of the child I create, but I do not know nothing of the children sh begets | 15:29 |
KotCzarny | can any of them be modified to create pid file? | 15:30 |
ceene | i control both of them, yes | 15:30 |
KotCzarny | might be easiest way, or even control pipe to accept msgs/signals | 15:31 |
ceene | isn't there any way for sh to just kill his own children when it dies? | 15:31 |
KotCzarny | maybe your apps detach from sh? | 15:32 |
ceene | nop, none of them fork() or daemon() | 15:32 |
inz | The behavior might also depend on the shell | 15:32 |
inz | Is the pipe() solution above too complex for you? | 15:34 |
ceene | no, I could do it, but I have several processes that I launch via fork+execv, that are later on managed by a few functions | 15:35 |
ceene | so I would have to make a special case out of this process | 15:35 |
KotCzarny | make the producer or receiver create known pid file | 15:36 |
KotCzarny | then kill the pid when needed | 15:36 |
inz | It should be enough for you to just kill one end or the other, they should mutually destruct on SIGPIPE when one end goes away | 15:36 |
ceene | that still forces me to make this a particular case that isn't managed the same way I managed the other processes | 15:36 |
KotCzarny | can producer spawn receiver? | 15:37 |
ceene | I could do that, yes | 15:37 |
KotCzarny | that way you could evecve it directly | 15:38 |
ceene | everything seems inelegant to me | 15:40 |
KotCzarny | all depends on your schedule and budget i guess | 15:40 |
ceene | If pid is less than -1, then sig is sent to every process in the process group whose ID is -pid. | 15:41 |
KotCzarny | https://unix.stackexchange.com/questions/124127/kill-all-descendant-processes | 15:42 |
KotCzarny | may be related? | 15:42 |
ceene | fork()+exec() /bin/sh -c 'a | b'... I guess a, b, sh would belong to the same process group | 15:42 |
ceene | but would the parent of sh be a member of the same process group? | 15:42 |
ceene | ah, I can set process group by myself via setpgrp | 15:44 |
KotCzarny | you can also make shell return descendant pids on kill | 15:44 |
KotCzarny | and use it | 15:44 |
KotCzarny | anyway, time to go home | 15:45 |
ceene | thanks for your ideas! | 15:45 |
ceene | the process group trick did it! | 15:58 |
ceene | if(!(a->pid = fork())) { | 15:58 |
ceene | + /* Move child to a new process group so we can kill all its descendents via kill -pid */ | 15:58 |
ceene | + setpgid(a->pid, 0); | 15:58 |
ceene | 15:58 | |
ceene | - kill(a->pid, sig); | 15:58 |
ceene | + /* Negative PID means sending signal to all members of the group PID */ | 15:58 |
ceene | + kill(-a->pid, sig); | 15:58 |
ceene | so I can keep exactly the same code for everything, and if I face later on some other thing that must create children, they will die as well | 15:59 |
ceene | and I can forget about that | 15:59 |
ceene | :) | 15:59 |
KotCzarny | :) | 15:59 |
KotCzarny | nothing like sharing problem and resolving it by mind reset | 15:59 |
ceene | totally, you were a pretty fine rubber duck, you even talked back with useful remarks | 16:00 |
ceene | now I have more of a philosophical problem... | 16:00 |
KotCzarny | try porto | 16:00 |
ceene | i'm basically creating a init system by scratch | 16:00 |
ceene | s/by/from/ | 16:01 |
infobot | ceene meant: i'm basically creating a init system from scratch | 16:01 |
KotCzarny | why not systemd? | 16:01 |
KotCzarny | ;) | 16:01 |
ceene | lol | 16:01 |
ceene | that's my philosophical problem, I don't want to do that | 16:01 |
KotCzarny | but there are few real ones to choose from | 16:01 |
KotCzarny | including busybox's simple inittab | 16:02 |
ceene | most things I'm running from busybox init | 16:03 |
ceene | but several things I'm running via this custom initd | 16:04 |
ceene | i've implemented something akin to runlevels, because this system may be running in one out of several different modes | 16:04 |
inz | Doesn't every good unix geek write at least 1) a music player, 2) a window manager, 3) an irc client, 4) a compiler, 5) a kernel and 6) an init replacement; not necessarily in that order | 16:04 |
ceene | but this also initializes several segments of shared memory, configures an FPGA and more | 16:05 |
KotCzarny | i did #1 | 16:06 |
KotCzarny | the rest wasnt needed custom versions | 16:06 |
KotCzarny | (for me) | 16:06 |
ceene | this thing also receives RPC messages requesting changes in configuration, etc | 16:07 |
ceene | somedays I think this is great, somedays I think it's doing too much in one place | 16:07 |
ceene | and I'm having some kind of imposter syndrome related to systemd (am I making the same mistakes that they do?) | 16:08 |
KotCzarny | as long you are not on the mission to rule the world with your offspring, no | 16:09 |
ceene | no, I just need this thing to manage different pieces of hardware so in the end the product does what it has to do: be a radar | 16:09 |
ceene | anything out of that, I'm not interested in | 16:09 |
KotCzarny | main problem with evild is being shoved to everyone's throats | 16:12 |
KotCzarny | (apart from being written badly by an idiot) | 16:12 |
CatButts | don't put that in mouth | 16:14 |
CatButts | you don't know where it's been! | 16:14 |
KotCzarny | i think you've missed 'shoved' part | 16:17 |
DocScrutinizer05 | ceene: https://unix.stackexchange.com/questions/14815/process-descendants | 17:46 |
DocScrutinizer05 | ooh, somebody beat me to it | 17:46 |
DocScrutinizer05 | ceene: *usually* your children processes share STDIN, STDOUT, STDERR and thus when parent quits they receive SIGHUP(?) | 17:55 |
DocScrutinizer05 | or your parent keeps thrack of its children by memorizing their PIDs and sending them a kill signal when/before the parent quits | 17:57 |
DocScrutinizer05 | or you use a unique new program group for your process and its children, teher are ways to send signals to all processes of a pg | 17:58 |
DocScrutinizer05 | or you might even use cgroups, like systemd does | 17:59 |
DocScrutinizer05 | or run the process under monitor, though that's a total overkill and often fails (can't monitor monitors afaik) | 18:00 |
DocScrutinizer05 | see strace -f for the latter | 18:00 |
DocScrutinizer05 | inz: I only wrote a shell | 18:03 |
DocScrutinizer05 | not on linux though but on BS-M which woefully lacked anything akin a shell of sorts | 18:04 |
DocScrutinizer05 | this thing even had weird terminals (DS-075) where youz can move around the cursor and edit on screen like you want, and there are "DÜ", "DÜZ" "DÜM" keys for DatenÜbertragung (Zeile/Marke) "datatransfer (all)", "datatransfer line of cursor" and "datatransfer from mark to cursor" | 18:09 |
DocScrutinizer05 | NB that DÜ DÜZ and DÜM were the only key<s that actually triggered a data transfer from terminal to computer | 18:12 |
DocScrutinizer05 | there was a so called fullscreen mode(?) on a virtual second screen which transferred every key as it got pressed, but that mode and screen was reserved for the fullscreen editor | 18:14 |
DocScrutinizer05 | you'll have a hard time finding any info about BS-M, so look for AMBOSS-M or the big brother BS-1000 | 18:22 |
DocScrutinizer05 | the whole thing looked very "IRCy", commands to OS were like "/BOOT" or "/DATE" or "/START prognam" and a line starting with ":prognam:" established a dialog between that process "prognam" and the terminal sending it. All output from prognam showed on that terminal from then on, and all input from that terminal went to prognam until another ":progTWO:" | 18:39 |
DocScrutinizer05 | users? owners? passwords & login? unknown ;-P | 18:41 |
DocScrutinizer05 | the program FILE was like a combo of `cp`, `mv` `rm` and `ls`/`stat` and for our 6 terminals we had 6 processes started: "FILE1" to "FILE6", while scripts used "FILE" | 18:44 |
DocScrutinizer05 | it was normal to have a ~16ß programs started during boot, just to have them waiting for input when you need them | 18:49 |
DocScrutinizer05 | 150* | 18:49 |
DocScrutinizer05 | http://www.tentacle.franken.de/m80/ | 19:54 |
Wikiwide | Can Nokia N900 connect to 2.4GHz or 5GHz WiFi networks? | 21:16 |
Wikiwide | 802.11 b/g : 2.4GHz, yes. | 21:17 |
sicelo | 5GHz, no | 21:18 |
Wikiwide | Okay, thank you :-) Just trying to figure out how to improve WiFi at home. Signal is crowded by neighbours' networks. | 21:19 |
Wikiwide | I have heard that ordinary modems aren't that good at WiFi networking, especially when surrounded by lots of devices. Now I have a gateway or two to test... | 21:20 |
Vajb | maybe to try different channels | 21:23 |
DocScrutinizer05 | interesting teardown just to show what complexity of engineering we face when competing with state of the art top notch embedded integration https://www.youtube.com/watch?v=L5eSaFIIUpM | 21:32 |
sicelo | 3/cu | 21:35 |
DocScrutinizer05 | Wikiwide: first of all: do manual channel selection and nail down the channel so it never changes. Consider carefully where to place your AP. Adjust antenna orientation. Then, starting to do really effective measures, use multiple APs and configure them so they all run the same SSID and establish one contiguous RF network | 21:36 |
DocScrutinizer05 | refer to competent howto regarding whether those multiple AP should all use same channel or nailed fix to each its own channel | 21:38 |
DocScrutinizer05 | plcae the APs along "perimeter" of your flat | 21:39 |
DocScrutinizer05 | place* | 21:39 |
DocScrutinizer05 | sicelo: ? | 21:39 |
sicelo | typo. sorry | 21:39 |
DocScrutinizer05 | np :-) | 21:40 |
sicelo | >configure them so they all run the same SSID and establish one contiguous RF network< a la, WDS? | 21:42 |
DocScrutinizer05 | sicelo: I lack expertise on that particular detail of WLAN | 21:46 |
sicelo | ok. i'm also not well-versed. just that WDS tends to be not worth it (bandwidth is reduced) and also interoperability with APs from different manufacturers is virtualy non-existe t | 21:48 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!