libera/#devuan/ Tuesday, 2022-09-20

bgstack15I installed ddccontrol today to play around with settings for my monitor. I see that package ddccontrol placed /lib/systemd/system/ddccontrol.service, but I don't see anything in /etc/rc*.d/ or /etc/init.d/01:30
bgstack15But my service binary /usr/lib/x86_64-linux-gnu/ddccontrol/ddccontrol_service is running.01:30
bgstack15With the same start time as other system services. Does sysvinit have some parser for /lib/systemd/system/*.service or something?01:30
gnarfaceif bgstack15 comes back tell them to wait longer02:33
dan9er[m]I've run netcat to transfer a large backup to a different PC. It's been running all day, but now it's stuck!06:31
dan9er[m]I ran `nc -l -p 1337 < backup.tar.bz2` on the sender and `$ nc $senderip 1337 | bzip2 -dc | lzip -9vvs 512Mi -m 273 -o backup.tar.lz` on the receiver06:34
dan9er[m]As you can see lzip has `-vv` on it, and it's been stuck at 16105.0 MB for half an hour06:35
dan9er[m]No CPU, network, or disk activity06:35
dan9er[m]I ran `lzip -tvv backup.tar.lz` in a separate console and it reports the file as prematurely truncated, so not finished06:37
dan9er[m]How do I salvage this situation? I know that lzip deletes output files on ^C06:38
dan9er[m]Is the transfer actually finished? Was there some sort of flag I should've passed to netcat to prevent this from happening?06:39
dan9er[m]My thought is to hit ^C on the sender, but I'm scared that lzip on the receiver will see that as a broken pipe and delete the backup I was transferring all day06:42
ltsUnsure about the rest but why are you listening on the sender and not listening on the receiver? Meaning -l06:43
dan9er[m]lts: ????? I got from this https://superuser.com/q/9808906:49
dan9er[m]I used the stuff in the question06:49
dan9er[m]The accepted answer had an extra `< /dev/null` so I assumed it was more complicated to do that way round06:50
dan9er[m]also, looking at docs, I should've put `-w` 🤦‍♂️06:52
rwpnc is famous for never terminating the connection.  Knowing only that makes me think it finished.07:08
rwpWhich is one of the reasons I dislike using nc that way.  I have converted to using socat for my use of similar things.07:08
ltsYou could just ssh and enjoy integrity and confidentiality with your transfer07:09
rwpThese things are good learnings for next time.  But for now I am thinking it has finished.07:10
rwpMeanwhile... Which netcat do you have installed?07:13
dan9er[m]lts: I'm transferring within local network07:19
dan9er[m]ssh is overkill in this situation07:20
dan9er[m]rwp: I have BSD netcat on receiver07:21
dan9er[m]lemme check sender07:21
dan9er[m]BSD as well07:22
rwpI prefer the openbsd variant as well.  It fixes a couple of the design problems with the traditional one.07:25
gnarfacechances are it finished doing whatever it was doing, but whatever that was is somewhat questionable because you've definitely got sender and receiver backwards07:26
gnarfacenetcat is a basic tcp tunnel, and standard behavior for such is for the server not to exit until the client first exits07:27
gnarfacethat's not a netcat thing, that's a basic tcp thing07:27
gnarfaceit's baked into http too07:27
rwpnc is rather more of a peer to peer thing than a client server thing.07:27
gnarfacewell, yes but in the network level context one end is always designated as a server and one end is designated as a client, and they have different assigned roles and default behaviors07:28
dan9er[m]Can I just hit ^C on sender?07:28
dan9er[m]Will that throw a broken pipe on the receiver end?07:29
gnarfaceyes you can just ctrl-c it, but you might still have to kill it on the receiver end manually too, depending on how you called it07:29
gnarfacemind you, you still may not have the file you want so check it07:30
gnarfacedifferent versions of netcat behave quite differently when called with ambiguous or conflicting options07:30
dan9er[m]Well uh I just hit ^C on sender, no response on receiver07:30
dan9er[m]SIGTERM?07:30
gnarfaceyes07:30
rwpIf you are simply copying the file then after interrupting it on both sides you can sha256sum both files and verify they are the same.07:31
gnarfacenc -l -p [port number] > file07:33
gnarface^ this command listens, aka "server"07:33
gnarfacenote the different direction for the ">"07:33
gnarfacebut "-l" is the key for making it the server07:33
gnarfaceyour example command had no designated sending ip so it is difficult to picture any data going out07:34
dan9er[m]huh? it started processing again after I sent SIGTERM07:34
dan9er[m]guess it's now flushing pipe buffers07:34
gnarfaceyou sure nothing else is running an open pipe to this port?07:35
gnarfacei find this whole business highly volatile07:35
dan9er[m]No, again this is going through local net07:36
dan9er[m]And btw, the tar i'm sending was bzip2 compressed07:36
gnarfacewell let's see here, conceivably calling a listening port but with an input file ("<") i could imagine maybe successfully returning the contents of that file to the client07:36
dan9er[m]On the receiver side i'm uncompressing it and then recompressing with lzip07:37
dan9er[m]Cause the sender has shit amount of RAM07:37
gnarfacehmm, so then you connect with a client end which should be the sender, but send nothing and get the bz2 file in return... hmm, this is ass-backwards but maybe it could work actually07:37
gnarfaceonly problem i think is you could corrupt the file on either end with a stray keypress after initialization07:38
dan9er[m]hangon wait sorry what are you talking about??07:38
dan9er[m]I hit ^C on sender end already, and I sent SIGTERM on receiver07:39
dan9er[m]Ah it's done07:39
gnarfaceshort version: you got it backwards but i think i see now how it might have worked, but you still got it backwards and that makes this process unnecessarily confusing07:39
gnarfaceit's easier to get your head around if you are using "-l" on the receiver instead of the sender, even though technically once connected either netcat instance can send data to the other end of the pipe07:40
gnarfaceand if the client is the one sending the file instead of the server then the server should exit normally after EOF07:42
gnarface(the -w option isn't valid everywhere)07:42
* gnarface used this as a backup solution on a mixed network of macs and linux boxes07:43
gnarfacealso, scp or ssh is a better choice, i agree with that statement too07:44
gnarfacethe real usefulness of netcat is for stuff that's more latency sensitive07:45
gnarfacelike this for example:07:45
gnarfacenc -l -p [host port] -u |aplay --buffer-time=5000007:46
gnarfacearecord -fdat -D"plug:\"dsnoop:Loopback,1\"" |nc -u [host ip] [host port]07:47
gnarface                 ^ substitute any alsa device here07:47
gnarface("-u" for UDP mode, helps reduce latency further)07:48
gnarfaceeven in my notes for this i admittedly have it confused, because i call the client the host here, even though in a network context it's the client07:49
gnarfacesorry, that was even more confusing; in my notes i have it backwards, in this example transposed here, i have it right, to be clear^07:52
gnarfacetechnically the "host" is technically the one listening for incoming connections, regardless of which direction you're sending the data07:52
gnarfaceit's easy to think of the "host" as the one sending data, but that would not always be accurate07:53
gnarfacehmm, i see a discrepancy in my example07:56
gnarfacenc -l -p [host port] -u |aplay -q -traw -fdat --buffer-time=5000007:57
gnarfacearecord -q -traw -fdat -D"plug:\"dsnoop:Loopback,1\"" |nc -u [host ip] [host port]07:57
gnarfacethere, better, that one won't die after it hits the max wav file size :)07:58

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!