kos

@EdMorton Yes also 1.3.4

@EdMorton The second example (the actual one they have in ~/.bashrc) uses left, I too got confused at first

@EdMorton Right, I didn't take into account they were printing field 2, makes sense, all I was thinking of was that "the thing wasn't splitting". By the way @OP mawk works for me, too, so that doesn't quite explain it.

It's as if the field separator is unset. I thought it could have been awk aliased to a version that doesn't cope with a separator such as [][] but surely it wouldn't have worked when running the comman manually, either.

So which version is it? Anyways, you may try this: askubuntu.com/a/24024/380067 , and once you have the root prompt, getent passwd 1000 | cut -d: -f1 should show the username Ubuntu was installed with. Unless it's such an old version that something in this procedure is not applicable.

9.04 required 256MB of RAM. There's no shot it would run on 4MB. Either you meant 4GB or the version is not correct.

Ok, now can you explain what is the 4MB ram about? I think you meant 4GB? And why is this tagged 9.04? Do you actually mean to ask about a version that is that old?

I can't make sense of what you're asking either; what's a "post case"? Maybe you're trying to translate a (Spanish?) idiom literally, which isn't working, please word your question differently or try and use a translator

If it fills back up at soon as you free up some space,it's 99% a service logging too much. Try and run systemctl show '*' --state=loaded --property=Id --value | xargs -i sh -c 'journalctl -S "$(date -d "- 24 hours" +"%Y-%m-%d %T")" -u {} | wc -c | awk "{print \$1,\"{}\"}"' | sort -n and add the output to your question. Also, to notify users of your comments, use @ followed by the username, if you don't notify users of your replies they might miss them and stop following up

Purge the apt cache (this will remove every package you previously downloaded for installation, obviously leaving the packages installed), you should be able to gain enough space to install ncdu, I really suggest using it cause it's a mess to do this by descending each time into a directory and running du again, with errors popping up on the screen etc. sudo apt clean, then sudo apt install ncdu

@user535733 The second output OP posted is from df -h (they mispelled df for du, I think it's confirmed they have a full / partition)

For this kind of things, I'd suggest to use ncdu (an ncurses-based implementation of du, sudo apt install ncdu), which makes it a breeze to navigate the filesystem looking for big directories; you can run ncdu /, wait for the scan to finish (it may take a while depending on the performance of the drive) and then you'll be presented with the usage of every element in /. Descending further into other directories will also show usage for each element in the directory you descended into. You can quickly spot the culprit this way, without running a multitude of commands.

Or in some other file sourced by Bash / ~/.bashrc

@TommyPeanuts After some research, it could be that you're automatically adding your private key to the ssh agent with ssh-add, do you by any chance have an ssh-add command in your ~/.bashrc?

I mean I have to know at this point, I got way too invested, I know this thing will drive me insane :O

@TommyPeanuts But then it must be in Seahorse. Am I crazy? If it's not a key and the keyring it's feeding it, it must come from the keyring itself? Are you sure there's no password stored in any keyring? Login, Default, others?

@TommyPeanuts I think I've figured it out (or I'm completely wrong); the ssh key is loaded in memory by gnome-keyring's ssh agent, which feeds the key to the ssh command. But that means the key is probably stored in ~/.ssh; do you have an authorized_keys / any .pub files in ~/.ssh?

@TommyPeanuts But then it looks like something is feeding the password to ssh . What's the output of type 'ssh hostname.here.com'? Is it aliased to something?

@TommyPeanuts But what does the command say? Does it say that the used method is "password", "Kerberos", something else? Cause that explains how the authentication is actually performed, besides the fact that you found it in your record (I suppose it's not fetching it frome there :D)

It should be the final piece of the puzzle :)

@TommyPeanuts But what does ssh -vvvvv say when connecting to the host? It should print a lot of lines that reference the currently used authentication method and the methods that are left to try, updating each time one method has been tried with the result, granted, it's a bit verbose, but it should be pretty clear which method has been used to connect to the host once the connection has took place

@TommyPeanuts Ah but you said you recovered the password from your record, so if Seahorse doesn't list the key / you don't have private / public keys in ~/.ssh, you're using a different authentication method. But I can't think of any that doesn't require setting up something on the client. Did this VM get deployed for you pre-configured? In any case ssh -vvvvv hostname.here.com should list all the attempted (and the successful) authentication methods.

@TommyPeanuts That's why I asked you to fill me in, cause I'm curious, I'm not aware of something that may store the password for a simple ssh command run from the terminal. That's why I also kinda confidently guessed public-key authentication. But if you're sure the correct password is printed using Rinzwind's command, it must be somewhere, doesn't ssh -vvvvv hostname.here.com give a clue?

@TommyPeanuts No Seahorse doesn't store SSH passwords, my bad, it just manages SSH keys, I believe in the same way you could manually do from the command line with ssh-keygen / fiddling with private / public keys in ~/.ssh

