| unclouded_ | `su - $username --command='stty -a'` shows "speed 38400 baud; rows 55; columns 119; line = 0;" (i.e. the correct terminal size) | 00:00 |
|---|---|---|
| rwp | For me in screen on daedalus with screen 4.9.0-4 my TERM is set to "screen". | 00:01 |
| rwp | Also the shell usually sets LINES and COLUMNS from the tty driver (after a SIGWINCH signal window change) and that can override. | 00:03 |
| rwp | Look at "echo $LINES $COLUMNS" to see what the shell thinks the size is set to. | 00:03 |
| unclouded_ | Hmm. Using TERM=screen, `su - $username --command='echo $TERM' shows "screen" but echo $COLUMNS with `su` is blank | 00:03 |
| rwp | And verify that those are NOT exported. Try "printenv LINES COLUMNS" and it should not print anything since the variables are not exported. | 00:03 |
| unclouded_ | (unset) | 00:03 |
| rwp | Bash? Or a different shell? | 00:04 |
| rwp | I am just asking all of these questions so I can understand what is and what is not. Both are important. | 00:04 |
| unclouded_ | $SHELL=/bin/bash | 00:04 |
| unclouded_ | So it is good that COLUMNS is unset when I do `su - $username...`? | 00:05 |
| rwp | Yes. Environment variables are static. If it is set then it will freeze the override at that size. | 00:05 |
| rwp | When terminal emulators are resized the tty driver sends a SIGWINCH to the process group. Things that need to react to the size change then react and change size. | 00:06 |
| rwp | I think most programs query the tty driver for the size (reported from stty -a) and then react appropriately. Bash sets the internal variables LINES and COLUMNS for its own use. But don't export them. | 00:07 |
| unclouded_ | OK, that makes sense. I'm not resizing the terminal emulator though, it just seems that mutt uses 80x25 when I run it with "su --command" but not if I "su - $username" first and *then* run mutt | 00:08 |
| unclouded_ | but is COLUMS set when a shell starts? | 00:08 |
| unclouded_ | (as well) | 00:08 |
| rwp | Yes. When the shell starts up it sets the internal variables LINES and COLUMNS. And many programs accept those as overrides. Look at dpkg for example. | 00:09 |
| unclouded_ | When I "su" first, I notice that $COLUMNS is set for the new shell | 00:10 |
| unclouded_ | If I "su --command=mutt", is no new shell involved, so $COLUMNS would be unset? | 00:10 |
| unclouded_ | As well as showing 80x25, ^Z doesn't work when mutt is launched this way, so I can't even background to see what variables are set | 00:11 |
| rwp | mutt should be reading the terminal size from the tty driver the same as other curses/slang programs. | 00:12 |
| unclouded_ | It definitely accepts the override like you said: `su - $username --command='COLUMNS=119 mutt...` uses the full width | 00:12 |
| rwp | I was asking questions about LINES and COLUMNS because you said they were incorrect for you. Therefore I was looking at the things that override the correct value. | 00:13 |
| rwp | But you also said TERM was screen.xterm-256color too. I don't know how that happened either. I don't see that here. | 00:13 |
| unclouded_ | Sorry, I misled. They are either unset, or correct, depending on whether "su --command" is used | 00:13 |
| rwp | Also the man page for screen describes in the TERM section that it sets it to "screen" and other things but does not mention screen.xterm-256color making me think that is a local override on your side of things somewhere. | 00:15 |
| unclouded_ | What is a bit strange, is that this was OK on beowulf and chimaera | 00:15 |
| unclouded_ | Hmm, ok. I'll have a look for that. I don't remember messing with $TERM at all, except querying it in bashrc.local | 00:16 |
| rwp | It looks okay to me on daedalus too though. | 00:16 |
| unclouded_ | mutt is ok for me if I "su - $username" first to a new shell and then run mutt, just not if I "su - $username --command='mutt..." | 00:17 |
| unclouded_ | after I reboot, I like screen to start up all the mutts from .screenrc | 00:18 |
| rwp | I am pretty sure there will be a difference between "su - user" followed by "mutt" over "su - user -c mutt" because the first allows the shell to act as a login shell and load the full environment and the second one will do something different. | 00:19 |
| rwp | I was trying to remember but a month ago someone had reported a problem with btop++ in screen that produced garbled characters. | 00:20 |
| unclouded_ | makes sense. Although `su - $username --command='bash -c "mutt ..."'` also presents as 80x25 | 00:20 |
| rwp | I would also test using vi or emacs (pick your favorite editor) to verify that it isn't something in mutt but something outside of it. | 00:21 |
| unclouded_ | OK, will do. I just thought of strace to see if mutt really is running "stty -a" | 00:22 |
| rwp | It won't be running stty -a but probably ioctl(0, TCGETS, struct address) | 00:23 |
| unclouded_ | Interesting. 2700 lines of trace, but no trace of "stty". Doesn't look like mutt is running stty | 00:23 |
| blockhead | would guess LANG=C btop++ would be a workaround to prevent oddball characters? | 00:23 |
| unclouded_ | OK, I see the "TCGETS" stuff | 00:23 |
| rwp | blockhead, Actually no! That made it worse. I had to force en_US.UTF-8 in my case to get it to start. If LANG=C then it complains and fails to start. | 00:24 |
| blockhead | thought this was off-topic. sorry | 00:24 |
| blockhead | oh, weird | 00:24 |
| rwp | And normally I would have had en_US.UTF-8 set but I had spun up a VM specifically to test it and it was mostly unconfigured. If LANG is not set then things default to C/POSIX. | 00:24 |
| rwp | We are on topic here with a technical debug session of screen and window size. It's not off-topic. | 00:25 |
| unclouded_ | Not sure how to interpret the ioctl call. It returns 0. There's only the one call with 0 as the first parameter, the rest are with 1 | 00:26 |
| rwp | unclouded_, Another thing I would try is that I would test in a completely clean default empty environment. Either by creating a new user and logging in there for the test or by moving all of my personal dot files out of the way. Just for testing this. Since often we have done something there that we have long forgotten about. | 00:26 |
| unclouded_ | I hear that. I've forgotten a great many things. | 00:27 |
| rwp | The ioctl call will return data in one of the variable structures. It will be hard to interpret. If you are using strace then try "strace -v -e ioctl" on it. The -v will give more data about the structure. | 00:28 |
| rwp | For example "strace -v -e ioctl stty -a" will give a nice short bit of output with the flags in hex. | 00:29 |
| unclouded_ | Unfortunately, running mutt as a newly created user results in the same issue | 00:29 |
| rwp | Weird! | 00:29 |
| rwp | Do things improve if you resize the window? | 00:29 |
| rwp | Resizing the window will send a SIGWINCH to the process group and that should trigger them to re-read window sizes and to react to it. | 00:30 |
| rwp | That has sometimes caused things to reset to a working size when they originally started off incorrectly sized. | 00:30 |
| unclouded_ | No, sadly not. The one thing that is weird is that I'm running i3, so I can't really resize, but full-screen and back resizes the mutts that were started after "su -" | 00:32 |
| unclouded_ | and not the one that is stuck at 80x25 | 00:32 |
| unclouded_ | It must be receiving SIGWINCH I guess and then doing the same incorrect thing that it did at startup | 00:32 |
| rwp | Hmm... I was able to reproduce your behavior here. And I really did not expect that! | 00:33 |
| unclouded_ | So `su - $username --command='mutt ...` gives you 80x25 too? | 00:34 |
| rwp | I think the problem is that when using su with --command=mutt that the tty device is left owned by the original user and cannot be accessed by mutt. | 00:34 |
| rwp | Try this: su - $username --command=/bin/bash | 00:35 |
| rwp | That will give you a shell. It will complain that it can't set up job control, due to the tty problem. Then look at the tty. | 00:35 |
| unclouded_ | Nicely done: "cannot set terminal process group (-1): Inappropriate ioctl for device" | 00:35 |
| rwp | "tty" returns something like /dev/pts/20 or something. "ls -ld $(tty)" and it will show that it is owned by root in my case and I cannot read it. | 00:35 |
| unclouded_ | "crw--w---- 1 root tty 136, 10 Dec 4 12:36 /dev/pts/10" | 00:36 |
| rwp | Because mutt run like that cannot read the tty it means that the ioctl() calls (stty -a) cannot get the actual terminal size. Therefore it can only fall back to 80x25 for the TERM type. | 00:36 |
| unclouded_ | I don't think my user is in the tty group though | 00:36 |
| rwp | It should not be in the tty group. Don't "fix" things that way. :-) | 00:36 |
| unclouded_ | OK, won't :-) | 00:37 |
| unclouded_ | Just for fun, I did "chmod 666 `tty`" and tried to run mutt with su and it still showed 80x25 though | 00:39 |
| rwp | At least we are at the root cause of the problem. Off the top of my head I don't immiedately know the solution. And I must go and start work on fixing dinner in a moment. | 00:39 |
| rwp | Are you opposed to using sudo? I tried it with sudo and I get a new pty device. Which solves the problem. | 00:39 |
| unclouded_ | OK. Thanks for pointing me in the right direction, and for teaching some commands that I didn't know before | 00:39 |
| rwp | Try: sudo -i -u username mutt | 00:39 |
| unclouded_ | OMG that works. I guess it will work from .screenrc too! | 00:41 |
| rwp | The key point there is that it plumbs in a different tty device. A tty device that then you the switched to user then owns. | 00:42 |
| unclouded_ | That is some deep knowledge. I mostly don't have to think about ttys | 00:44 |
| rwp | Experience and treachery will always triumph over youth and enthusiasm! :-) | 00:44 |
| unclouded_ | Excellent, I'm keeping that quote! :D | 00:45 |
| rwp | That's one I created too. You can attribute that one to me. --Bob Proulx | 00:45 |
| rwp | I hate to mention this but I remember when SIGWINCH was added to the kernel. It was a HUGE deal! Before then resizing terminals had to be set up manually. PITA! | 00:45 |
| unclouded_ | OK, awesome. Using sudo does indeed work from .screenrc | 00:46 |
| unclouded_ | Even if I don't resize my terminal much because it's i3 and it's in the left-hand half of the screen, I really appreciate SIGWINCH when changing termnal fonts! | 00:47 |
| rwp | I use i3 as well. But even tiling window managers must resize things. As things are split left-right or top-bottom. As windows are stacked or tabbed. | 00:48 |
| rwp | I most often used stacked windows. Which means that one line is consumed for the window title bar every time I stack another terminal. | 00:48 |
| rwp | And in tmux (I used screen for years and years but am using tmux these days, try it you will convert too) then every time I split a pane then that resizes too. | 00:49 |
| unclouded_ | Yes, that one gets me. When another window opens in the LHS then the terminal changes size. | 00:49 |
| unclouded_ | Thanks, I'll check out tmux | 00:50 |
| rwp | Very happy to hear that we got to the root cause of your problem and got a workaround. With that my job here is done. Time for me to go fix dinner! :-) | 00:51 |
| unclouded_ | Like Ben Kenobi: My work here is done :) | 00:51 |
| mason | '/wl | 01:04 |
| u-amarsh04 | had an obscure problem with the side-effect of not seeing a shell at boot-up: had manually put one firmware file in /lib/firmware/radeon, and firmware was moved to /usr/lib/firmware/radeon EXCEPT the file I manually added (for an old card no longer in use). HOWEVER, the old /lib/firmware/radeon directory was used by update-initramfs and old initramfs, and the firmware for the current gpu wasn't there | 02:35 |
| chomwitt | i noticed that somme mirrors dont have a devuan/debian folder . Does that make them slower ? | 07:32 |
| brocashelm | chomwitt: which mirrors? could you link them here so onefang can check? | 07:37 |
| chomwitt | sure one moment | 07:38 |
| brocashelm | maybe create a paste url and link it here | 07:39 |
| onefang | Damn, I have to do some work now? | 07:39 |
| brocashelm | :( | 07:39 |
| chomwitt | http://mirror.koddos.net/devuan/ | 07:39 |
| chomwitt | brocashelm, what did you mean by ' create a paste url' ? | 07:41 |
| brocashelm | chomwitt: i meant by using a paste site like paste.debian.net or dpaste.org | 07:41 |
| brocashelm | depending on how many you found | 07:42 |
| chomwitt | http://deb.devuan.nz/ | 07:42 |
| onefang | Koddos isn't one of the fastest, but not one of the slowest. | 07:42 |
| brocashelm | makes it easier to refer to | 07:42 |
| onefang | Ah there's a list? | 07:42 |
| onefang | Generally there's two reasons for having a /devuan. One is that they might mirror more than one distro. If they also mirror Debian ,then they server both sorts of packages. | 07:43 |
| chomwitt | no i dont have a list! i just bumbed onto one and i was under the impression that is not mandatory to include a part of the debian repe | 07:43 |
| chomwitt | s/repe/repo | 07:43 |
| onefang | Another is coz they have both packages and files mirrored, with the ISO files on /devuan-cd. | 07:44 |
| onefang | Nothing to do with speed. | 07:44 |
| onefang | Oddly koddos has Devuan, but not Debian. It has other distros and stuff though. | 07:46 |
| chomwitt | in a Package's Filename i see pool/DEVUAN/main/pathtoFoo.deb but in a repository i see DEVUAN_ARCHIVE_ROOT/devuan/pool/main/pathtoFoo.deb . Is that due to a rewrite rule in the www server ? | 10:08 |
| chomwitt | also another queston. Where DEVUAN_ARCHIVE_ROOT/devuan/dists is used ? I mean if the usual is to put in sources.list deb http://deb.devuan.org/merged | 10:11 |
| chomwitt | or DEVUAN_ARCHIVE_ROOT/devuan/dists is used an an input to amrpolla to make the merged repo ? | 10:12 |
| rrq | try search on 'debian repository structure' | 10:56 |
| chomwitt | ok rrq . i am on it. | 11:07 |
| al1r4d | how is going all? | 11:15 |
| u-amarsh04 | Am I allowed to express my "told you so" opinion that /usr merge would break things in strange and wondrous ways during transition? | 14:54 |
| gnu_srs1 | Did you see that Debian now use foul play with usrmerge:, see #1056980 and #813: | 15:00 |
| gnu_srs1 | netcat-traditional: Binary files moved to /usr/bin but the postinst script keeps /bin making it un-installable. | 15:00 |
| u-amarsh04 | yes, that's my report | 15:03 |
| hagbard | My quick and dirty workaround for netcat-traditional was a hardlink for the affected file. | 15:04 |
| u-amarsh04 | gnu_srs1 if they were consistent, it wouldn't be so bad, but designing something to deliberately break on a non merged system...? | 15:07 |
| gnu_srs1 | Does not changing the postinst file work? | 15:07 |
| gnu_srs1 | Time to fork that package in Devuan :( | 15:08 |
| u-amarsh04 | that's why I reported the bug | 15:12 |
| u-amarsh04 | (in Devuan as #813, quoting Debian #1056980) | 15:12 |
| fsmithred | Better to get it fixed upstream than to fork it. | 15:13 |
| gnu_srs1 | fsmithred: Flagged as wontfix in Debian bug #1056980 :( | 15:18 |
| fsmithred | wtf? | 15:19 |
| gnu_srs1 | I built netcat on a Hurd box and changed the postinst path to /usr/bin. Installed nicely :) | 15:21 |
| u-amarsh04 | the /usr merge unintended consequences: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057399 | 16:51 |
| djph | "unintended" | 16:53 |
| DashiePie | "nothing is sacred, everything is permitted" | 16:59 |
| mason | u-amarsh04: What's video output, measured against the immense good of laying things out more like Solaris? | 17:41 |
| u-amarsh04 | I haven't used Solaris since 2002? | 17:42 |
| rwp | My search fu is failing me. Every so often I find this in my Devuan syslog "sshd[5326]: pam_elogind(sshd:session): Failed to release session: Interrupted system call". | 20:52 |
| rwp | Though I do find other people asking the same question. https://askubuntu.com/questions/1150195/ssh-failed-to-release-session | 20:52 |
| rwp | Anyone know what causes this? I am about to add it to my logcheck filter ignore as unresolved and unknown noise. But I would rather fix it if it is something that can be fixed. | 20:52 |
| mason | rwp: I believe that's a systemd-specific issue, as OpenSSH doesn't depend on systemd-logind itself. I'm guessing it's a bug somewhere in elogind, but I only have the guess. | 20:56 |
| gnarface | can't say i've seen that happen here | 20:56 |
| rwp | No systemd on my system! | 20:56 |
| mason | rwp: elogind, a rose by any other name | 20:56 |
| gnarface | though i'm not using elogind either, so that could have something to do with it | 20:56 |
| rwp | I'll give you the rose analogy mason. | 20:57 |
| gnarface | rwp: you sure it's not something mundane like closing a terminal without disconnecting the ssh client first? | 20:57 |
| rwp | This system is running libvirt and libvirt dependencies pulled in elogind. | 20:57 |
| mason | rwp: There's some discussion of it here: https://github.com/systemd/systemd/issues/18817 | 20:58 |
| rwp | OMG! If I "apt-get purge -s elogind" it will let me do it without removing libvirt! I guess that was a previous release version dependency and no longer needed. My machines are all upgrades from older versions. | 20:59 |
| mason | \o/ | 20:59 |
| rwp | This is what the purge action looks like. I don't need anything that is being removed. https://paste.debian.net/plain/1300174 | 21:00 |
| rwp | That's my action plan now! But I will want to reboot after doing it to make sure all is well and I want to wait on that reboot. I'll do it later. | 21:00 |
| mason | rwp: You might find that accessing libvirt without polkit leads to some excitement if you're not root. Not sure if seatd would work there. | 21:01 |
| mason | If you only access it as root, you're likely fine. | 21:01 |
| rwp | This machine has one purpose and that is to host VMs for me. I only ever interact with it as root. | 21:01 |
| rwp | But I will keep that in mind for another system which has XFCE on it and does interact from the user DE. | 21:02 |
| rwp | Thanks for the second brain on this! | 21:03 |
| rwp | I guess I should say that I am not sure consolekit which is pulled in to replace elogind will really be significantly better. But it will be different. WCGW? | 21:08 |
| mason | heh | 21:08 |
| rwp | I purged elogind, installed consolekit, rebooted, and all is well. I'll see how that goes. I need to upgrade that system anyway at some point. | 21:19 |
| mason | Cool. | 21:24 |
| rwp | Looking at things a little bit more I might possibly have been better off by simply disabling PAM in sshd_config as I don't need it. That would have avoided elogind and the associated bugs but left elogind for use by libvirt. | 22:01 |
| plumpanda | I need advice on how to narrow down a problem I'm having. I'm on devuan testing (excalibur) and most, but not all, of my DV cameras don't connect via firewire correctly. I normally use dvgrab to record from camera to disk and that is failing ("no camera exists"). One of my cameras works as intended with this exact same workflow, and on a devuan stable live USB all cameras work as expected. I also tried booting testing into the old 6.1 kernel I still had | 22:57 |
| plumpanda | in grub just in case, and it did not work there either. As far as I know dvgrab and the other firewire components have not been updated in eons, so I'm not sure why it's broken. | 22:57 |
| plumpanda | Only other difference is I see it detect the device in dmesg twice, but it's not clear if it's failing, just that it creates the device again (so probably something failing before dvgrab has a chance to touch it??) | 22:59 |
| plumpanda | oh, it works as root. Well shoot. What would be in charge of setting the permissions on the device when it's configured? | 23:09 |
| plumpanda | (this may also be some quirk going from a live boot to a normal install) | 23:10 |
| plasma41 | plumpanda: maybe polkit- and/or eudev-related? | 23:10 |
| plumpanda | Possibly, I'll have to dig and look. I've never had to configure anything in the past, hopefully I can lift a config from an old install (of a non devuan OS) | 23:12 |
| plumpanda | fwiw I'm just running sysvinit, haven't changed that from out of the box. | 23:14 |
| plasma41 | That shouldn't^TM make a difference. | 23:17 |
| gnarface | plumpanda: it's udev/eudev that handles permissions on device creation | 23:19 |
| al1r4d | Errors were encountered while processing: | 23:22 |
| al1r4d | netcat-traditional | 23:22 |
| al1r4d | E: Sub-process /usr/bin/dpkg returned an error code (1) | 23:22 |
| al1r4d | What happened? | 23:22 |
| gnu_srs1 | al1r4d: Scroll up: (15:01:05) gnu_srs1: Did you see that Debian now use foul play with usrmerge:, see #1056980 and #813: | 23:24 |
| gnu_srs1 | (15:01:05) gnu_srs1: netcat-traditional: Binary files moved to /usr/bin but the postinst script keeps /bin making it un-installable. | 23:24 |
| al1r4d | hmm | 23:26 |
| al1r4d | Ok, i will hold the package | 23:33 |
| plumpanda | gnarface, sounds like I'm writing a rule for it then. Thank you | 23:38 |
| gnarface | plumpanda: you might not need to. if the group ownership isn't set to root anyway, you might be able to just add yourself to that group safely | 23:40 |
| gnarface | like, if the group is already the "video" group, you probably want to be in the video group anyway | 23:41 |
| plumpanda | It's (/dev/fw1) not getting any group permissions right now | 23:41 |
| plumpanda | but I've never had to mess with udev before so this might be a lack of understanding on my part | 23:41 |
| gnarface | it might be an accidental regression, you are on testing, after all | 23:42 |
| plumpanda | unrelated to that: where did /sbin/mount.nfs go? D: | 23:42 |
| gnarface | uh, not sure. maybe in the package "nfs-common" | 23:43 |
| gnarface | you could try apt-file search but if it's a symlink created by postinst script it might not show up | 23:43 |
| plumpanda | That's installed, and has been. I've had a network mount that was working fine. Today after rebooting for testing it won't mount and sure enough that file is missing | 23:43 |
| gnarface | worth a try maybe though | 23:44 |
| gnarface | also, see if "mount -t nfs" still works | 23:44 |
| plumpanda | Confirmed that it's supposed to just point to /sbin/mount.nfs per apt-file. The file is also present on my other devuan testing system, weirdly. Which is also up to date, or at least I did apt upgrade on it earlier today | 23:47 |
| plumpanda | and nfs-common is still installed | 23:48 |
| plumpanda | looks like nfs-common updated "1:2.6.4-2 amd64 [upgradable from: 1:2.6.3-3]" | 23:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!