| gnarface | hmm, i really thought that linux-source package had the debian/ directory... | 02:46 |
|---|---|---|
| fsmithred | gnarface, me too, but i see it's not. Maybe this? https://salsa.debian.org/kernel-team/linux | 03:01 |
| gnarface | hmm, no, it's definitely there, or at least was last time i downloaded it | 03:06 |
| gnarface | my on-disk copy of 6.1.85 still has it | 03:06 |
| gnarface | but maybe the problem is i mistakenly suggested "apt-get install linux-source" instead of "apt-get source linux-source" which is what is actually in my history on that machine | 03:07 |
| gnarface | i can't imagine why there'd be a difference for that particular package, but this part of the way debian does things never quite made sense to me anyway | 03:08 |
| gnarface | well, anyway, if Alverstone comes back, someone please suggest to try it again with "apt-get source linux-image" instead | 03:08 |
| fsmithred | oh right... apt-get source, not install. I did it wrong. | 03:36 |
| gnarface | did you just try again? is it still there or did they actually remove it from the most recent versions? | 03:37 |
| fsmithred | yes, the correct command gives the correct result | 03:39 |
| fsmithred | and wow that debian dir is full. | 03:39 |
| gnarface | yea there's a huge stack of patches in there, and while they do sometimes mysteriously break other things, over time i've noticed they usually mysteriously fix them | 03:40 |
| gnarface | lots of backported security stability and bug fixes | 03:41 |
| gnarface | ymmv i suppose | 03:41 |
| gnarface | hmm, i could have sworn i had to get that package specifically with "apt-get install ..." before too though, weird | 03:49 |
| onefang | firefox-esr locked up it's window, and I can't kill it. Not even killall -KILL worked. | 06:02 |
| onefang | I could reboot, but I have another process that'll take hours to complete that I can't interrupt. | 06:03 |
| gnarface | isn't it killall -9? | 06:04 |
| gnarface | no, wait, killall works different | 06:04 |
| gnarface | do "kill -9 [pid]" | 06:04 |
| gnarface | then wait a couple seconds | 06:04 |
| debdog | "kill dash nine | and the process is mine" heehee | 06:04 |
| gnarface | if there's multiple firefox processes, put them all on the command-line in a list | 06:04 |
| onefang | Except there's 152 of them. lol | 06:05 |
| gnarface | woah, that's too many | 06:05 |
| gnarface | something definitely went wrong | 06:05 |
| debdog | you'll have to find the one with the lowest PID | 06:05 |
| gnarface | "ps aux --forest" might help, there should be a hierarchy | 06:05 |
| gnarface | the controlling one won't necessarily be the lowest PID, just probably | 06:06 |
| onefang | I just locked up two terminals trying that. lol | 06:06 |
| gnarface | doh | 06:06 |
| gnarface | well, then, you could always try to pipe through cut and grep | 06:07 |
| onefang | Ah btop can show a tree, and it was already running. Killing the base one didn't help. | 06:10 |
| gnarface | only one choice then | 06:11 |
| gnarface | you gotta get them all onto one kill -9 command-line | 06:11 |
| onefang | Find something else to do for a few hours, then reboot. Or that. lol | 06:11 |
| gnarface | "killall -9 firefox-esr" didn't help? | 06:12 |
| gnarface | for some reason i seem to recall it didn't allow -9 but i'm not sure | 06:12 |
| onefang | It allows it, but doesn't do anything. | 06:13 |
| onefang | Looks like any use of the ps command locks up, but btop and pstree work fine. | 06:18 |
| gnarface | heh, what site were you using so i know not to go there? | 06:30 |
| onefang | I was 14 pages deep on the 44 comment pages about Ars Technica changing their UI. Doubt if that was the problem, I regularly read longerl comment sections there. | 06:31 |
| gnarface | hmm | 06:32 |
| gnarface | interesting problem, but at this point it might be better to just reboot it | 06:33 |
| onefang | Mostly it was lots of people making the same complaints about the excess blank space, which is my main complaint to. | 06:33 |
| onefang | Yep, already resigned to waiting out the few hours for that other thing to finish, then rebooting. | 06:33 |
| rwp | onefang, I think this one line command should send a kill to all of the firefox processes: kill $(ps -ef | awk '/[f]irefox/{print$2}') | 07:28 |
| rwp | Preview the list of processes with: ps -ef | awk '/[f]irefox/{print$0}' | 07:28 |
| rwp | If kill -9 does not kill the process then it means either 1) the parent process has not waited upon the child or 2) it is in an uninterruptible "D" state waiting for DMA I/O to complete writing into it's memory space. | 07:29 |
| rwp | Most likely it means the parent has not waited for the child. Kill the parent. Child processes are inherited by the init 1 process when their parent exits. The init 1 process waits for all and the process is then reaped. | 07:30 |
| rwp | The reason processes hang around until the parent wait(2)'s on them is so the parent can receive the exit code and status from the child. | 07:31 |
| onefang | ps command is still just hanging until I kill it. | 07:35 |
| onefang | But at least it does the honourable thing, and actually dies. | 07:36 |
| rwp | The ps command is hanging? | 07:56 |
| rwp | If so then can't really blame firefox for not being killed then. Hopefully your long running task finishes. You might have to reboot anyway. | 07:57 |
| CueXXIII | sounds like a hanging (network) filesystem | 07:59 |
| onefang | Yep, any variation of the ps command I have tried just hangs until I Ctrl-C it. | 08:02 |
| CueXXIII | does df --all hang, too? | 08:03 |
| onefang | Nope. pstree and btop are not hanging either. | 08:04 |
| CueXXIII | ok, so no fs issue probably. you can try strace ps and see, where it hangs | 08:04 |
| onefang | Time to reboot. Considering the sorts of things that are going wrong, I'm not expecting the shutdown part to go smoothly. Likely I'll have to sit through 20 TB of spinning rust getting fscked. Also have to deal with a kernel update. This'll take a while. | 08:19 |
| onefang | Seems fine now. | 09:16 |
| gnarface | impending block device failure seems possible, but could be indistinguishable from a driver bug | 09:21 |
| gnarface | firefox devolving into a heavy fork bomb also seems possible though | 09:22 |
| CueXXIII | i'm pondering whether installing a 32bit version of firefox will limit its memory hunger | 09:25 |
| onefang | Could also just have been my RAM gremlin. It tends to like firefox. | 09:28 |
| Alverstone | under runit, who runs sysv init scripts and why adding the same named service to svdir overrides that? I installed dhcpcd5 and it was being started using its /etc/init.d script, which is stupid, so I made a runit service for it and whoosh the /etc/init.d script is no longer used but my service is preferred instead | 10:00 |
| Alverstone | Who's responsible? | 10:00 |
| avir327 | Alverstone: Probably the sysv init script (line 37). | 11:24 |
| Alverstone | avir327, please be more specific which script exactly? I've never used sysvinit | 11:31 |
| avir327 | Alverstone: A quick look at the (original Debian) package shows, that the sysv init script (/etc/init.d/dhcpcd) checks for already running instances. | 11:36 |
| fsmithred | Alverstone, it would be even stupider if you installed a service and it didn't start. I guess you can blame the debian technical committee for not making all the devs write run scripts for the services they maintain. They're only required to support the default init system in debian. | 11:45 |
| Alverstone | but who the heck invokes it at all? i looked through /etc/runit/{1,2} and only /etc/rcS.d is executed by runit. Why does dhcpcd get invoked by /etc/init.d at all? It is symlinked somewhere in sysv runit stages, but why would runit care? | 11:45 |
| fsmithred | I don't know where in the code that decision gets made. | 11:46 |
| Alverstone | does runit handle it internally? | 11:46 |
| Alverstone | I can't find any documentation | 11:47 |
| fsmithred | This looks like it might help: https://salsa.debian.org/debian/runit/-/blob/master/debian/README-flagfiles | 11:50 |
| Alverstone | might be it | 11:55 |
| fsmithred | also look in /usr/share/doc/runit There are some html help pages. | 11:59 |
| fsmithred | If you can't find it, ask Lorenzo. Also, he might be interested in adding your run scripts to the runit-services package. | 12:01 |
| gnarface | Alverstone: hey just fyi if you get that linux source package with "apt-get source linux-source" instead of "apt-get install linux-source" it has a debian/ directory | 12:07 |
| gnarface | sorry if i gave you bad instructions, i remembered it wrong apparently | 12:08 |
| Alverstone | gnarface, correct, but I don't see much a point. Also, I learned that firmware still goes separately. Anyway it's easier to just build from upstream. Debian patches and etc might break something and I don't want any of that | 12:14 |
| Alverstone | I have no knowledge to test it in a sane manner | 12:14 |
| Alverstone | And I don't have a spare machine I don't mind killing for fun :D | 12:25 |
| Alverstone | fsmithred, my run scripts are nothing fancy actually, but just in case, how do I contact Lorenzo on this matter? | 12:26 |
| fsmithred | Alverstone, he'll probably reply to your forum post, but you could also file a wishlist bug report against the runit-services package. https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=runit-services | 12:47 |
| Alverstone | Can I tag people on the forum? | 14:25 |
| Alverstone | How do I check that I'm in chroot? | 14:32 |
| Alverstone | systemd has systemctl is-system-running | 14:32 |
| Alverstone | maybe by checking that /var/run is not empty? | 14:33 |
| fsmithred | Alverstone, I usually just do ls to see where I am. If I suddenly got transported to the root of the filesystem, I'm in a chroot. | 14:36 |
| Alverstone | I am hacking a script though | 14:36 |
| fsmithred | there's no private message system on the forum | 14:36 |
| fsmithred | do you recall running the chroot command recently? | 14:37 |
| fsmithred | maybe check command history | 14:37 |
| Alverstone | I am hacking a script that must determine whether it's running in chroot or not | 14:37 |
| fsmithred | oh | 14:37 |
| fsmithred | attaching som AI is probably not an option | 14:38 |
| Alverstone | a bit too involved :D | 14:39 |
| fsmithred | I would ask google. There are probably a few ways to do it, but you could be fooled if things are bind-mounted | 14:39 |
| Alverstone | people suggest using /proc/self/mountinfo | 14:41 |
| Alverstone | linuxism ofc | 14:41 |
| fsmithred | check what reboot does - when I try to do that in chroot I get an error message. | 14:41 |
| fsmithred | somehow it knows | 14:41 |
| Alverstone | calls `init 6` | 14:42 |
| Alverstone | which in turn `chmod =100 /run/runit.reboot` | 14:42 |
| Alverstone | hmm | 14:43 |
| Alverstone | a bit runit specific | 14:43 |
| Alverstone | but maybe who cares since I am going to stick to runit anyway? | 14:43 |
| Alverstone | I think I will rather use /proc. Linux specific is better than init specific and it's not like I'm going to be using BSDs anytime soon. It's not like the software is even supported for BSDs that I am hacking | 14:47 |
| fsmithred | oh, check runlevel | 14:47 |
| Alverstone | on BSDs | 14:47 |
| Alverstone | fsmithred, how? | 14:47 |
| fsmithred | have the script run the command, runlevel and look for the answer "unknown" | 14:51 |
| fsmithred | that's what I get when I do that in chroot | 14:52 |
| Alverstone | says 'N 2' | 14:54 |
| Alverstone | BTW I found a Debian utility `ischroot` which works on /proc/1/mountinfo + /proc/self/mountinfo | 14:55 |
| Alverstone | Judging by strace it's a C oneliner | 14:55 |
| Alverstone | I guess I can do that in shell :) | 14:55 |
| Alverstone | fsmithred, just so you know, I chroot devuan from debian | 14:56 |
| Alverstone | so it's systemd to runit | 14:56 |
| fsmithred | what do you look for in /proc/self/mountinfo? | 14:57 |
| fsmithred | mine has info in it - I'm in a chroot and /proc is mounted along with /sys and /dev which is a common way to do chroot | 14:58 |
| fsmithred | you could also check to see if you're in devuan - /etc/os-release or /etc/devuan_version | 15:00 |
| Alverstone | fsmithred, it might be a guess, but for the true root, the ID of the parent mount is 1 | 15:03 |
| Alverstone | damn my chroot is on different block device | 15:04 |
| Alverstone | need to put it on the same one to check! | 15:04 |
| Alverstone | 4.5 GB of rsyncing | 15:05 |
| Alverstone | yeah | 15:05 |
| Alverstone | in chroot, however, the parent mount ID is not 1. If it checks out on a chroot on the same block device as true /, then I go with this method | 15:06 |
| Alverstone | if not | 15:07 |
| Alverstone | well, life never promised anything | 15:07 |
| Alverstone | see man proc_pid_mountinfo(5) | 15:08 |
| fsmithred | no manual entry... | 15:10 |
| fsmithred | afk | 15:11 |
| Alverstone | fsmithred, man7.org. that's some weird stuff tbh why wouldn't it be distributed | 15:13 |
| Alverstone | Yep, I figured it out. If chroot is on the same block device, then there isn't / in mountinfo at all. If it's on a different block device, then it has a parent ID which is not equal to 1. Perfect. Now lets hope linux devs don't break it | 15:16 |
| kaz_ | BTW any documentation on how to decode the `sv status`? | 16:28 |
| Alverstone | BTW any documentation on how to decode the `sv status`? | 16:32 |
| rwp | Back in 2012 I filed this bug against ischroot and AFAIK it still has not been fixed: https://bugs.debian.org/685034 | 18:01 |
| rwp | It only works if /proc is also mounted. Which I almost never have mounted in a chroot. | 18:02 |
| rwp | That's just an FYI... | 18:02 |
| freem | Alverstone: what is it to decode in `sv status` ? | 18:07 |
| freem | status: $DAEMON (pid $DAEMON_PID) $(ps -oetimes $DAEMON_PID); | 18:08 |
| freem | and same for logger if any | 18:09 |
| freem | err... s/status/$STATUS/ ofc | 18:09 |
| freem | which can be various stuff, such as run, down, etc | 18:09 |
| freem | one important detail to keep in mind though is that the PID and elapsed time are for runsv's child, which is the ./run being executed. It is not necessarily the actual process image of the daemon per se | 18:11 |
| Alverstone | rwp, correct, I rely on /proc. If there is no proc, there can be no doubt it is a chroot. | 19:36 |
| Alverstone | freem, I want to exactly understand every field and I can't exactly find a man explaining it | 19:36 |
| freem | which field do you not undestand? | 19:37 |
| Alverstone | honestly? | 19:37 |
| Alverstone | I don't understand anything beyond run: | 19:37 |
| freem | yes. Only stupid questions are those which are not asked. | 19:37 |
| Alverstone | only vaguely | 19:37 |
| freem | so, "run:" is actually "${STATUS}:", it could have other values than run | 19:37 |
| freem | in this command: % sv status mpd | 19:38 |
| freem | run: mpd: (pid 4508) 19645s; run: log: (pid 4506) 19645s | 19:38 |
| freem | I have my userland "mpd" daemon (the name of the directory which contains the `run` file) in state "run" since 19645 seconds | 19:38 |
| freem | the part after the ";" are same information, but for the logger if you have setup one | 19:39 |
| freem | I have a generic logger I just reuse all the time | 19:39 |
| freem | oh | 19:39 |
| freem | and PID is the PID of the process that runsv is watching | 19:39 |
| Alverstone | I just reuse svlogd everywhere, why not? | 19:39 |
| freem | that is what I do as well :) | 19:40 |
| freem | this is the file I symlink for all system daemons for example: % cat /etc/runit/log.run | upl | 19:40 |
| freem | https://p.mort.coffee/4Xc | 19:40 |
| Alverstone | I just noticed dhcpcd writes to syslog so svlogd is redundant, but on the other hand grepping is easier with svlogd | 19:41 |
| freem | I have a slightly different one for my user stuff, since runsvdir even handles i3 here. I did that as a fun experiment, but really I should use another tiling WM for that | 19:41 |
| freem | it depends | 19:41 |
| freem | I always configure my daemons to avoid them writting to a possibly down syslog daemon | 19:41 |
| freem | quite often it requires passing a --debug flag or something, but that is also required to avoid them to double fork anyway | 19:42 |
| Alverstone | dhcpcd hasn't got configurations for syslog | 19:42 |
| Alverstone | doesn't matter, because I don't care | 19:42 |
| freem | dunno. I wrote my own stuff using busybox's udhcpcd | 19:42 |
| Alverstone | I don't wanna write my stuff. Wanna it to just work | 19:42 |
| freem | I use neither ifupdown nor network-manager here | 19:43 |
| freem | well, I can help you if you want to understand the output of sv, at least | 19:43 |
| Alverstone | I've been using dhcpcd5 for years I'm reluctant to change it, because it's very flexible and does its thing alright | 19:43 |
| freem | I don't know for every daemon existing if they handle things nicely or not though | 19:43 |
| freem | I understand | 19:43 |
| freem | and you can just have a syslogd running somewhere anyway | 19:44 |
| freem | sometimes there's no choice :) | 19:44 |
| freem | (i.e. PAM debugging) | 19:44 |
| Alverstone | if there's no syslog then dhcpcd simply doesn't write to it. It doesn't fail | 19:44 |
| freem | true | 19:44 |
| Alverstone | :) | 19:44 |
| freem | some do that as well :p | 19:44 |
| Alverstone | Some software does its own logging at all | 19:44 |
| Alverstone | independent of the system | 19:45 |
| freem | anyway, if you have a question for runit, feel free to ping me, I'll try to help. I don't say I will always be able to, mind you | 19:45 |
| Alverstone | not very smart imo, but can't fix others | 19:45 |
| freem | yes, I have had problems with such as well | 19:45 |
| Alverstone | no, if I ping you, you'll have to answer ;D | 19:45 |
| freem | i'll try, for sure :) | 19:45 |
| freem | I really like runit, and think it's a shame it's not more used | 19:45 |
| freem | it's not perfect, but every tool have it's pros and cons | 19:46 |
| Alverstone | Well I haven't got experience with runit so far but my brief acquaintance with it is a pleasant one | 19:46 |
| freem | I have been happy with it since many years now | 19:46 |
| Alverstone | systemd is a breeze actually so long as you don't try to write a service more complex that one-shot | 19:47 |
| freem | even if that means I had to write all my scripts, but... well.. most are one-liners, really | 19:47 |
| Alverstone | scripts are not hard to write in most cases | 19:47 |
| Alverstone | and I often boiled down my systemd services to scripts anyway | 19:48 |
| Alverstone | because it's easier to write a script than to understand how to use another-os-as-pid-1-daemon | 19:48 |
| freem | systemd have few nice features though: allowing daemons to report when they are ready, for example. Integration of cron in the daemon manager is not stupid neither, and dependency handling can *sometimes* be very useful | 19:48 |
| Alverstone | a few good features is no excuse for bullying me | 19:49 |
| Alverstone | :D | 19:49 |
| freem | I think most of that could be easier to handle with a daemontools' child, but... well, someone have to try and fail a few times before doing it :) | 19:49 |
| Alverstone | anyway, I'm waiting till somebody takes something like runit, adds some cool features enterprise wants, and releases it, so we can both have a good init and no systemd | 19:50 |
| freem | I actually used runit in enterprise in the past | 19:50 |
| Alverstone | apparently they want some features that are only present in systemd | 19:50 |
| Alverstone | haven't found a use case on desktop though | 19:50 |
| freem | ofc, it was because I revamped the whole "embedded" system... so that we could get many nice features *and* trivial to understand systems | 19:50 |
| freem | we're probably talking about that in #devuan-offtopic though? | 19:51 |
| freem | I'd be curious to know about those features you're talking about, I'm tinkering with runit's codebase for my own fun, since few days (making it into modern C11+POSIX-2008 for example) | 19:52 |
| dvbst | gnarface: you told me to change the stuff in /etc/rc*, so i did, and it doesnt work either way, it still teleports me to tty7 and disables me from doing anything at all on the system | 19:52 |
| freem | so maybe I could see if that requires stuff inside runit's code itself, or just some tooling on top (the most likely) | 19:52 |
| Alverstone | freem, I'll answer in offtop | 19:53 |
| freem | thanks | 19:53 |
| fsmithred | dvbst, did you do 'update-rc.d -f lightdm remove'? | 20:26 |
| dvbst | no, i just moved the files to a different place and removed the symlinks | 20:27 |
| fsmithred | or better disable instead of remove | 20:27 |
| fsmithred | and lightdm is still running? | 20:27 |
| fsmithred | you moved which files? | 20:29 |
| dvbst | idk if its running, i suspected it to be running because thats the thing that is on tty7 right after booting, i cannot verify that because i cant do anything | 20:30 |
| fsmithred | you see a graphical login screen? | 20:30 |
| dvbst | and i moved the /etc/rc*.d/*S*lightdm* files | 20:30 |
| dvbst | i do not, because i do not have the nvidia drivers installed | 20:31 |
| dvbst | i cant install them on the normal system, because it keeps switching me to tty7 and i cant do anything, and the drivers refuse to install in a chroot | 20:31 |
| fsmithred | and you can't get to a console. | 20:31 |
| dvbst | i would sudo apt purge lightdm and then sudo apt install lightdm but i know this will fuck up my system and i wont be able to reinstall | 20:32 |
| dvbst | yes i cant | 20:32 |
| fsmithred | I was going to suggest 'chmod -x /etc/init.d/lightdm' but I now think that won't help since you removed the links. | 20:32 |
| dvbst | i can add them back in | 20:33 |
| fsmithred | they won't help. I don't think lightdm is the problem, but I don't understand that low-level stuff enough to say whether you have no conole or just can't see it. | 20:34 |
| fsmithred | Oh, there's an idea. Assume you have a console login screen that you can't see and log in and type a command. | 20:35 |
| fsmithred | something that will respond with sound or reboot. | 20:35 |
| dvbst | no | 20:36 |
| fsmithred | you tried booting with 'nomodeset' in the boot command? | 20:37 |
| dvbst | no i havent, i can try that | 20:37 |
| fsmithred | that might give you a console | 20:37 |
| dvbst | oh yea, i think i might be able to install the drivers with booting in single user mode or something like that | 20:37 |
| fsmithred | if you really disabled lightdm, you should end up in multi-user non-graphical | 20:39 |
| dvbst | wow, i wish i remembered about this single user mode sooner, ive been putting fixing my computer off for like few weeks | 20:47 |
| dvbst | it did the job | 20:47 |
| fsmithred | cool | 20:49 |
| dvbst | ight guys, thanks for trying to help me and sorry to waste your time once again | 20:50 |
| fsmithred | maybe you learned some tricks you can use later | 20:51 |
| dvbst | yes | 20:52 |
| Alverstone | sysvinit boot scripts are pretty damn complex. Say I want a boot script to success very badly, how do I go into emergency shell upon failure? | 21:33 |
| Alverstone | Or boot isn't something that can fail/ | 21:39 |
| Alverstone | Or boot isn't something that can fail? | 21:39 |
| Alverstone | I just don't understand it, /etc/runit/1 doesn't handle handle errors in any way. the /etc/rcS.d doesn't have a single script that makes use of a emergency shell | 21:39 |
| Alverstone | which all together means | 21:39 |
| Alverstone | I should Do It Myself? | 21:40 |
| rwp | sysvinit moves through runlevels. It boots first to single user mode and continues *through* single user mode to multi user mode. | 21:43 |
| rwp | If something fails trying to get to single user mode it usually drops to the boot loader prompt. | 21:43 |
| rwp | After getting through single user mode if something fails in the multi user mode then it is already past single user and will drop into multi user mode. | 21:43 |
| rwp | The goal is to get the system online as much as possible at any given time. It will be up to the system operator to perform any rescue or maintenance if there is a failure along the way. | 21:43 |
| rwp | The systemd approach is completely different. I can't tell you how many times I have gotten onto the console of various systemd controlled systems and found systemd halted. Because systemd handles failure as a condition to halt. Making it damn hard to fix when you can't log into the system to fix it. Most of the time it needs a boot to rescue media. | 21:45 |
| rwp | The sysvinit approach to try to keep going and get to the login: prompt so that the operator can log in and fix things if needed is a much better approach. | 21:45 |
| rwp | I haven't grok'd runit enough to know how runit handles errors during the boot phase. But I am hoping it is more like sysvinit in trying to keep going to a login: prompt. | 21:46 |
| Alverstone | as far as I can see errors are a joke, they're completely ignored, probably expecting all scripts that follow to handle any possible failures gracefully | 21:47 |
| Alverstone | is it safe to set FANCYTTY to yes? | 21:51 |
| Alverstone | for some reason it's disabled by default | 21:51 |
| Alverstone | /lib/lsb/init-functions | 21:52 |
| Alverstone | or is there a configuration file? | 21:52 |
| Alverstone | put it in /lib/lsb/init-functions.d, hope I'm not implementing a wheel | 21:54 |
| rwp | FANCYTTY is yes by default. So, certainly it is okay to set it to yes. (I happen to always set it to no because, yes is the default.) | 22:01 |
| Alverstone | my /lib/lsb/init-functions sets it to empty... | 22:02 |
| Alverstone | probably because I use runit? | 22:02 |
| Alverstone | where is your FANCYTTY set to yes by default? | 22:02 |
| rwp | Probably at this moment in time you are the #2 world wide leading expert on using runit with Debian/Devuan. | 22:03 |
| Alverstone | who's the #1? | 22:04 |
| rwp | File /etc/lsb-base-logging.sh: line 216: [ -z $FANCYTTY ] && return 0 || true | 22:04 |
| rwp | Lorenzo | 22:04 |
| rwp | That line 216 is actually buggy, but works by accident. | 22:04 |
| rwp | If FANCYTTY is not set then what the shell sees is [ -z ] which has 1 argument "-z" and that being a non-zero sized string is true. It's true so that's the same as if -z "$FANCYTTY" were empty. | 22:05 |
| rwp | Works by accident. I reported that at some point but since it is accidentally functioning nothing ever got fixed. | 22:06 |
| rwp | And it's somewhat a clue that the author was having trouble with the syntax of that line because they appended || true there. Which also says the script is probably running with set -e active. Which is also a bad idea. See the bash FAQ for rationale. | 22:08 |
| rwp | http://mywiki.wooledge.org/BashFAQ/105 | 22:09 |
| Alverstone | isn't is sh | 22:11 |
| Alverstone | isn't it sh though | 22:11 |
| Alverstone | anyway | 22:11 |
| Alverstone | /lib/lsb/init-functions doesn't set -e | 22:11 |
| Alverstone | but the sourcing script might | 22:11 |
| Alverstone | doesn't matter since runit stage 1 ignores exit statuses completey | 22:12 |
| Alverstone | doesn't matter since runit stage 1 ignores exit statuses completely | 22:12 |
| Alverstone | not saying it's bad, just the way i expected | 22:12 |
| Alverstone | just not the way i expected | 22:12 |
| rwp | If the sh is running with set -e then the control flow of the shell is changed in subtle and buggy ways. It's bad. | 22:17 |
| rwp | And it doesn't matter that the caller ignores exit codes. The problem is that the sh -e will behave incorrectly sometimes and then it's incorrect. That's nothing to do with the caller. | 22:18 |
| Alverstone | doesn't it just exit upon a failure? i agree that ppl putting it everywhere are probably overcomplicating things. which bugs exactly do you mean | 22:19 |
| Alverstone | i saw scripts where people would use set -e and then append || true to almost every like | 22:20 |
| Alverstone | line* | 22:20 |
| rwp | That's a classic anti-pattern. Set -e and then use ||true everywhere to defeat it! | 22:22 |
| Alverstone | well i do use that flag sometimes, when proceeding after failure is dangerous | 22:24 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!