@TommyPeanuts Mind to fill me in? Where was the password stored?

If you have a mechanical HDD involved, maybe check its status using smartctl -a, however, it doesn't make too much sense for me to a crash to occurr due to a failing HDD. I'm just out of answers :D

@ecjb What about the disks? What disks are we talking about? Mechanical to SSD?

@zwets We excluded memory issues already, it really looked like it was a memory issue, but OP reported htop's bar just shy of half filled once the crash occurres, so that should be ruled out. That being said, besides hardware / kernel issues, I can't think of much eles.

Other than a memory hardware issue, the only other thing I could think of right now is: something buggy, either in the kernel or in rsync, so I suggest you update everything using apt

When you come back ping me here with @kos otherwise I'll surely foget to check out the room :)

@ecjb Sure, I'll think about it in the meantime; the reason why I asked is that freezing could still be a memory issue, albeit a hardware one; if you haven't left (yet) maybe you could start a memory test with memtest and leave the mac at doing its thing (it will take a while to test 32GB of memory)

How old is the mac again?

Let me think

(I thought it was weird it could cripple 40GB worth of system memory...)

I agree. Memory has nothing to do with it, even though the symptoms are the same. Huh

Yeah in fact I couldn't see it

@ecjb No, please just run htop and verify yourself, without adding pictures (you can and should indeed add the obtained information to the question after the fact) but just run rsync with htop on the side; htop has a MEM bar which will fill up and even turn red if the memory fillls up so it's very useful for you to understand if memory is filling up or not; top doesn't have this feature, and it can be hard to tell what's going on

@ecjb No, in fact it doesn't make too much sense, that's why I suggested trying with htop, as htop will show, graphically, memory increasing during the process (if this is indeed what's happening, you should have htop running before starting the rsync command since the crash happens pretty fast), but if you're already sure the problem is too much memory consumption then it's not useful to try

@ecjb Otherwise we may be wrong about memory usage being the culprit. Since you're at it, more than one source online claims that --delete can actually cause increased memory consumption even on 3.0.0+, so maybe you can combine this with setopt +o nullglob; for source in "${SOURCEDIR}"/{,.}*; do rsync -a --progress "${source}" "${TARGETDIRCURRENT}"; done after having completely purged the target directory

@ecjb It seemse weird that that number of files would manage to trigger the OOM,rsync should consume about 100 bytes per file. Can you test again. this time with two terminal windows (one running rsync. the other running htop) so that you can visually clearly see using htop if indeed memory is filling up?

Ok then one of the directories must be have a zillion of files (or the problem is something else). The directory being giant kinda stomps me OTOH, because it apparently manages to cripple 32GB + 8GB swap? What's on the source folder?

(the last command I posted is meant to be run in Zsh because of setopt so make sure you don't accidentally run it in Bash)

Or yeah, perhaps increasing swap, as waltinator suggests

@ecjb I'm convinced this is due to too much memory being consumed by the rsync process; I dove into the man page: --delete itself is compatible with the memory-saving mode introduced with rsync 3.0.0 and shouldn't cause too much harm. Segmenting the transfer into multiple transfers could work if files are more or less split evenly across directories; e.g. you could do one rsync per directory / file in ${SOURCEDIR}, something like setopt +o nullglob; for source in "${SOURCEDIR}"/{,.}*; do rsync -a --progress --delete "${source}" "${TARGETDIRCURRENT}"; done

Mind you that -r in place of -a will do many things differently; if you need all of the options turned on by -a (rlptgoD), maybe try and exclude just -l and -D (-l should just recreate symlinks, not following them, which indeed could cause the problem but it doesn't, and -D is likely unneeded), so maybe something like rsync -rptgo --progress --delete "${SOURCEDIR}" "${TARGETDIRCURRENT}" || exit 1, then see if it works or go back debugging.

I too think it could be consuming too much memory for some reson, e.g. some unintended recursion is happening; try rsync -r -vvvvv --progress --delete "${SOURCEDIR}" "${TARGETDIRCURRENT}" || exit 1, which will avoid most of the options turned on by-a (I'm not sure how they could be a problem, but still, at least by elimination we may get somewhere)

Also I'm noticing that you used to connect using enp7s0, which isn't even listed right now, this may be due to the newly installed card effecting the enumeration of the devices; but besides the red light thing we're now stepping in unfamiliar (to me) territory, I don't remember the exact chain of events that take place when connecting but because of the differences between NICs names I would try and check first what's in /etc/netplan's configuration files,and see if there's a blatant mismatch between network interfaces listed there and interfaces listed with ip link

Your ethernet cable is connected and in good condition right? Have you tried swapping ethernet ports? After having checked these two things please post the output of journalctl -xu systemd-networkd.service

I believe on Ubuntu server you'd want to start systemd-networkd.service

What about ip link set dev enp3s0 up?