16:29 <tinnvec> hadn't had a chance to test out that trap setup until today. Maybe I'm missing something, but it seems that Ctrl-C is no longer working

16:30 <tinnvec> I can stop (ctrl-z) and kill the pid, so it's not like it's unstoppable, but it doesn't seem to make sense to me as to why

16:30 <dominikh> because you're not properly quitting after you handled the signal?

16:30 <tinnvec> bot.quit?

16:31 <tinnvec> or do I need to also specify that the mutex sync thread needs be killed?

16:31 <dominikh> well, are you sure it's calling that? and that you have no other Ruby code that's keeping the process alive?

16:31 <leftylink> should determine: the minimal example posted yesterday does or does not work for you? it does work for me. if it also works for you but not your full bot need to figure out the differences between the two

16:32 <tinnvec> hmm unsure, let me doublecheck

16:32 <tinnvec> yeah, let me see what might be messing things up here

16:36 <tinnvec> hrm okay maybe something's messed up elsewhere, ctrl-c doesn't seem to be working at all in my terminal emulator lol

16:45 <tinnvec> so so wierd, ctrl-c seems to not work on my vps anymore

16:45 <tinnvec> rebooted it and everything

16:46 <tinnvec> ctrl-\ seems to still send SIGQUIT, so at least there's that

17:25 <tinnvec> hm okay, must have been a typo on my part in this part of the quit message: Signal.signame(signal_received)

17:25 <tinnvec> as soon as I removed it all was well

17:25 <tinnvec> re-entered it and it works fine now too

17:25 <tinnvec> thanks for bearing with me :D

17:30 <tinnvec> I may have mentioned this earlier (mostly unelated) but I made a little "kill" plugin to tell the bot to quit from irc

17:30 <tinnvec> is there any way to do a restart? other than a variable and a while true?

17:30 <dominikh> use a proper supervisor such as runit or systemd

17:31 <tinnvec> ah yeah, I'm using systemd on my vps where the bot runs

17:31 <tinnvec> at least I'm pretty sure that's what the startup system is, I write the service filed in /etc/init.d

17:31 <tinnvec> *files

17:32 <tinnvec> so I can totally restart it from outside the bot, in a terminal

17:33 <tinnvec> or am I misunderstanding your meaning?

17:34 <dominikh> no.

17:35 <tinnvec> oh okay heh, so from within the bot, there isn't exactly a clean way to "reboot" it

17:35 <dominikh> sure there is, exec yourself. but it's pointless when you could do it the proper way

17:36 <tinnvec> cause there's always "while(true) { if (bot.quitting) { sleep 5; bot.start; } } "

17:37 <tinnvec> maybe I'm going to sound like a noob, but how would the "proper" way work? I feel like I'm missing a piece of the puzzle

17:38 <tinnvec> like, I don't know how to trigger systemd stuff from within a script

17:39 <dominikh> what is there to trigger? exit, and systemd, being a supervisor, will start it again.

17:40 <tinnvec> oh I see what you mean, it'll do it automatically? I'm not exactly familiar with the inner workings of systemd, I just assumed that once the bot quits out, the only way to restart it was from the command line

17:40 <dominikh> open up google and read up on what the actual task of a supervisor is ;)

17:41 <tinnvec> haha will do, linux is the never ending fountain of stuff I need to learn

18:37 <tinnvec> oh good thing to read up on, looks like I wrote things in the old way for startup

18:38 <tinnvec> being on 14.04, I didn't ealize that moving forward, upstart will be used

18:38 <dominikh> sane people have had supervision since ~2000 btw, mainstream linux is a tad slow to catch up.

18:53 <tinnvec> heh, so it would seem

18:53 <tinnvec> I actually went through a decent amount of hassle to learn how to write the old startup scripts too lol

18:53 <tinnvec> meh, happens, lesson learned

18:54 <tinnvec> at least the whol ebot thing isn't work work

18:54 <tinnvec> *whole bot

18:54 <tinnvec> just a fun distraction