1617515114 M * Bertl_oO off to bed now ... have a good one everyone! 1617515117 N * Bertl_oO Bertl_zZ 1617516842 J * Ghislain ~ghislain@adsl1.aqueos.com 1617532469 Q * Ghislain Quit: Leaving. 1617534030 J * Ghislain ~ghislain@adsl1.aqueos.com 1617537545 Q * Aiken Remote host closed the connection 1617546751 Q * Ghislain Ping timeout: 480 seconds 1617551430 N * Bertl_zZ Bertl 1617551433 M * Bertl morning folks! 1617551664 M * gnarface morning Bertl! 1617551673 M * gnarface say, question for you 1617551755 M * Bertl yup? 1617551758 M * gnarface i upgraded a guest from an old version of devuan to current stable, and it wouldn't start anymore (not surprising) but if i changed to plain init from the sysvinit default it works... does that suggest it's a simple file name problem or something? afaik none of the init stuff should have changed between these two versions 1617551797 M * gnarface it's supposed to be known not to work from what i've heard, but these guests all survived 2 previous upgrades... 1617551804 M * Bertl yes, that would hint that the proper init script cannot be found or doesn't respond as expected 1617551815 M * Bertl could be wrong runlevel or similar as well 1617551819 M * gnarface i had wondered if maybe a file just didn't get unpacked right 1617551824 M * gnarface that has happened before 1617551851 M * gnarface i tried to enable debugging but there was no change in the output though, couldn't get more verbose of a message other than the script "()" isn't present 1617551867 M * gnarface which i compared to other errors online and found out means that it couldn't even determine the name of what it's missing 1617551888 M * gnarface any idea how i might narrow it down? 1617551931 M * gnarface might it log some errors about this somewhere in a file on the host or the guest? 1617551987 M * gnarface hmm... runlevel wouldn't have been different before right? 1617552028 M * gnarface i know that it defaults to 2 in devuan and debian and while researching this i noticed vserver guests are 3, which i had not noticed before or had forgotten, unless that could have somehow changed with the guest update when the tools themselves had not been updated on the host... 1617552065 M * gnarface most init scripts aren't really set different for 2-5 i thought though 1617553190 M * Bertl can you upload the full --debug output somewhere? 1617554129 M * gnarface https://paste.debian.net/1192298/ 1617554141 M * gnarface i also tried the redhat fix it mentions in the error 1617554145 M * gnarface no change for that 1617554150 M * gnarface but switching to init style "plain" does work 1617554740 M * Bertl now let's run the start with --debug 1617554748 M * gnarface no change 1617554907 M * Bertl you are saying that 'vserver --debug chivalry-0 start' doesn't provide more output? 1617554913 M * gnarface correct 1617554923 M * Bertl if so, then your tools are probably broken 1617554926 M * gnarface also i checked for obvious stuff like missing symlinks 1617555034 M * Bertl ah, just tried it, the start is the command and needs to go first 1617555070 M * gnarface lemme try again, i think the instructions i found told me to run it like "vserver chivalry-0 start --debug=help" 1617555099 M * Bertl no, vserver --debug chivalry-0 start should work 1617555126 M * gnarface ok, yea if i call it like that it does work, i have more output, want me to paste that too? 1617555134 M * Bertl yep 1617555227 M * gnarface https://paste.debian.net/1192301/ 1617555228 M * gnarface here you go 1617555314 M * gnarface could a change to how the guest's sysvinit works have caused boot to fail like this because of something i put in /etc/rc.local to start up at the very tail end of boot? 1617555347 M * gnarface the stuff i read suggested that init style "plain" still calls my rc scripts though just like sysvinit would have... 1617555385 M * gnarface but, to be clear, guest's sysvinit shouldn't have changed in any incompatible ways, so if it did this is a bug 1617555402 M * gnarface but i think it's more likely that maybe a postinst script failed rather during the upgrade process 1617555423 M * gnarface and that this error is not directly related to sysvinit but mabye more indirectly related to a packaging glitch 1617555444 M * gnarface that hypothesis i admit is based on nothing more than statistical analysis of past events 1617555582 M * gnarface if it's actually a change in devuan maybe i can get them to fix it 1617555637 M * gnarface but usually it has just been as simple to fix as reinstalling some package 1617555652 M * gnarface some package that isn't compatible with vserver tools that they won't fix 1617555676 M * gnarface but also isn't broken very badly 1617555802 M * gnarface i thought it was pretty weird the error "()" 1617555825 M * gnarface judging by the examples google dredged up of that error template, there should have been a name of a script it tried to call there 1617555836 M * gnarface so i was baffled at how it could have gotten to that point and not even know 1617555892 M * gnarface the parenthesis being empty seemed to belie the point of the statement 1617555969 M * gnarface tool versions 0.30.216-pre3126-1, so i think there's probably a possibility they're incompatible due to age but i had assumed that if that were the case then switching to init style "plain" wouldn't have worked either 1617555993 M * gnarface but not only does it work, it works silently 1617556873 M * Bertl is there an /etc/init.d/rc or /etc/rc.d/rc inside the guest root? 1617556884 M * Bertl and if so, is it executable? 1617556932 M * gnarface well, it's a symlink 1617556942 M * gnarface and the symlink is broken in the host context 1617556956 M * gnarface would that matter as it launches if i'm launching it by hand like this? 1617557051 M * Bertl where does it symlink to? 1617557064 M * gnarface /lib/init/rc 1617557091 M * Bertl try to specify that in the config then 1617557136 M * gnarface in which config? 1617557140 M * gnarface i've never had to specify this 1617557148 M * gnarface it's not different from where it was before 1617557181 M * Bertl is that so? 1617557213 M * Bertl let's do a --debug run on one of the 'old' working guests then 1617557217 M * gnarface double-checking... 1617557222 M * Bertl and upload the output as well 1617557309 M * gnarface oh, my bad it's not a symlink on the others 1617557315 M * gnarface it's just in the same place 1617557337 M * gnarface symlinks are probably all that's killing this then i'm guessing? 1617557351 M * Bertl very likely 1617557368 M * Bertl so I'd try with specifying the actual path in the config 1617557375 M * Bertl and see if that works as expected 1617557382 M * gnarface where is the config now? 1617557389 M * gnarface like i said, i never had to specify this 1617557413 M * gnarface i kinda thought it was hardwired 1617557550 M * Bertl you want to specify cmd.start and cmd.stop 1617557559 M * gnarface i had tried fixing the symlinks so they were relative and correct in both contexts but not only did that not work, somehow they get rewritten back to the way they were 1617557595 M * Bertl http://www.nongnu.org/util-vserver/doc/conf/configuration.html 1617557627 M * gnarface oh, i see, i don't even have that file present here 1617557639 M * Bertl that's okay, it has defaults 1617557639 M * gnarface thanks 1617557719 M * gnarface so, i take it there's no easy way to just tell it to resolve the symlinks in the guest context is there? 1617558079 M * Bertl well, it's open source, so you can probably modify util-vserver scripts in this regard 1617558125 M * Bertl did you verify that it works when you change the cmd.start/stop? 1617558367 M * Bertl anyway off for now ... bbl 1617558372 N * Bertl Bertl_oO 1617559101 M * AlexanderS Yes, we already had this problem here a few times: http://sprunge.us/mi2oCA 1617565951 M * gnarface sorry, got pulled away there for a bit, yes it works though, thank you guys 1617565983 M * gnarface rc doesn't care what directory it's called from i guess... 1617566114 M * gnarface i guess i don't know why i was afraid it would 1617570355 J * Aiken ~Aiken@2001:44b8:2168:1000:b26e:bfff:fe2a:b951