hyrcanus | facebook got deplatformed today! PROST! | 00:44 |
---|---|---|
golinux | Wrong channel for that news and discussion | 01:03 |
golinux | Please take it to #devuan-offtopic | 01:03 |
adhoc | golinux: perhaps what we can learn from this situation is, what mistakes happened, learn from them and apply changes as appropriate | 01:35 |
adhoc | which reminds me, quagga packages... | 01:35 |
adhoc | I see that debian has dropped them from stable | 01:36 |
adhoc | however I was unable to find out why | 01:36 |
bb|hcb | adhoc: it got replaced by frr | 01:49 |
adhoc | oh | 01:49 |
adhoc | bb|hcb: do you know why ? | 01:49 |
bb|hcb | the quagga project became inactive and frr forked | 01:51 |
bb|hcb | same as how quagga replaced zebra | 01:52 |
bb|hcb | frr is in Devuan, not forked | 01:53 |
bb|hcb | TBH I don't know the answer to the 'why' | 01:54 |
adhoc | ok, thats cool. | 01:55 |
adhoc | just trying to understand why quagga was dropped. | 01:55 |
adhoc | thanks bb|hcb | 01:55 |
adhoc | I dist-upgrade'd some machines from beowulf to chimera last week | 02:17 |
adhoc | if i run; | 02:17 |
adhoc | # lsb_release -s -c | 02:17 |
adhoc | beowulf | 02:18 |
adhoc | so that makes sense | 02:18 |
adhoc | but on chimera; | 02:18 |
adhoc | # lsb_release -s | 02:18 |
adhoc | No LSB modules are available. | 02:18 |
adhoc | # lsb_release -c | 02:18 |
adhoc | Codename:n/a | 02:18 |
adhoc | is that supposed to happen ? | 02:18 |
adhoc | if I; cat /etc/os-release | 02:19 |
adhoc | things look sensibla and all the usual values are filled in | 02:19 |
adhoc | hi nemo | 02:22 |
hyrcanus | i get n/a with that command adhoc | 02:44 |
hyrcanus | on ceres | 02:44 |
adhoc | right, so does that mean it is broken? | 02:51 |
adhoc | surely that can not be the expected output? | 02:51 |
adhoc | various scripts relly on that givning back a release name so it can pick the right repository to pull package from. | 02:51 |
adhoc | s/relly/rely/ | 02:52 |
adhoc | I assume if chimera is going to be 'stable' soon, that needs to get updated ? | 02:55 |
golinux | It is "stable". Waiting on documentation and updated website to release. | 02:58 |
golinux | Hopefully after the upcoming Bullseye point release | 02:59 |
golinux | adhoc: ^^^ | 02:59 |
adhoc | golinux: thanks for that =) | 03:00 |
adhoc | if it was a bug and no one has spotted it yet, it could be sorted out =) | 03:00 |
golinux | It could be a Debian bug. (Didn't read too closely) | 03:01 |
adhoc | well the package that has lsb_release in it must be devuan specific? | 03:04 |
adhoc | otherwise we would have all the debian relase names and numbers? | 03:05 |
bb|hcb | adhoc: you can fix that by adding VERSION_CODENAME=chimaera to /etc/os-release (that was discussed some time ago, but I do not remember); Devuan specific packages have +devuanN or ~devuanN in their version | 03:08 |
adhoc | bb|hcb: ok thanks. | 03:09 |
adhoc | should that be done manually, or is that something that users would expect to be done in the jump to stable? | 03:10 |
golinux | adhoc: We are also waiting for updated versions of the "live" isos. | 03:10 |
adhoc | ok | 03:11 |
* adhoc will pull those down and tinker when they are done =) | 03:11 | |
golinux | Installer isos are OK. | 03:11 |
systemdlete | is there a way to prevent a package upgrade? My system has its heart set on upgrading this one package, no matter what I try to do to stop it. It is a huge package, and I kind of want to do some kind of integrity check on the package system before doing anything further. | 08:06 |
systemdlete | rpm had a tool that would sort of clean up the rpm database. I get a sense that debian does not feature a db in its packaging system | 08:07 |
systemdlete | If I proceed with the install of the package, it hangs during unpacking | 08:08 |
systemdlete | I've tried rebooting | 08:08 |
gnarface | systemdlete: look into pinning; you can pin packages at a particular version to prevent them upgrading automatically along with the rest of the system | 08:14 |
gnarface | of course, that will prevent any upgrades of stuff that requires the newer version if the package is set to check, and may break stuff invisibly if not | 08:15 |
systemdlete | this package is in a funky state. I get a message saying: 1 not fully installed or removed | 08:15 |
gnarface | try to purge it first | 08:15 |
systemdlete | wont let me do that either | 08:15 |
systemdlete | :( | 08:15 |
gnarface | why does it fail? | 08:15 |
gnarface | any error message? | 08:15 |
systemdlete | is there a way to tell apt to completely forget about the package? | 08:15 |
systemdlete | hold on | 08:16 |
gnarface | no that would be bad | 08:16 |
gnarface | you need to remove it | 08:16 |
systemdlete | is there a way to remove it? | 08:16 |
systemdlete | force if need be? | 08:16 |
gnarface | check the preinst/postinst scripts | 08:16 |
gnarface | figure out what they do and run the parts manually that are failing | 08:16 |
systemdlete | so extract them? | 08:16 |
gnarface | if you tried to install it they're already extracted somewhere | 08:17 |
gnarface | somewhere in /var i think | 08:17 |
gnarface | if it's half installed it's in that state exploded across the filesystem | 08:17 |
gnarface | that's why you don't want to just tell apt to "ignore it" that would make the mess worse | 08:17 |
systemdlete | the problem I think is that the hang is happening during the unpacking which is probably when it gets those scripts | 08:17 |
gnarface | is it running out of space? | 08:18 |
systemdlete | no | 08:18 |
systemdlete | but! | 08:18 |
systemdlete | when I first tried to install it, it DID run out of space. | 08:18 |
gnarface | did it come with a lot of other dependencies? | 08:18 |
systemdlete | so I added some space and then restarted the install. that's when all heck broke loose | 08:18 |
systemdlete | yes, many. | 08:18 |
gnarface | maybe make sure they complete installation first | 08:18 |
gnarface | then check for free space again | 08:18 |
systemdlete | this was the last to be installed. All the others (deps) got installed ok | 08:19 |
gnarface | no actual error message? | 08:19 |
systemdlete | what sort of error message -- from what exactly? There are messages galore from apt install... | 08:20 |
gnarface | just paste the last screen or so of it at paste.debian.ent | 08:20 |
gnarface | paste.debian.net i mean | 08:20 |
gnarface | actually proably just the last 10 lines should be enough | 08:20 |
systemdlete | apt or apt-get? | 08:20 |
gnarface | apt-get is the one i'm familiar with but you'd better have run "apt-get update" first | 08:20 |
systemdlete | funny part is, I did this on another devuan beowulf VM and no problem! | 08:20 |
gnarface | yea i have a strong feeling this issue is self-inflicted i'm just looking for the proof | 08:21 |
systemdlete | self-inflicted huh | 08:22 |
systemdlete | I committed the sin of running out of disk space, then apt refuses to be happy for me | 08:22 |
gnarface | well it's proably in stages | 08:22 |
gnarface | so that was part of it | 08:22 |
gnarface | then skimming the error messages without reading them was another part | 08:22 |
gnarface | i suspect there is another undiscovered tactical error in the chain of events though | 08:23 |
gnarface | but it might just be a bad preinst/postinst script that doesn't clean up right in this corner case | 08:23 |
gnarface | that's why you gotta find it | 08:23 |
gnarface | the error messages in question would have provided a strong clue so it might not have been necessary | 08:24 |
gnarface | i hope this isn't a package from a 3rd party repo... | 08:24 |
systemdlete | hope all you want gnarface. It is, indeed... | 08:24 |
gnarface | hmm, that might be the critical key error, because it could have been built on invalid assumptions from ubuntu or something, and really made a mess that can't be cleaned up without a complete reinstall | 08:25 |
gnarface | ... but i don't know that for sure, that's just the worst case scenario | 08:25 |
systemdlete | idk. Like I said, I had no problem on a differnt system, but then that one had enough space the first go around | 08:25 |
gnarface | yea, so you're in uncharted territory now | 08:25 |
gnarface | you've used the tools in a way they were not intended and now this is the definition of undefined behavior | 08:26 |
systemdlete | https://paste.debian.net/1214342/ | 08:26 |
gnarface | my advice stands that if you examine the preinst and postinst scripts (and maybe the prerm and postrm ones too) you should be able to figure out a way to clean it up | 08:26 |
gnarface | that paste looks normal | 08:27 |
gnarface | then it errors out after you say yes or what? | 08:27 |
systemdlete | no, it proceeds but it hangs during unpack | 08:27 |
gnarface | hangs as in i/o locks? | 08:28 |
systemdlete | I mean, for a long, long, long... x100 times | 08:28 |
gnarface | that suggests an out of memory or out of storage error | 08:28 |
systemdlete | I looked for locked files, but I don't see anything | 08:28 |
systemdlete | nope plenty of memory and disk | 08:28 |
gnarface | can you ssh in remotely while it is doing this? | 08:28 |
systemdlete | cpu's barely moving | 08:28 |
gnarface | does the whole machine freeze or just that terminal? | 08:28 |
systemdlete | terminal doesn't really freeze, no | 08:28 |
gnarface | could the package be trying to connect to a remote server that is unresponsive? | 08:28 |
systemdlete | system is not freezing, slowing down a bit sometimes, but not freezing | 08:29 |
systemdlete | during unpacking? | 08:29 |
gnarface | wait... so let me be clear here, just the package installation task hangs, not anything else on the system? | 08:29 |
systemdlete | right | 08:29 |
gnarface | but cpu and ram usage are low at that moment and drive space is free? | 08:29 |
systemdlete | htop says so | 08:29 |
systemdlete | nothing unusal. More like some file lock | 08:29 |
gnarface | and it's got all the same library versions as the other VM that works? | 08:29 |
systemdlete | lsof |grep /lock shows 3 files locked, 1 by apt and the other 2 by dpkg | 08:30 |
systemdlete | I'd have to run a comparison for that, but I think they are more or less the same in terms of base libraries, etc. | 08:30 |
systemdlete | They're both devuan beowulf and they've both been kept updated/upgraded | 08:31 |
systemdlete | (sometimes I get behind on that from time to time, but I always run update first before upgrade) | 08:31 |
gnarface | see if it makes outgoing network connections during install | 08:31 |
gnarface | maybe the server went down between the two installs | 08:31 |
systemdlete | oh it definitely did | 08:32 |
systemdlete | I had to take it down to install additional disk space | 08:32 |
gnarface | no i mean the remote server | 08:32 |
systemdlete | oh | 08:32 |
gnarface | maybe this omd labs thing tries to download files from a remote server during install and maybe that's why it appears to hang with no apparent load | 08:32 |
systemdlete | you think the unpack step might involve remote accesses? | 08:32 |
systemdlete | I have tried this multiple times now | 08:33 |
gnarface | i know it is technically feasible that's all | 08:33 |
systemdlete | same pattern every time | 08:33 |
systemdlete | sure | 08:33 |
gnarface | i'm not familiar with this software | 08:33 |
systemdlete | and I am not confident in apt | 08:33 |
gnarface | it is usually fine unless you start mixing foreign packages from other distros in, then it can get really confused really fast | 08:34 |
systemdlete | this is not really another distro, per se, but I agree that can introduce issues | 08:34 |
systemdlete | what would happen if I remove those 3 lock files and let the process fail or re-create them? | 08:35 |
systemdlete | they're just files after all... | 08:35 |
gnarface | dunno for sure but i assume massive irreversible dependency tree corruption leading to all future upgrades and installs failing | 08:35 |
systemdlete | you think that apt would proceed to lock a non-existent file? | 08:35 |
systemdlete | I would think it would just stop with an error | 08:36 |
gnarface | it makes a lock file so only one thing can change the dependency tree at a time | 08:36 |
systemdlete | yes | 08:36 |
gnarface | if you disengage that you have two processes changing the dependency tree that were written to assume that's not possible | 08:36 |
gnarface | you don't see why that might be a bad idea? | 08:36 |
systemdlete | ??? what 2 processes? | 08:36 |
gnarface | if you don't, just take my word fo rit | 08:36 |
gnarface | for it | 08:36 |
systemdlete | I'm not trying to run apt at the same time as another process | 08:37 |
systemdlete | at least not one that would be accessing the apt's lock files... | 08:37 |
systemdlete | sorry, not following | 08:37 |
gnarface | afaik that's the only thing removing that lock file would do for you | 08:37 |
gnarface | but at this point i can't do the leg work for you | 08:38 |
systemdlete | I'm thinking that maybe... maybe one of those files is 'bad' | 08:38 |
gnarface | my speculation would be useless here, you have to follow your heart | 08:38 |
systemdlete | well thanks for the help | 08:38 |
systemdlete | I'll keep monkeying with this | 08:39 |
systemdlete | I may have to just re-install the whole blasted system. I have backups, so it is not a big deal. | 08:39 |
gnarface | next time maybe try the foreign packages in a chroot, so if this type of thing happens you can just delete it all and start over | 08:39 |
systemdlete | no | 08:39 |
systemdlete | maybe next time I will remember to snapshot the VM (doh! why do I always forget) | 08:39 |
gnarface | indeed | 08:40 |
systemdlete | before starting a massive task liek this | 08:40 |
systemdlete | like this | 08:40 |
systemdlete | crap | 08:40 |
systemdlete | so, in all of the 25 years or so of debian, no one has written a database integrity check script for apt? That surprises me. | 08:40 |
systemdlete | I'd think that would be standard for a distro of such maturity | 08:41 |
systemdlete | It's got to be out there... somewhere | 08:41 |
gnarface | i'm not sure there isn't one, but there are certain mistakes they do just seem to rather punish you for | 08:46 |
gnarface | the first thing i'd do like i said is find the package's own installation scripts and figure out where they failed | 08:46 |
gnarface | i'd usually expect that to give me a clue as to why it failed and how to either back it out or help it complete | 08:47 |
peterrooney | systemdlete: they will be in /var/lib/dpkg/info | 08:47 |
peterrooney | systemdlete: or, should be, that's where dpkg puts all pre/post install/remove scripts | 08:47 |
systemdlete | none in there for this package | 08:47 |
systemdlete | (tons of other ones though) | 08:48 |
gnarface | if they didn't make it then perhaps you will have to extract a copy to read them | 08:48 |
gnarface | maybe it would be better to just compare the "dpkg -l" lists from this and the working system to find version discrepancies | 08:49 |
gnarface | maybe this one is just missing something expected? | 08:49 |
gnarface | normally you'd be expecting some obvious error but not if they forget to add it as a package dependency | 08:50 |
systemdlete | I'm going to let the thing run for a few hours and see if the needle moves. Maybe I'm just being impatient. It IS a big package. | 08:51 |
systemdlete | OTOH, I notices that no disk space was being eaten during unpack (by running df every few seconds) | 08:52 |
systemdlete | maybe it is doing checksums in memory... idk, guessing at this | 08:52 |
systemdlete | I'd run strace, but sadly I did not install it, and can't now that I'm caught up in this "loop" | 08:53 |
systemdlete | there's this option to apt remove: --force-remove-reinstreq | 08:55 |
systemdlete | it is considered a "nuclear option" | 08:55 |
systemdlete | something is def going on because the disk access light is going constantly, whereas when I stopped it in the previous attepts, it stopped | 09:01 |
systemdlete | I don't see df changing though. So maybe these are reads only. Maybe checksumming... | 09:02 |
systemdlete | I just dont recall it taking this long on the other system. | 09:02 |
gnarface | ps aux --forest | 09:08 |
gnarface | iotop -a | 09:09 |
gnarface | fuser ... something | 09:09 |
gnarface | i forget | 09:09 |
gnarface | if there's disk access happening there has to be a process attached to it | 09:09 |
gnarface | maybe if that's what is hanging you can figure out what is wrong | 09:09 |
gnarface | if these systems are very different in CPU speed or RAM quantity, something like the recent shift to using xz by a lot of different stuff could cause exponentially longer unpacking times on older hardware | 09:10 |
gnarface | df wouldn't necessarily show any changes if it never made it out of ram | 09:11 |
hyrcanus | i find dpkg -r and --force-remove gets me out of many binds | 09:15 |
gnarface | that might back the package out but if it fails again with plenty of space we'll still be at square 1 | 09:17 |
systemdlete | I think the nuke option worked... | 09:18 |
systemdlete | just to be sure, I'm going to reboot | 09:19 |
systemdlete | (thinking maybe a fsck wouldn't hurt here) | 09:19 |
hyrcanus | what % of physical do you set your zram cache to? i seem to be running fine with zram at 199% of physical ram (3754MB) | 09:19 |
gnarface | he's gone already, i'd forgotten this was a zram setup | 09:20 |
gnarface | if that's what is different between this machine and the vm that worked it would be worth trying the package install again with it disabled temporarily | 09:20 |
hyrcanus | mhm | 09:20 |
hyrcanus | the maintainers of my other device set zram to 25% of physical ram | 09:23 |
hyrcanus | does that allow some more frequently used apps to get higher performance ram? | 09:23 |
gnarface | than 199%? i'm not sure but i would expect the variable isn't frequency of use but rather initial ram footprint | 09:26 |
gnarface | and i don't know which way it would skew in the case of there being way more demand than is physically available | 09:27 |
gnarface | i'd have to run benchmarks myself | 09:27 |
gnarface | but for stuff that doesn't swap in the first place i'd expect no change | 09:27 |
gnarface | the difference is gonna be in stuff that needs lots of swap immediately | 09:28 |
onefang | "ps aux --forest"? man ps doesn't mention --forest. | 09:30 |
systemdlete | gnarface: I installed strace (and ltrace) and now I can see what the ##$DFS the thing is doing | 09:32 |
systemdlete | it's installing a gob of perl stuff | 09:32 |
systemdlete | which makes sense -- it needs that | 09:32 |
systemdlete | but... again, I don't recall it taking this long on the other system... | 09:33 |
systemdlete | otoh, I think I was eating dinner while it did the install, so I might be wrong | 09:33 |
systemdlete | sorry to bug you with this nonsense. | 09:33 |
systemdlete | it's doing a ton of rename()s | 09:34 |
systemdlete | no wonder I see no disk space consumption at this point. | 09:34 |
systemdlete | renames all the *-dpkg.pm files to just *.pm | 09:35 |
systemdlete | iotop shows a lot of I/O "activity" but no read or write counts being bumped -- this all makes sense now | 09:37 |
systemdlete | I'm going to shut down everything so the process can get all the cycles it can. | 09:38 |
gnarface | onefang: now i can't even remember where i learned it initially... maybe it is in those info pages that got tossed overboard? | 09:40 |
gnarface | there were a ton of GNU additions to the standard utilities all prefixed with "--" instead of "-" to distinguish them from the POSIX ones | 09:40 |
gnarface | and at some point the info pages had exhaustive documentation that went above and beyond the man pages | 09:41 |
gnarface | last time i went looking for them someone had just replaced them all with info-ized copies of the man pages though | 09:41 |
gnarface | now i don't know where that data is | 09:41 |
gnarface | at one point it had just been removed from the info configuration by default and you could put it back but either that is no longer true or i simply forgot how | 09:42 |
onefang | So does this --forest thing do something similar to pstree? | 09:42 |
gnarface | probably | 09:42 |
gnarface | yes actually it is significantly more verbose | 09:43 |
onefang | Yes I just ran it. | 09:43 |
gnarface | the same thing happened to the tar man page | 09:44 |
onefang | Though not useful for my main usage of ps, which is to filter it through grep to check specific programs. | 09:44 |
hyrcanus | i never got used to info pages | 09:53 |
rrq | onefang: "--forest" is just a bad spelling of the "-f" option | 10:09 |
Guest39 | I am using debootstrap, but I cannot complete the installation. | 10:09 |
Guest39 | debootstrap --include=xorg,openbox,fbpanel,pcmanfm,tilix,,network-manager,firefox-esr,,qbittorrent,blueman,alsa-utils,vlc,meld,xvkbd,file-roller,evince,gimp,gthumb,synaptic,gnome-disk-utility --arch=amd64 chimaera /home/xxx/345/ http://deb.devuan.org/merged | 10:09 |
Guest39 | It will install these two dependencies at the same time ( libsystemd0 libelogind0 ) , They conflict | 10:09 |
hyrcanus | q* pulls in a mess. still get it without qbittorrent? | 10:10 |
Guest39 | yes,same | 10:11 |
GyrosGeier | the debootstrap resolver is rather primitive | 10:12 |
hyrcanus | libelogind0 tells me Conflicts: libsystemd0 | 10:13 |
onefang | I debootstrap the minimum, then chroot into it and apt install the rest. | 10:13 |
rrq | perhaps nominating libelogind0 as first include make it happier | 10:15 |
Guest39 | ok, Goodism @onefang | 10:15 |
hyrcanus | whapt-cache rdepends libsystemd0 |less shows me no package incorrectly wanting libsystemd0 | 10:16 |
hyrcanus | -wh | 10:16 |
Guest39 | Maybe now the code has been updated . I will try again ,When i have time | 10:23 |
hyrcanus | Guest39: i suspect GyrosGeier's comment points to the problem, but I don't know | 10:25 |
Guest39 | @hyrcanus Thank you, I learned a new command ( apt-cache rdepends xxxx ) | 10:25 |
Guest39 | Sorry i can't understand ( the debootstrap resolver is rather primitive ) | 10:29 |
Guest39 | d-i Also use debootstrap ? | 10:30 |
rrq | yes | 10:36 |
alv1 | :D | 10:36 |
GyrosGeier | Guest39, debootstrap doesn't use apt for the initial resolution of the package list, because apt isn't available before the system is installed, and at that point the network might be unavailable | 11:13 |
GyrosGeier | (also, there is a special mode for bootstrapping different architectures, where you can't even run the apt that gets installed) | 11:14 |
GyrosGeier | instead, that is a script that just resolves package names | 11:14 |
GyrosGeier | AFAIK it ignores version numbers (assuming that a single release is consistent), and Conflicts handling is rather limited | 11:15 |
sadoon_albader[m | Guys on the default sysvinit what's the service that sets up the ttys and how do I modify it? | 14:43 |
sadoon_albader[m | I need to add an extra tty for my vm | 14:43 |
humpelstilzchen[ | Back in the old days of the republic tty were configured in /etc/inittab | 14:45 |
gnarface | it's still inittab | 14:45 |
humpelstilzchen[ | sadoon_albader: which is a textfile, so use a text editor to modify it | 14:47 |
humpelstilzchen[ | however I have no idea about your link between vm and a tty | 14:47 |
sadoon_albader[m | Oh that is excellent | 14:47 |
sadoon_albader[m | Found it | 14:47 |
sadoon_albader[m | Thanks! | 14:47 |
sadoon_albader[m | humpelstilzchen[: It's just the qemu tty that you can access in spice/virt-manager by switching from graphical display to serial | 14:48 |
sadoon_albader[m | Apparently on this system it goes to hvc0 | 14:48 |
sadoon_albader[m | I manually ran agetty as root on hvc0 and it worked so I just need to copy paste a line from inittab and modify it :D | 14:49 |
sadoon_albader[m | It's also apparently exposed to the host machine through /dev/pts/* but I haven't tried yet | 14:50 |
sadoon_albader[m | I need this because on qemu 5.2 (devuan chimaera) when you use virgl the bootup sequence is laggy until you start X | 14:51 |
sadoon_albader[m | newer versions in ceres have this fixed | 14:51 |
dormito | is there any tooling for scripting/automating devuan installs? If so anyone have a link, or a good search term? | 15:54 |
gnarface | the term used is "preseeding" | 15:56 |
gnarface | should still work the same as debian afaik | 15:56 |
dormito | gnarface: thanks, I'll look for that :) | 15:56 |
gnarface | dormito: wait, there's also refracta | 15:56 |
gnarface | might be easier to use | 15:56 |
gnarface | not sure | 15:56 |
gnarface | the live image is based on refracta and i think it might be able to do this too | 15:57 |
dormito | ok, I'll lookup both | 15:57 |
gnarface | preseeding is an old feature of the netinstaller where you just feed it a debconf state file | 15:57 |
brocashelm | i use refracta for almost two years so far. the defaults are more to my liking | 17:08 |
furrymcgee | I made preseed and netboot with QEMU https://furrymcgee.github.io/Debian.html , https://furrymcgee.github.io/QEMU.html | 17:26 |
james11381 | Hello from Indiana. I am trying Pidgin again on Linux - anyway to make the text input box on IRI bigger>> I only see the lower part of the words I type. | 21:11 |
james11381 | I thought someone would have fixed that over time | 21:12 |
dgamer69 | https://developer.pidgin.im/ticket/5296 | 21:13 |
dgamer69 | there's a plugin that enable's that functionality | 21:13 |
james11381 | dgamer69 - would you have the link? | 21:15 |
dgamer69 | https://developer.pidgin.im/ticket/5296 | 21:15 |
james11381 | thanx | 21:15 |
dgamer69 | ye | 21:16 |
guest3525 | Hi. I have a problem with some program, taking up my disc space in a tremendous pace. What can I use, and how, to check wht causes this issue? | 21:35 |
guest3525 | Could I use some file search tool? On the Windows I could use "everything" to list everything, and then sort it according to the modification time. How can I do something like this with Linux? | 21:38 |
hyrcanus | guest3525: locate | 21:40 |
hyrcanus | locate - maintain and query an index of a directory tree | 21:40 |
hyrcanus | there are a few variants but we seem to have converged on mlocate | 21:41 |
Guest11 | Ok. So how exactly would I have to use this, to list all, or at least a number of the newly modified/created files with this? | 21:44 |
rwp | Though 'locate' is good it is a daily compiled file name database and not about disk space. | 21:45 |
Guest11 | So what should I do? | 21:46 |
rwp | Guest11, I like the terminal command program "ncdu" which is a curses interactive du explore tool. | 21:46 |
hyrcanus | soryr i needed to scrollback | 21:46 |
rwp | apt-get install ncdu | 21:46 |
hyrcanus | oh new to me ty rwp | 21:46 |
hyrcanus | i usually find large files with find . -size +100M | 21:46 |
rwp | There are also other graphical mouse based tools. But I am a CLI type of person so I like ncdu best. | 21:46 |
hyrcanus | or large files modified since yesterday with find . -size +100M -mtime -1 | 21:48 |
rwp | A venerable old graphical tool is xdu used like "du | xdu" and then after it runs click around on it. (Developed with our tax dollars out of arl.army.mil. <smile>) | 21:48 |
rwp | +1 for using find as hyrcanus is describing too. | 21:48 |
rwp | For the mouse graphical folks I hear they like "qdirstat -- Qt-based directory statistics" available in the repos but I didn't like it myself. | 21:51 |
Guest11 | Can I list the newly created/modified files with some of those tools? | 21:54 |
hyrcanus | not bad, ncdu | 21:55 |
hyrcanus | this will be a daily driver for me thx rwp | 21:56 |
hyrcanus | with find yes, Guest11 | 21:56 |
hyrcanus | 'find' | 21:56 |
rwp | Guest11, Using 'find' as hyrcanus described is best to find new large files. Example find files larger than 100MB and modified in the last 1 day: find . -size +100M -mtime -1 -ls | 21:57 |
rwp | Due to historical creation by meeting a design specification, find has a different syntax than most programs. But it is still good. | 21:58 |
rwp | +100M means files larger than 100M, due to the + leading the option. | 21:58 |
rwp | The -mtime -1 means modification times, -1 in the last day, due to the - leading the option meaning less than 1, and units are days by default. | 21:59 |
Guest11 | Oh...I just found in the user profile directory, a file named ".xsession-errors" | 21:59 |
rwp | The ~/.xsession-errors file logs all X graphical program output there. | 21:59 |
Guest11 | How can it take up 25.5 GB? | 21:59 |
rwp | Caution! Do not remove the file if it is too large! | 21:59 |
rwp | Instead "truncate" the file first. | 22:00 |
Guest11 | This is kind of a lot. | 22:00 |
gnarface | Guest11: run "iotop -a" as root and it will show you exactly what process is doing it | 22:00 |
gnarface | but it's probably Xorg... | 22:00 |
rwp | Removing a file like that won't actually free up the disk space. Because programs have their stdout & stderr attached to it. And it doesn't go away until the last program exits. | 22:00 |
rwp | Instead if you want to free that space _now_ it is better to truncate it now. ": > .xsession-errors" will do it by using shell redirection to truncate the file. | 22:01 |
rwp | And that will free up the space immediately. | 22:01 |
rwp | Then I expect that it is so large because something was spewing there until the disk filled up. | 22:01 |
hyrcanus | what's the : ? | 22:01 |
hyrcanus | not echo "I like turtles" > .xsession-errors ? | 22:01 |
rwp | After truncation then "tail" the file with "tail -F .xsession-errors" and see what it is printing at the end. Since I expect the problem might be continuing. | 22:01 |
rwp | The ":" is a shell idiom. It is equivalent (mostly) to "true" and does nothing successfully. Often used for these types of almost noop actions. | 22:02 |
peterrooney | hyrcanus: it's a command built in to bash that does nothing | 22:02 |
hyrcanus | interesting ty | 22:02 |
peterrooney | hyrcanus: many shell constructs /require/ some command to be present | 22:02 |
rwp | With bash it isn't needed at all. "> .xsession-errors" will work just fine too. | 22:02 |
rwp | But being the pedantic sort of person that I am I try to always play by the portability rules. And so... : is often used! | 22:03 |
hyrcanus | i wrote some funstuff in bash but the scrolling cpu use took too much time ▃▄▃▄▄▅▆▆▅▅▃ | 22:05 |
hyrcanus | was going to do that for temp, power drain, cpu and memory | 22:06 |
hyrcanus | there's probably an efficient way to iterate through a ringbuffer or copy strings with offsets | 22:06 |
rwp | Just because some can do something does not mean they should do something. :-) | 22:06 |
hyrcanus | mhm i'll do it in a fork of 'top' sometime | 22:07 |
rwp | hyrcanus, You are aware of 'htop' ? FTW! | 22:07 |
hyrcanus | not a fan | 22:08 |
rwp | The memory usage bar graph at the top of htop is worth everything. I want just that part in a standalone command. | 22:08 |
Guest11 | I used tail -F on this file, but it didn't print anything | 22:09 |
hyrcanus | thought it was lowercase f | 22:10 |
rwp | Whew! Good. Then whatever it was has stopped. But having something in an infinite loop printing there is often a reason it has filled up the disk. | 22:10 |
rwp | Either tail -f or tail -F will mostly do the same thing. But -F continues to follow the file if the file is rotated. | 22:10 |
hyrcanus | wow | 22:10 |
rwp | So for example "tail -F /var/log/syslog" will follow the new file after logrotate has rotated the file and a new file put into place. | 22:11 |
rwp | While "tail -f /var/log/syslog" will remain attached to the previous file after rotation and you won't see the new stuff there afterward. | 22:11 |
rwp | "tail -f" is the original traditional form of the command. The -F was a GNU extension, but I think now available everywhere. Let me look... | 22:12 |
rwp | "tail -F" is not POSIX standard (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tail.html) but available in NetBSD and FreeBSD so probably portable enough for mortals. | 22:13 |
hyrcanus | i am so used to du -s * |sort -n | 22:25 |
hyrcanus | can i make * include .files in the expansion | 22:25 |
hyrcanus | cause i hate having to do like rm .[a-z][A-Z] or something | 22:26 |
peterrooney | hyrcanus: yes, in bash. man bash # search for dotglob; | 22:31 |
hyrcanus | thank you | 22:32 |
peterrooney | hyrcanus: yw. also, /join #bash and read the guide by lhunath & greycat | 22:33 |
hyrcanus | i'm scared to join #bash | 22:33 |
sixwheeledbeast | because? | 22:33 |
hyrcanus | i used to ask too many easily findable questions :) | 22:34 |
peterrooney | i feel it. they got so little patience for questions covered in the guide, and none for questions covered in the man page. | 22:35 |
rwp | The #bash channel can be a little harsh too. | 22:36 |
rwp | hyrcanus, Instead of "*" use either "." or nothing in the case of du as it will default to dot if nothing is specified. | 22:36 |
rwp | Also, a hack that mostly works if one wants *only* dot files is ".??*" which isn't perfect but is so fast and easy to type that I just ignore that it isn't perfect. | 22:37 |
hyrcanus | du with no params recurses though | 22:37 |
rwp | "?" does not match a '.' and so .??* avoids ".." avoiding going up a directory. And the second " in "" matches any single non-dot character. | 22:37 |
hyrcanus | oh nice | 22:37 |
hyrcanus | thanks! | 22:37 |
rwp | du with a param that matches a directory recurses though, so I assumed that was what you wanted. | 22:38 |
rwp | Anyway... ".??*" won't match a file "...foo" for example. | 22:38 |
hyrcanus | don't have those | 22:40 |
hyrcanus | du -s * .??* |sort -n << and i'm a happy camper | 22:40 |
rwp | Also, instead of "*" if you have a file that starts with a '-' it will be read as an option. Better to always use "./*" to avoid that possibility entirely. | 22:40 |
hyrcanus | hm or i could add -- | 22:41 |
rwp | Yes. Either way. I just find the -- a little ugly. And I learned the ./* thing before -- was available. | 22:41 |
hyrcanus | nice. i don't allow ^- anyway | 22:42 |
rwp | I have seen people purposefully place a -i as a file so that "rm *" will pick up "rm -i" and avoid a nasty event. | 22:42 |
hyrcanus | clever | 22:42 |
rwp | But I have also seen people mistakenly have a file -f from an accidental creation and it bypasses the first thing. | 22:43 |
hyrcanus | :D | 22:43 |
hyrcanus | i've had about three accidental rm's in the past 6 years | 22:43 |
hyrcanus | that glorious space before * | 22:43 |
rwp | It's good to test your backups every so often. | 22:44 |
hyrcanus | mhm | 22:44 |
hagbard | Why not simply a bash alias for rm=rm -i ? | 22:44 |
hyrcanus | that'd be very annoying | 22:44 |
rwp | That's a default alias for root on some systems. I find it very annoying. | 22:44 |
hagbard | uhm, i meant -I, that's not so annoying | 22:45 |
peterrooney | hagbard: that's preferred, but it is commented out by default in devuan's /etc/skel | 22:45 |
peterrooney | it's the second thing I attend to in a fresh install | 22:45 |
peterrooney | ...and you can always do /bin/rm to skip the -i | 22:46 |
hagbard | "prompt once before removing more than three files, or when removing recursively; less intrusive than -i, while still giving protection against most mistakes" | 22:46 |
rwp | Also \foo avoids aliases for foo too. But I hate always needing to \rm \cp \mv \rsync everything. | 22:46 |
peterrooney | rwp: as root, it's a small insurance fee. I accidentally did a 'dd' over an external USB drive last week that I thought i had unplugged. | 22:50 |
peterrooney | now i'm tempted to alias dd='echo heck no what are you thinking' | 22:51 |
rwp | dd is a command so powerful it can only be used for Ultimate Good or Ultimate Evil. | 22:56 |
rwp | I often only run dd as non-root. First I "chown floppy /dev/sdf" the device I want to write to and then double check three times, then run dd as non-root to it. | 22:59 |
hyrcanus | nice | 23:08 |
sixwheeledbeast | data destroyer... | 23:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!