| brocashelm | is it just me or is the site down? error code is SSL_ERROR_RX_MALFORMED_SERVER_HELLO | 05:33 |
|---|---|---|
| brocashelm | dev1galaxy loads | 05:33 |
| debdog | same error here | 05:51 |
| rrq | thanks; .. cert issue | 05:52 |
| nemo | hm... I see that tomcat10 for devuan doesn't bundle an init script yet | 19:33 |
| nemo | oh well. manual addition, nbd | 19:33 |
| nemo | cp /etc/init.d/tomcat8 /etc/init.d/tomcat10 ☺ | 19:34 |
| clemens3 | Linux from scratch is replacing eudev with systemd extracted udev | 19:34 |
| clemens3 | is devuan not using eudev, or do you have something else or of your own? | 19:34 |
| nemo | https://www.devuan.org/os/init-freedom | 19:35 |
| gnarface | last i checked, devuan had both | 19:35 |
| gnarface | it might be that now udev is just a transitional package that points to eudev though | 19:36 |
| rustyaxe | systemd is a cancer upon the Linux. A curse given to our computers like a biblical plague :o | 19:36 |
| gnarface | for a while i think you could literally run either | 19:36 |
| nemo | the init freedom page says that eudev, mdev and vdev are the options, with eudev ofc being systemd based. I'm not sure how that's different from what clemens3 is describing | 19:36 |
| nemo | I have no idea if this page is up to date though | 19:36 |
| ___used | systemd is a solution for problems normal linux users do not have. Fast booting, one point administration, "billble", container ready etc. All for cloud use. | 19:37 |
| ___used | billble->billable | 19:37 |
| gnarface | the fast booting part is pure fud though | 19:37 |
| gnarface | that part of the argument was started when it was purely theoretical and time has proven it to be 100% fictional in every respect | 19:38 |
| ___used | In a way yes. But someone likes to say that a lot. | 19:38 |
| rustyaxe | ___used: i dont have clowns on my computer tho | 19:38 |
| ___used | they are hiding from you | 19:39 |
| rustyaxe | Also, my laptop boots in 3 seconds once its past post.. Need it much faster? Its usually wait for me to login | 19:39 |
| clemens3 | well, lfs claim eudev is now unmainntained, and i can't believe other distros all fall back to systemd udev | 19:39 |
| nemo | I've never noticed any significant delays in booting with sysvinit - the work devuan machines reboot in seconds. even with full desktops | 19:39 |
| onefang | They should be hiding in #devuan-offtopic. | 19:39 |
| rustyaxe | nemo: indeed | 19:39 |
| ___used | clemens3: what does slackware use? | 19:39 |
| nemo | https://github.com/eudev-project/eudev | 19:40 |
| nemo | seems active | 19:40 |
| clemens3 | yeah, have to find out.. but without having a running devuan 4 right now, i thought i just ask around here what you guys have under the hood | 19:40 |
| nemo | I mean, not a ton of commits but that is not necessarily a bad thing | 19:40 |
| nemo | so long as it is being maintained | 19:40 |
| clemens3 | nemo: last updates may.. good for me | 19:41 |
| nemo | clemens3: do you have a post about that lfs claim? wondering when it was made | 19:41 |
| clemens3 | lfs has a systemd version and sysv, naturally if they use udev might make it simpler for the systemd fans/maintainers | 19:42 |
| nemo | clemens3: well, no idea how far apart eudev and udev are at this point, but theoretically they are supposed to be close… | 19:42 |
| nemo | clemens3: https://wiki.gentoo.org/wiki/Project:Eudev I guess you could go ask them | 19:42 |
| clemens3 | the lfs git diffed just a few days ago, and eudev was just removed, no mailing list discussion, moody in irc just said: | 19:42 |
| clemens3 | Moody | clemens3, dunno, but i assume that they are on systemd so no need for a sep. udev | 19:43 |
| nemo | mm | 19:43 |
| clemens3 | "implementation" | 19:43 |
| nemo | welp. that's their call. going all in on systemd is sufficient explanation | 19:43 |
| mason | Gentoo's not really involved with eudev any more. | 19:43 |
| clemens3 | oh, wrong quote wait | 19:43 |
| ___used | slackware is on udev | 19:43 |
| nemo | mason: oh? | 19:43 |
| mason | nemo: They determined that udevd wasn't locked to systemd so they could keep using it with their openrc/sysvinit | 19:44 |
| clemens3 | Moody | clemens3, afaics, problem is that eudev seems unmaintained and it gets more and more | 19:44 |
| clemens3 | incompatible | 19:44 |
| nemo | https://wiki.gentoo.org/wiki/Eudev | 19:44 |
| nemo | hm. no mention there that udev is not systemd linked | 19:45 |
| nemo | unless my skimming missed something | 19:45 |
| clemens3 | the first quote was about gentoo, i asked him what gentoo uses, he said systemd, moodys, i asked wasnt it openrc | 19:45 |
| ___used | Should this not be on #-offopic? | 19:45 |
| mason | nemo: https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html | 19:45 |
| nemo | clemens3: gentoo still allows you to choose | 19:45 |
| nemo | ___used: why | 19:45 |
| nemo | mason: thanks | 19:46 |
| mason | The wiki page should probably link that. | 19:46 |
| clemens3 | here is something from 2012 | 19:46 |
| clemens3 | https://lwn.net/Articles/529314/ | 19:46 |
| clemens3 | 11 years | 19:46 |
| clemens3 | saying how eudev started | 19:46 |
| ___used | https://blog.paranoidpenguin.net/2015/11/slackware-linux-is-moving-to-eudev/ because it is off topic -- explanation on slackware going eudev then back udev | 19:46 |
| nemo | ___used: it's relevant to me as to what init system I should be using on devuan | 19:47 |
| nemo | I'd like to know if gentoo feels udev is "safe" and not systemd linked, then perhaps I should switch to that on both gentoo and devuan | 19:47 |
| nemo | and I'm curious if devuan supports this | 19:47 |
| ___used | read the links, they explain what eudev is | 19:47 |
| nemo | so understanding current lay of the land, a useful support issue for this channel | 19:47 |
| clemens3 | ___used: well, support question what devuan is actually by default using | 19:47 |
| nemo | yeah. that was not a helpful response | 19:48 |
| nemo | mason: reading that it does seem to be exactly what you say... do you happen to know why devuan doesn't do this? | 19:48 |
| nemo | mason: is it a packaging issue? | 19:48 |
| mason | nemo: Devuan moved to eudev prior to Gentoo moving away from it, and I'm not currently aware of issues that would prompt moving back. | 19:48 |
| mason | Maybe they exist. | 19:49 |
| ___used | short: 2012 udev is merged into systemd, 2015 slack and others switch to eudevd, nowish: switch back to udevd "peeled" out of systemd | 19:49 |
| ___used | liberated? | 19:49 |
| nemo | mason: but I wouldn't be able to simply install udev on devuan... | 19:49 |
| nemo | mason: because the upstream packages would need modification? | 19:49 |
| mason | nemo: Unsure, sorry. | 19:50 |
| clemens3 | so without booting into devuan 4 myself, which package do you see installed on it yourself? | 19:50 |
| nemo | eudev/stable,now 3.2.9-10~chimaera1 amd64 [installed] | 19:50 |
| clemens3 | ok, thank you | 19:51 |
| ___used | afaik from user programs, (e)udev is not visible, some programs "see" udev notifications via dbus | 19:51 |
| nemo | clemens3: and same on dædalus unsurprisingly. eudev/testing,now 3.2.12-1 amd64 [installed] | 19:51 |
| clemens3 | i don't care about such stuff, i just feel very uncomfortable to give the systemd project any chance to make some decisions for me | 19:51 |
| gnarface | clemens3: what's important here is that eudev is currently in devuan so it's not going anywhere for the duration of the current release (chimaera) or the next release (daedalus) | 19:51 |
| mason | Reminds me, I've got a database box still on Beowulf I should upgrade. | 19:51 |
| ___used | see the deps and incompatibles for that package | 19:51 |
| nemo | gnarface: so long as it works reasonably well that's fine by me ☺ | 19:51 |
| nemo | gnarface: ... and isn't missing key features that will break upstream apps | 19:52 |
| clemens3 | yeah, i just asked because if eudev is used by devuan, i don't see a reason why it is not good enough for LFS | 19:52 |
| * ___used wants to go back to when hotplug called a shell script to get things done | 19:52 | |
| gnarface | nemo: well, my steam controller still works so i'm guessing it's fine | 19:52 |
| clemens3 | 2012 they say udev doesn't care for old kernels or hardware so much | 19:52 |
| clemens3 | don't know if that is true and eudev is better | 19:52 |
| nemo | clemens3: well. from what I am gathering here, their decision makes sense if udev is now considered untainted, and sounds like devuan might even have it as an option someday in a few years | 19:52 |
| clemens3 | but for sure the systemd devs are not trustable | 19:52 |
| nemo | clemens3: so not a reason to get too worried ☺ | 19:53 |
| gnarface | clemens3: probably because nobody slides you $40,000 in laundered mafia money for switching to eudev | 19:53 |
| nemo | O_o | 19:53 |
| clemens3 | exactly | 19:53 |
| nemo | I feel like I'm missing an inside joke | 19:53 |
| onefang | They don't? How am I gonna pay the rent now? | 19:53 |
| clemens3 | i moved from devuan to lfs to learn how to get rid of dbus.. once i know it, and how to build devuan myself from scratch, seems i have to consider coming back | 19:54 |
| onefang | I think fsmithred_ has a dbus free build of refracta. | 19:54 |
| mason | clemens3: That'll be a lot of package rebuilds. | 19:54 |
| mason | Easier to just suppress dbus. | 19:54 |
| ___used | One uses a stub instead | 19:55 |
| gnarface | clemens3: i wouldn't worry through daedalus. probably worth circling back to this subject for the release after that, but for now i think you're safe to use eudev | 19:55 |
| ___used | faking dbus by event injection is possible | 19:55 |
| clemens3 | well, it is a lot of package builds to build a LFS with falkon and firefox and libreoffice and rust | 19:55 |
| clemens3 | right now i just do sudo chmod 644 /usr/bin/dbus-launch to get rid of the runtime | 19:56 |
| clemens3 | but i still haven't had time to build more stuff without it at all | 19:56 |
| onefang | https://get.refracta.org/files/experimental/ | 19:57 |
| clemens3 | gotta learn refracta some day.. | 19:57 |
| onefang | "nodbus: | 19:57 |
| onefang | No dbus, no consolekit, no policykit, no display manager. | 19:57 |
| onefang | Openbox, lxpanel, sudo shutdown." | 19:57 |
| clemens3 | and seems I am not upgrading LFS next time | 19:57 |
| clemens3 | yeah, besides dbus looks like my setup | 19:58 |
| clemens3 | no elogind, no pam | 19:59 |
| clemens3 | and yeah, openbox:), no panel | 19:59 |
| nemo | so. question. the fact that I had to copy over init.d/tomcat8 to init.d/tomcat10 (and fix the symlinks) in the dædalus tomcat10 package - is that a known bug? I mentioned it a few weeks ago and I seem to remember fsmithred_ saying "thanks" but I recognise that's not the same as a formal bug report ☺ | 20:07 |
| nemo | s/symlinks/rc symlinks/ | 20:07 |
| ___used | tomcat10 is likely an upstream package and your fix was not propagated up | 20:08 |
| ___used | Also they may suffer systemd rot and no longer provide init.d scripts | 20:09 |
| nemo | well. it's very likely that, but that's why devuan has fixups | 20:09 |
| ___used | You could contribute one ;) | 20:09 |
| nemo | I imagine the tomcat9 script would work too, I just didn't have it on this machien | 20:09 |
| nemo | don't really have the devuan competence to do that properly sorry | 20:10 |
| nemo | but I can certainly type out what I did to "fix" | 20:10 |
| ___used | Just provide a .tgz of the modified files. | 20:11 |
| nemo | cp /etc/init.d/tomcat8 /etc/init.d/tomcat10;/bin/ls rc?.d/*tomcat8 | while read f;do pushd $(dirname $f);ln -s ../init.d/tomcat10 $(basename $f | sed 's/8/10/');popd;done | 20:11 |
| nemo | didn't modify anything | 20:11 |
| nemo | just did the above before removing tomcat8 | 20:11 |
| nemo | hmmm I did rename the tomcat8 to tomcat10 in the init script | 20:12 |
| nemo | I guess that counts as a mod | 20:12 |
| ___used | tar -czf tomcat8-to-10-sysvinit-scripts-v0.tgz /etc/init.d/tomcat10 /etc/rc?.d/*tomcat10 | 20:13 |
| nemo | the symlinks are packed up too? | 20:13 |
| ___used | y | 20:13 |
| nemo | lemme reboot at least once to verify that seems to work ok 😝 | 20:13 |
| nemo | reboot happened virtually instantaneously btw. despite full desktop on this server to please the windows admins, and tomcat and php-fpm and mysql all actively doing stuff | 20:16 |
| nemo | ok. not instantaneously. like whole tens of seconds to go down and come back up ☺ | 20:16 |
| ___used | that is $1 probably in "cloud pricing" terms, added over a couple reboots | 20:17 |
| ___used | you need systemd! </me ducks> | 20:17 |
| nemo | ok... that's weird. tomcat did not start up on reboot. crud | 20:19 |
| nemo | why... the script is there... | 20:19 |
| nemo | maybe copying 8 was not sufficient ☹ | 20:19 |
| nemo | it starts fine if done manually... | 20:19 |
| nemo | to the logs | 20:19 |
| ___used | it needs network up to start? | 20:20 |
| nemo | well, yeah, but that's defined in Required-Start just like in 8 and 9 | 20:26 |
| ___used | did you check starting by calling a symlink works? ... `$(basename $f | sed 's/8/10/');popd;done` ... seems to miss a sed `-e` flag | 20:27 |
| nemo | yes | 20:27 |
| fsmithred_ | nemo, I see that orphan-sysvinit-scripts has tomcat9 but not tomcat10 | 20:27 |
| fsmithred_ | that's in daedalus | 20:27 |
| nemo | ___used: -e is not needed with a single argument like that] | 20:28 |
| nemo | ohhhh | 20:28 |
| nemo | haha | 20:28 |
| nemo | dammit | 20:28 |
| fsmithred_ | both 9 and 10 are devuan packages, so I'm not sure what the maintainer is thinking. | 20:29 |
| nemo | hm. no. n/m. I did it right | 20:29 |
| fsmithred_ | Neither has an init script. | 20:29 |
| nemo | fsmithred_: huh. 9 had an init script in chimæra. odd. | 20:29 |
| nemo | fsmithred_: did 10 have one? | 20:29 |
| nemo | never thought to try it before | 20:29 |
| fsmithred_ | not according to apt-file | 20:30 |
| fsmithred_ | did you have a leftover init script from upgrade? | 20:30 |
| nemo | fsmithred_: so you can run 8 and 10 simultaneously | 20:30 |
| nemo | or 8 9 and 10 | 20:30 |
| fsmithred_ | no init script in 10 and it's not in the orphan package | 20:30 |
| nemo | so I just copied over 8 to 10 | 20:30 |
| nemo | (one server had been running 8 and 9 in chimæra when I'd been trying out 9, the other only 8) | 20:31 |
| fsmithred_ | is 10 the one that just did not start for you on reboot? | 20:33 |
| nemo | fsmithred_: yeah | 20:33 |
| nemo | trying to figure out why my approach didn't work. the init script seems fine | 20:33 |
| nemo | my crude symlink fixup... | 20:34 |
| nemo | is there a better way to do the symlinks? | 20:34 |
| ___used | increase logging level | 20:34 |
| fsmithred_ | update-rc.d? | 20:34 |
| nemo | fsmithred_: ah... yes... 😃 | 20:34 |
| nemo | well. let's see if that does anything different | 20:34 |
| ___used | assuming the headers in the init.d script are correct | 20:34 |
| nemo | fsmithred_: should I remove the existing ones first? | 20:35 |
| fsmithred_ | but you need an init script | 20:35 |
| ___used | are they nemo ? | 20:35 |
| nemo | fsmithred_: yeah. just using the one I copied from 8 | 20:35 |
| nemo | ___used: don't see anything obviously wrong with them | 20:35 |
| fsmithred_ | I don't know the best approach. This is something I don't normally mess with. | 20:35 |
| ___used | nemo: all 10 not 8? | 20:35 |
| fsmithred_ | did you look over the service file to see what it does? That might give some clues. | 20:36 |
| nemo | ___used: not sure what you mean sorry | 20:36 |
| nemo | fsmithred_: mmm good idea | 20:36 |
| ___used | no mention of 8 in the headers | 20:36 |
| nemo | ___used: no | 20:36 |
| nemo | and I updated the /usr/libexec/tomcat10/tomcat-locat-java.sh line | 20:36 |
| nemo | *locate | 20:36 |
| nemo | (which still exists) | 20:37 |
| nemo | well. wouldn'tve started manually otherwise ☺ | 20:37 |
| ___used | PATH assumptions by the script? | 20:38 |
| nemo | doesn't seem like it.. | 20:39 |
| ___used | add `set -x` to it and reboot? | 20:40 |
| nemo | eh. hang on. trying to examine the service files | 20:41 |
| nemo | annoyingly I removed 9 and kicking myself 'cause now I need that file | 20:41 |
| nemo | (wanted to do a diff between /lib/systemd/system/tomcat9.service and 10 | 20:41 |
| nemo | ) | 20:41 |
| nemo | guess I'll just grab the .deb again | 20:41 |
| ___used | try to add set -x to the init script and reboot. Should log a lot and the answer will be there. | 20:42 |
| nemo | no significant differences in the service files | 20:44 |
| nemo | just 9 replaced with 10 everywhere | 20:44 |
| clemens3 | so there was an lfs ticket for eudev, which let to its replacement: https://wiki.linuxfromscratch.org/blfs/ticket/18292 | 21:16 |
| clemens3 | and here is another explanation: https://lists.linuxfromscratch.org/sympa/arc/lfs-dev/2023-07/msg00006.html | 21:17 |
| clemens3 | i don't know if it makes sense | 21:17 |
| clemens3 | and if the world ends, or blootooth or upowerxy support | 21:17 |
| clemens3 | and if eudev is just a copy paste job of systemd-udev anyway | 21:18 |
| nemo | clemens3: well. forks do get out of sync... | 21:24 |
| nemo | yeah. a little under 20 seconds to shutdown and start up this devuan dev server with a full desktop and multiple services... I don't know what the expectations are in the cloud, but that is totally fine with me | 21:32 |
| nemo | well... apart from tomcat. still no idea what's going on there | 21:33 |
| nemo | ___used: so... I've never had to debug an init script that behaved differently at boot.. where do I go for the logs? do I have to install bootlogd or something? | 21:39 |
| gnarface | nemo: shortcut to the probable issue; echo $SHELL && ls -l /bin/sh | 21:55 |
| gnarface | (if the first one says bash and the second one says dash, that's probably why it behaves differently on boot) | 22:00 |
| nemo | gnarface: heh. good point on the dash thing. | 22:09 |
| nemo | can give that a quick shot for sure | 22:09 |
| nemo | you wouldn't think that would happen to a debian init script but eh | 22:09 |
| gnarface | i feel like i've still seen the issue disturbingly recently with something they had just removed | 22:10 |
| nemo | gnarface: no issues with launching after explicitly using /bin/dash in the init script | 22:15 |
| gnarface | nemo: interesting... a bit weird but not impossible i guess | 22:17 |
| gnarface | dash is supposed to be a subset of bash functionality but there must be some ambiguous cases | 22:18 |
| nemo | oh no | 22:18 |
| nemo | I mean | 22:18 |
| nemo | I tried changing the init script to explicitly use dash | 22:18 |
| nemo | and it still started and stopped manually just fine | 22:19 |
| nemo | so that seems unlikely to be the issue | 22:19 |
| nemo | and yeah, root's shell was set to bash | 22:19 |
| gnarface | oh, i see | 22:19 |
| nemo | and yeah, reviewing the service file there were no changes between 9 and 10, and those things listed in the service file didn't seem unusual | 22:19 |
| nemo | gnarface: do you happen to know how I would get some boot logging on this init? | 22:20 |
| gnarface | i think you should be able to see the relevant boot log if you run "dmesg" right after boot | 22:21 |
| gnarface | if you need it put in a file i think you were right that you need to install some package | 22:21 |
| gnarface | bootlogd or something like that | 22:21 |
| gnarface | i forget the exact name, but your guess matched my vague recollection of it | 22:21 |
| gnarface | some stuff shows up too early to get with anything other than a serial console, but hopefully none of that is your init scripts | 22:22 |
| nemo | uuuugh that !@#$ tomoyo-init does not exist dmesg spam | 22:29 |
| nemo | gotta figure out how to get rid of that too | 22:29 |
| nemo | nothing obvious in dmesg | 22:30 |
| nemo | guess I'll try that bootlog thing | 22:30 |
| nemo | sure hope that still works | 22:30 |
| mason | nemo: tomoyo-tools: /sbin/tomoyo-init | 22:30 |
| nemo | mason: but... I shouldn't have to install it | 22:31 |
| mason | nemo: Agreed. But if it's not there, you could shove a script there that saves off pstree -p or something to track it down | 22:32 |
| nemo | mason: ah. fair point | 22:34 |
| mason | I see it too but I've not yet tracked down what wants it. | 22:34 |
| mason | hm: https://www.kernel.org/doc/html/latest/admin-guide/LSM/tomoyo.html | 22:34 |
| mason | Might be the kernel itself, although that'd be unusual. | 22:35 |
| nemo | aw fuck | 22:35 |
| nemo | mason: that was a bad bad bad idea | 22:35 |
| mason | nemo: Worst case, have a shell script there that does nothing. :P | 22:35 |
| mason | nemo: Did you not redirect to a file? =cough= | 22:35 |
| nemo | no that wasn't the problem | 22:35 |
| mason | Ah, what happened? | 22:35 |
| nemo | access got cut off | 22:35 |
| nemo | literally my ssh session went unresponsive | 22:36 |
| nemo | and entire machine | 22:36 |
| nemo | bet it was the kernel | 22:36 |
| nemo | going to have to restore from this morning's snapshot. | 22:36 |
| mason | That's kind of unexpected. :/ Sorry. | 22:36 |
| nemo | ugh. | 22:36 |
| nemo | I had some stuff in there I really really did not want to lose | 22:36 |
| nemo | my fault for blithely listening to suggestions on IRC I guess | 22:37 |
| mason | Is this machine not local? | 22:37 |
| nemo | no | 22:37 |
| nemo | crap | 22:37 |
| nemo | yep. it's totally unresponsive to pings. lovely | 22:38 |
| mason | Looks like the real thing is supposed to be able to bail/fail and it's hard to think this ought to take down the system: https://termbin.com/kgg6v | 22:41 |
| nemo | mason: I hadn't put in a script that did anything yet | 22:41 |
| mason | And it prints arbitrary things to stdout. | 22:41 |
| nemo | I'd made a completely blank stub | 22:41 |
| nemo | and hadn't even made it executable | 22:41 |
| nemo | didn't get a chance because I got locked out | 22:41 |
| mason | nemo: Hrm, hrm. That could have been it, but frankly that's just how I'd have done it so it's not a crazy idea. | 22:41 |
| nemo | a few seconds after my stub file showed up | 22:41 |
| mason | Seems like a bug if a non-executable file there can freeze the system. | 22:42 |
| nemo | p'raps, but I'm sure as hell not trying this again | 22:42 |
| nemo | feel free to do it on your system 😝 | 22:42 |
| mason | I'm going to try it on my laptop, yes. | 22:42 |
| nemo | I now get to try and fix everything I was doing this afternoon on this machine. | 22:42 |
| nemo | I should have known better | 22:42 |
| nemo | should have done it on something not quite as important | 22:43 |
| nemo | thankfully it was just a dev instance | 22:43 |
| nemo | just one I'd been doing a lot to today | 22:43 |
| mason | While I agree, it's a really unexpected result. | 22:43 |
| mason | So, I've got one in place and nothing much is happening. Going to reboot with it in place and see what happens. | 22:44 |
| nemo | this was on dædalus if that matters | 22:45 |
| mason | Interesting. It appears to have frozen before getting too far into its attempt to reboot. Messages still up on screen. | 22:45 |
| nemo | mm | 22:45 |
| mason | I'm not able to, for instance, change to a virtual console. | 22:45 |
| mason | No IPMI or anything on yours...? | 22:46 |
| nemo | it's a VM | 22:46 |
| mason | Ah, can you access the hypervisor's interface, boot from rescue media? That's how I'm going to correct this guy. | 22:47 |
| nemo | nope | 22:48 |
| nemo | restoring to this morning's snapshot | 22:48 |
| nemo | less work | 22:48 |
| nemo | getting to that interface would require jumping through a lot of stupid bureaucratic hoops | 22:48 |
| mason | hrm hrm | 22:49 |
| nemo | and I cannot be bothered | 22:49 |
| nemo | I'll just redo what I did this afternoon. I can remember most of it | 22:49 |
| mason | So technically possible but access you don't have? I'd hate for you to lose the data. | 22:49 |
| nemo | yes | 22:49 |
| mason | Can you take a snapshot and access it from the reverted instance? | 22:49 |
| nemo | possibly... but don't feel like going through the same hassle to explain all that. if this was my instance and my VM, sure. | 22:50 |
| nemo | but it's managed by a totally different group | 22:50 |
| nemo | easier to just say. hey, revert to this morning's autosnapshot. thanks | 22:50 |
| nemo | and then sit down and refetc a half dozen jars and edit some configs | 22:50 |
| ___used | nemo: bummer. That should not happen. Do you even have a kvm screenshot of the stuck boot screen? | 22:50 |
| nemo | ummm | 22:50 |
| nemo | I might have access for that? maybe? | 22:51 |
| nemo | I have some limited read only | 22:51 |
| nemo | 'course I already sent them the message.. | 22:51 |
| ___used | so what's the last line on there | 22:51 |
| nemo | let's see what I can do on the nutanix console | 22:51 |
| mason | FWIW, removing the file from rescue media was successful here. | 22:52 |
| ___used | were you rebooting when it happened? | 22:52 |
| nemo | no | 22:52 |
| mason | Sure feels like a bug. | 22:52 |
| ___used | I was going to say typo in script but then no | 22:52 |
| nemo | oh wait. it's vsphere now | 22:53 |
| ___used | yes sounds like a bug unrelated to your sript | 22:53 |
| ___used | +c | 22:53 |
| nemo | well. it wasn't even a script yet | 22:53 |
| mason | Note to self: next time, test locally before mentioning it online | 22:53 |
| mason | I so often do but this felt like a pretty safe bet. | 22:53 |
| nemo | anyway. I do not have access to this VM | 22:53 |
| nemo | so I will have to wait | 22:53 |
| ___used | set -x makes the init script log each executed line. It does not change anything else. Boot log will be in syslog (from this) | 22:54 |
| nemo | ___used: yeah. familiar with -x however I saw nothing new in syslog or dmesg | 22:55 |
| mason | nemo: FWIW, even if it was executable and a script, it seems kind of fragile. This froze too: https://bpa.st/3YXA | 22:58 |
| mason | that said, maybe I'll have pstree output once I get in via rescue media | 22:58 |
| mason | I'll share what I find. | 22:59 |
| ___used | see /var/log/boot or /var/log/syslog for set -x output | 23:00 |
| mason | Nope, didn't get a chance to actually write out the tomoyo-pstree file. Whatever locks it up is immediate. | 23:02 |
| ___used | check free space | 23:03 |
| ___used | du -sk | 23:03 |
| ___used | or df | 23:04 |
| mason | On this box? What is the goal? | 23:04 |
| ___used | you may have run out of space | 23:04 |
| mason | Oh, no, it has space. | 23:04 |
| ___used | hmm | 23:04 |
| mason | I think whatever the kernel did was pretty immediate, probably before the shell started running the script, but I'm perplexed as to what and why. | 23:05 |
| ___used | change the tomoyo-init script to use full path for pstree? | 23:05 |
| mason | That's an interesting idea but I think I want to set up a VM to test, as each reboot/correction on my laptop involves snagging my installer, having it pull in ZFS kmods, manually unlocking two LUKS providers, and mounting up my root. | 23:06 |
| ___used | sounds like you are missing out something important. | 23:07 |
| mason | Hm? | 23:07 |
| mason | How so? | 23:07 |
| ___used | ssh into vm as non root and did not elevate? | 23:07 |
| mason | I'm not parsing. Could you restate that? | 23:09 |
| mason | I wonder if tomoyo-init is actually an init and the kernel intends for it to be PID 1. | 23:12 |
| mason | rereading | 23:12 |
| ___used | is not an init | 23:12 |
| mason | "This program is executed automatically by kernel when execution of /sbin/init is requested. | 23:13 |
| ___used | ?! | 23:13 |
| mason | Yeah, not an init. | 23:14 |
| mason | Feh. Popped in https://bpa.st/WNQQ and still no output, so it wasn't that it was a shell. | 23:24 |
| ___used | whoami? id? | 23:29 |
| mason | If this wasn't able to run, shelling out to something will have less success still. This was an attempt at fairly minimal moving parts. | 23:30 |
| ___used | whoami? id? <- | 23:33 |
| mason | If the kernel's calling it, it's root if anyone. | 23:34 |
| ___used | are you root? also does the local vm? have +w on the disk image file(s) | 23:38 |
| nemo | gnarface: welp. one problem solved. tomcat is starting up now. not sure why :) | 23:47 |
| nemo | gnarface: 'cause I ran update-rc for the symlinks this time... | 23:48 |
| gnarface | heh | 23:48 |
| nemo | as fsmithred_ suggested | 23:48 |
| nemo | you'd think that would work manually though. so... something else? dunno | 23:48 |
| gnarface | hmmm, could only guess you missed a symlink | 23:48 |
| gnarface | or named it wrong | 23:49 |
| nemo | also. using tomcat9 init.d is a better idea than 8 - less work to fix, 8 had more TOMCAT8 variables everywhere | 23:49 |
| nemo | gnarface: yeah, p'raps | 23:49 |
| nemo | so now the only thing is the issue I've always had w/ devuan, that irritating dmesg spam from tomoyo | 23:49 |
| nemo | but after above I am soooooo not touching that 😝 | 23:49 |
| gnarface | i think you should be able to suppress the errors from rsyslog.conf | 23:50 |
| ___used | your symlinks did not look like ../init.d/script | 23:50 |
| nemo | ___used: hm? | 23:53 |
| nemo | gnarface: fwiw, here's the ones I'd generated by copying tomcat8/9 and those from update-rc - they look identical to me, but whatever | 23:57 |
| nemo | https://m8y.org/tmp/temp.txt | 23:57 |
| nemo | (first ones were fortunately still in my tmux buffer) | 23:58 |
| nemo | maybe some of my other tomcat fiddling had messed something up... | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!