bgstack15 | I 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 |
---|---|---|
bgstack15 | But my service binary /usr/lib/x86_64-linux-gnu/ddccontrol/ddccontrol_service is running. | 01:30 |
bgstack15 | With the same start time as other system services. Does sysvinit have some parser for /lib/systemd/system/*.service or something? | 01:30 |
gnarface | if bgstack15 comes back tell them to wait longer | 02: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 receiver | 06:34 |
dan9er[m] | As you can see lzip has `-vv` on it, and it's been stuck at 16105.0 MB for half an hour | 06:35 |
dan9er[m] | No CPU, network, or disk activity | 06:35 |
dan9er[m] | I ran `lzip -tvv backup.tar.lz` in a separate console and it reports the file as prematurely truncated, so not finished | 06:37 |
dan9er[m] | How do I salvage this situation? I know that lzip deletes output files on ^C | 06: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 day | 06:42 |
lts | Unsure about the rest but why are you listening on the sender and not listening on the receiver? Meaning -l | 06:43 |
dan9er[m] | lts: ????? I got from this https://superuser.com/q/98089 | 06:49 |
dan9er[m] | I used the stuff in the question | 06:49 |
dan9er[m] | The accepted answer had an extra `< /dev/null` so I assumed it was more complicated to do that way round | 06:50 |
dan9er[m] | also, looking at docs, I should've put `-w` 🤦♂️ | 06:52 |
rwp | nc is famous for never terminating the connection. Knowing only that makes me think it finished. | 07:08 |
rwp | Which 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 |
lts | You could just ssh and enjoy integrity and confidentiality with your transfer | 07:09 |
rwp | These things are good learnings for next time. But for now I am thinking it has finished. | 07:10 |
rwp | Meanwhile... Which netcat do you have installed? | 07:13 |
dan9er[m] | lts: I'm transferring within local network | 07:19 |
dan9er[m] | ssh is overkill in this situation | 07:20 |
dan9er[m] | rwp: I have BSD netcat on receiver | 07:21 |
dan9er[m] | lemme check sender | 07:21 |
dan9er[m] | BSD as well | 07:22 |
rwp | I prefer the openbsd variant as well. It fixes a couple of the design problems with the traditional one. | 07:25 |
gnarface | chances are it finished doing whatever it was doing, but whatever that was is somewhat questionable because you've definitely got sender and receiver backwards | 07:26 |
gnarface | netcat is a basic tcp tunnel, and standard behavior for such is for the server not to exit until the client first exits | 07:27 |
gnarface | that's not a netcat thing, that's a basic tcp thing | 07:27 |
gnarface | it's baked into http too | 07:27 |
rwp | nc is rather more of a peer to peer thing than a client server thing. | 07:27 |
gnarface | well, 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 behaviors | 07: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 |
gnarface | yes 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 it | 07:29 |
gnarface | mind you, you still may not have the file you want so check it | 07:30 |
gnarface | different versions of netcat behave quite differently when called with ambiguous or conflicting options | 07:30 |
dan9er[m] | Well uh I just hit ^C on sender, no response on receiver | 07:30 |
dan9er[m] | SIGTERM? | 07:30 |
gnarface | yes | 07:30 |
rwp | If 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 |
gnarface | nc -l -p [port number] > file | 07:33 |
gnarface | ^ this command listens, aka "server" | 07:33 |
gnarface | note the different direction for the ">" | 07:33 |
gnarface | but "-l" is the key for making it the server | 07:33 |
gnarface | your example command had no designated sending ip so it is difficult to picture any data going out | 07:34 |
dan9er[m] | huh? it started processing again after I sent SIGTERM | 07:34 |
dan9er[m] | guess it's now flushing pipe buffers | 07:34 |
gnarface | you sure nothing else is running an open pipe to this port? | 07:35 |
gnarface | i find this whole business highly volatile | 07:35 |
dan9er[m] | No, again this is going through local net | 07:36 |
dan9er[m] | And btw, the tar i'm sending was bzip2 compressed | 07:36 |
gnarface | well 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 client | 07:36 |
dan9er[m] | On the receiver side i'm uncompressing it and then recompressing with lzip | 07:37 |
dan9er[m] | Cause the sender has shit amount of RAM | 07:37 |
gnarface | hmm, 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 actually | 07:37 |
gnarface | only problem i think is you could corrupt the file on either end with a stray keypress after initialization | 07: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 receiver | 07:39 |
dan9er[m] | Ah it's done | 07:39 |
gnarface | short 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 confusing | 07:39 |
gnarface | it'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 pipe | 07:40 |
gnarface | and if the client is the one sending the file instead of the server then the server should exit normally after EOF | 07: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 boxes | 07:43 | |
gnarface | also, scp or ssh is a better choice, i agree with that statement too | 07:44 |
gnarface | the real usefulness of netcat is for stuff that's more latency sensitive | 07:45 |
gnarface | like this for example: | 07:45 |
gnarface | nc -l -p [host port] -u |aplay --buffer-time=50000 | 07:46 |
gnarface | arecord -fdat -D"plug:\"dsnoop:Loopback,1\"" |nc -u [host ip] [host port] | 07:47 |
gnarface | ^ substitute any alsa device here | 07:47 |
gnarface | ("-u" for UDP mode, helps reduce latency further) | 07:48 |
gnarface | even 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 client | 07:49 |
gnarface | sorry, 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 |
gnarface | technically the "host" is technically the one listening for incoming connections, regardless of which direction you're sending the data | 07:52 |
gnarface | it's easy to think of the "host" as the one sending data, but that would not always be accurate | 07:53 |
gnarface | hmm, i see a discrepancy in my example | 07:56 |
gnarface | nc -l -p [host port] -u |aplay -q -traw -fdat --buffer-time=50000 | 07:57 |
gnarface | arecord -q -traw -fdat -D"plug:\"dsnoop:Loopback,1\"" |nc -u [host ip] [host port] | 07:57 |
gnarface | there, 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/!