**** BEGIN LOGGING AT Mon Jan 14 02:59:56 2019
Jan 14 12:29:08 <DocScrutinizer05> I think it's pointless
Jan 14 12:29:37 <DocScrutinizer05> particularly when unredacted
Jan 14 12:29:56 <DocScrutinizer05> SPAM QED
Jan 14 13:42:37 <CatButts> meow
Jan 14 14:21:13 <ceene> I'm having a bit of trouble with one linux related thing, maybe someone has an idea
Jan 14 14:21:50 <ceene> I'm executing via execv something like this: /bin/sh -c "producer | consumer"
Jan 14 14:22:01 <ceene> with that, I have the PID of /bin/sh
Jan 14 14:22:19 <ceene> but if I kill this sh instance, both producer and consumer keep on running
Jan 14 14:22:32 <KotCzarny> you can always do 2 execvs' and copy data between processes yourself
Jan 14 14:22:40 <ceene> shouldn't sh be killing its children?
Jan 14 14:22:49 <ceene> i'd rather not do that
Jan 14 14:22:51 <ceene> :/
Jan 14 14:23:42 <KotCzarny> maybe it waits for the children to finish
Jan 14 14:23:50 <inz> KotCzarny, no need to copy data manually, one can just pipe()
Jan 14 14:24:12 <ceene> these children won't end unless someone kills them, that's the reason I want to kill sh
Jan 14 14:24:35 <ceene> I expected them to die, but it seems they are happy to keep on living forever
Jan 14 14:25:46 <KotCzarny> do the killed sh vanishes from process list?
Jan 14 14:27:04 <ceene> yes, it becomes a zombie, and after waitpid it disappears
Jan 14 14:27:42 <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]);
Jan 14 14:27:51 <KotCzarny> kill the producer or receiver then?
Jan 14 14:28:19 <inz> I believe the problem was that their pids are not known
Jan 14 14:29:19 <ceene> inz: exactly
Jan 14 14:29:47 <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
Jan 14 14:30:19 <KotCzarny> can any of them be modified to create pid file?
Jan 14 14:30:44 <ceene> i control both of them, yes
Jan 14 14:31:12 <KotCzarny> might be easiest way, or even control pipe to accept msgs/signals
Jan 14 14:31:29 <ceene> isn't there any way for sh to just kill his own children when it dies?
Jan 14 14:32:13 <KotCzarny> maybe your apps detach from sh?
Jan 14 14:32:30 <ceene> nop, none of them fork() or daemon()
Jan 14 14:32:58 <inz> The behavior might also depend on the shell
Jan 14 14:34:19 <inz> Is the pipe() solution above too complex for you?
Jan 14 14:35:18 <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
Jan 14 14:35:48 <ceene> so I would have to make a special case out of this process
Jan 14 14:36:26 <KotCzarny> make the producer or receiver create known pid file
Jan 14 14:36:39 <KotCzarny> then kill the pid when needed
Jan 14 14:36:56 <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
Jan 14 14:36:57 <ceene> that still forces me to make this a particular case that isn't managed the same way I managed the other processes
Jan 14 14:37:24 <KotCzarny> can producer spawn receiver?
Jan 14 14:37:50 <ceene> I could do that, yes
Jan 14 14:38:25 <KotCzarny> that way you could evecve it directly
Jan 14 14:40:05 <ceene> everything seems inelegant to me
Jan 14 14:40:31 <KotCzarny> all depends on your schedule and budget i guess
Jan 14 14:41:53 <ceene> If pid is less than -1, then sig is sent to every process in the process group whose ID is -pid.
Jan 14 14:42:36 <KotCzarny> https://unix.stackexchange.com/questions/124127/kill-all-descendant-processes
Jan 14 14:42:39 <KotCzarny> may be related?
Jan 14 14:42:40 <ceene> fork()+exec() /bin/sh -c 'a | b'... I guess a, b, sh would belong to the same process group
Jan 14 14:42:51 <ceene> but would the parent of sh be a member of the same process group?
Jan 14 14:44:19 <ceene> ah, I can set process group by myself via setpgrp
Jan 14 14:44:19 <KotCzarny> you can also make shell return descendant pids on kill
Jan 14 14:44:21 <KotCzarny> and use it
Jan 14 14:45:05 <KotCzarny> anyway, time to go home
Jan 14 14:45:16 <ceene> thanks for your ideas!
Jan 14 14:58:05 <ceene> the process group trick did it!
Jan 14 14:58:21 <ceene>         if(!(a->pid = fork())) {
Jan 14 14:58:21 <ceene> +               /* Move child to a new process group so we can kill all its descendents via kill -pid */
Jan 14 14:58:21 <ceene> +               setpgid(a->pid, 0);
Jan 14 14:58:21 <ceene>  
Jan 14 14:58:25 <ceene> -               kill(a->pid, sig);
Jan 14 14:58:25 <ceene> +               /* Negative PID means sending signal to all members of the group PID */
Jan 14 14:58:25 <ceene> +               kill(-a->pid, sig);
Jan 14 14:59:12 <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
Jan 14 14:59:16 <ceene> and I can forget about that
Jan 14 14:59:17 <ceene> :)
Jan 14 14:59:21 <KotCzarny> :)
Jan 14 14:59:39 <KotCzarny> nothing like sharing problem and resolving it by mind reset
Jan 14 15:00:11 <ceene> totally, you were a pretty fine rubber duck, you even talked back with useful remarks
Jan 14 15:00:35 <ceene> now I have more of a philosophical problem...
Jan 14 15:00:44 <KotCzarny> try porto
Jan 14 15:00:47 <ceene> i'm basically creating a init system by scratch
Jan 14 15:01:03 <ceene> s/by/from/
Jan 14 15:01:03 <infobot> ceene meant: i'm basically creating a init system from scratch
Jan 14 15:01:19 <KotCzarny> why not systemd?
Jan 14 15:01:22 <KotCzarny> ;)
Jan 14 15:01:23 <ceene> lol
Jan 14 15:01:33 <ceene> that's my philosophical problem, I don't want to do that
Jan 14 15:01:54 <KotCzarny> but there are few real ones to choose from
Jan 14 15:02:02 <KotCzarny> including busybox's simple inittab
Jan 14 15:03:51 <ceene> most things I'm running from busybox init
Jan 14 15:04:09 <ceene> but several things I'm running via this custom initd
Jan 14 15:04:37 <ceene> i've implemented something akin to runlevels, because this system may be running in one out of several different modes
Jan 14 15:04:40 <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
Jan 14 15:05:56 <ceene> but this also initializes several segments of shared memory, configures an FPGA and more
Jan 14 15:06:01 <KotCzarny> i did #1
Jan 14 15:06:23 <KotCzarny> the rest wasnt needed custom versions
Jan 14 15:06:26 <KotCzarny> (for me)
Jan 14 15:07:05 <ceene> this thing also receives RPC messages requesting changes in configuration, etc
Jan 14 15:07:22 <ceene> somedays I think this is great, somedays I think it's doing too much in one place
Jan 14 15:08:05 <ceene> and I'm having some kind of imposter syndrome related to systemd (am I making the same mistakes that they do?)
Jan 14 15:09:00 <KotCzarny> as long you are not on the mission to rule the world with your offspring, no
Jan 14 15:09:47 <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
Jan 14 15:09:59 <ceene> anything out of that, I'm not interested in
Jan 14 15:12:25 <KotCzarny> main problem with evild is being shoved to everyone's throats
Jan 14 15:12:37 <KotCzarny> (apart from being written badly by an idiot)
Jan 14 15:14:27 <CatButts> don't put that in mouth
Jan 14 15:14:35 <CatButts> you don't know where it's been!
Jan 14 15:17:31 <KotCzarny> i think you've missed 'shoved' part
Jan 14 16:46:23 <DocScrutinizer05> ceene: https://unix.stackexchange.com/questions/14815/process-descendants
Jan 14 16:46:41 <DocScrutinizer05> ooh, somebody beat me to it
Jan 14 16:55:35 <DocScrutinizer05> ceene: *usually* your children processes share STDIN, STDOUT, STDERR and thus when parent quits they receive SIGHUP(?)
Jan 14 16:57:21 <DocScrutinizer05> or your parent keeps thrack of its children by memorizing their PIDs and sending them a kill signal when/before the parent quits
Jan 14 16:58:59 <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
Jan 14 16:59:22 <DocScrutinizer05> or you might even use cgroups, like systemd does
Jan 14 17:00:09 <DocScrutinizer05> or run the process under monitor, though that's a total overkill and often fails (can't monitor monitors afaik)
Jan 14 17:00:40 <DocScrutinizer05> see strace -f for the latter
Jan 14 17:03:28 <DocScrutinizer05> inz: I only wrote a shell
Jan 14 17:04:26 <DocScrutinizer05> not on linux though but on BS-M which woefully lacked anything akin a shell of sorts
Jan 14 17:09: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"
Jan 14 17:12:52 <DocScrutinizer05> NB that DÜ DÜZ and DÜM were the only key<s that actually triggered a data transfer from terminal to computer
Jan 14 17:14:21 <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
Jan 14 17:22:53 <DocScrutinizer05> you'll have a hard time finding any info about BS-M, so look for AMBOSS-M or the big brother BS-1000
Jan 14 17:39:32 <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:"
Jan 14 17:41:02 <DocScrutinizer05> users? owners? passwords & login? unknown ;-P
Jan 14 17:44:22 <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"
Jan 14 17:49:47 <DocScrutinizer05> it was normal to have a ~16ß programs started during boot, just to have them waiting for input when you need them
Jan 14 17:49:58 <DocScrutinizer05> 150*
Jan 14 18:54:24 <DocScrutinizer05> http://www.tentacle.franken.de/m80/
Jan 14 20:16:45 <Wikiwide> Can Nokia N900 connect to 2.4GHz or 5GHz WiFi networks?
Jan 14 20:17:57 <Wikiwide> 802.11 b/g : 2.4GHz, yes. 
Jan 14 20:18:27 <sicelo> 5GHz, no
Jan 14 20:19:32 <Wikiwide> Okay, thank you :-) Just trying to figure out how to improve WiFi at home. Signal is crowded by neighbours' networks.
Jan 14 20:20:58 <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...
Jan 14 20:23:57 <Vajb> maybe to try different channels
Jan 14 20:32:49 <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
Jan 14 20:35:10 <sicelo> 3/cu
Jan 14 20:36:55 <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
Jan 14 20:38:41 <DocScrutinizer05> refer to competent howto regarding whether those multiple AP should all use same channel or nailed fix to each its own channel
Jan 14 20:39:21 <DocScrutinizer05> plcae the APs along "perimeter" of your flat
Jan 14 20:39:39 <DocScrutinizer05> place*
Jan 14 20:39:48 <DocScrutinizer05> sicelo: ?
Jan 14 20:39:58 <sicelo> typo. sorry
Jan 14 20:40:04 <DocScrutinizer05> np :-)
Jan 14 20:42:05 <sicelo> >configure them so they all run the same SSID and establish one contiguous RF network< a la, WDS?
Jan 14 20:46:00 <DocScrutinizer05> sicelo: I lack expertise on that particular detail of WLAN
Jan 14 20:48:04 <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
Jan 14 23:21:48 <sixwheeledbeast^> I would always disable WDS. Firstly survey for the issue, try to centralise or AP to the area get it further away from conflicting AP's. I prefer using AP's that would mesh
Jan 14 23:22:45 <sixwheeledbeast^> Channel is an important thing too. look for a none conflicting channel to your neighbours
Jan 14 23:24:20 <sixwheeledbeast^> wavemon is a tool i use a lot when surveying for new AP's
Jan 14 23:32:52 <sixwheeledbeast^> When choosing channel try and aim for 1, 6, 11 or 13 (13 is regional) where possible. These channels don't overlap so provide the best option if you can get a free one.
Jan 14 23:34:52 <sixwheeledbeast^> In heavily congested areas your results will vary widely between whatever channel you choose.
**** ENDING LOGGING AT Tue Jan 15 02:59:58 2019