<isd>
At some point I'll probably gather the energy to spin up some VMs and figure it out, but I wouldn't mind hints.
<ocdtrekkie>
Ian, if my PHP app appears to connect to the database fine for selects, but can't do any inserts, is there anything you would imagine I should look at?
<ocdtrekkie>
(I can't even get to my Linux box atm... otherwise I'd try to help you run tests...)
<isd>
What happens when it attempts an insert? Do you get an error?
<ocdtrekkie>
Not that shows in stderr
<isd>
And in the browser, do you just get a 5xx return?
<isd>
I would fish around in the mysql logs
<isd>
also other log files
<ocdtrekkie>
From my perspective it was like the line just didn't execute, everything in the php script ran except inserts didn't happen. I suppose I can enter-grain tonight and see if I can find some log files of some sort.
<isd>
Yeah, that would be the next thing to try
<ocdtrekkie>
I see nothing relevant in the logs in the grain.
<ocdtrekkie>
Also, I think a weird behavior I noticed is a bug of some sort with Sandstorm or vagrant-spk.
<isd>
which wierd behavior?
<isd>
*weird
<ocdtrekkie>
I opened an issue for it in vagrant-spk, but I find grains both abruptly terminate, and I often cannot successfully reopen a grain with a dev app that I had previously closed.
<isd>
I doubt that's vagrant-spk.
<ocdtrekkie>
I believe I've seen the issue both on Windows and Linux, but I should test Linux again.
<isd>
Note that having the grain open per-se won't keep it alive; it's communication with the server that does it. So if the page is loaded and sitting there it may still be killed
<ocdtrekkie>
It doesn't seem like production Sandstorm or production grains are so abruptly murdered.
<isd>
But not being able to re-open grains is definitely weird.
<ocdtrekkie>
And it even terminated my enter-grain session while I was interacting with it.
<isd>
Well, that makes sense; your shell is operating in the same pid namespace as the grain, so if the grain is killed so with the enter-grain shell.
<isd>
Side note, if you're just trying to look at the grain's storage, e.g. for log files, it's sometimes easier to just go and look in /opt/sandstorm/var/sandstorm/grains/<grain-id>
<ocdtrekkie>
Maybe I don't leave production grains unattended as long as I do in dev mode. But then maybe we should hold grains open longer in dev mode?
<ocdtrekkie>
If working with enter-grain doesn't keep a grain alive, we probably should find a way to keep it alive more successfully, since that's a very annoying thing to be disconnected during?
<isd>
I suspect what's happening in prod is that the first network request after it's killed just starts it back up, as it's supposed to, so you don't notice. What happens instead of the dev grains starting up again successfully?
<ocdtrekkie>
I just get connection reset error on a given dev mode grain when I reopen it.
<ocdtrekkie>
Delete the grain and start fresh... no problem. Until it kills the grain again.
<isd>
Anything in its grain log when the reset happens?
<isd>
or in sandstorm.log?
<ocdtrekkie>
I put the sandstorm long stuff I saw in the issue I opened.
<ocdtrekkie>
I don't think I ever saw anything notable in grain logs... but I also couldn't reopen them after that, so I rarely looked further...
<isd>
ocdtrekkie: you can always look at the file in /opt/sandstorm/..., if you want to see stuff that isn't showing up in the UI anymore
<ocdtrekkie>
Yeah, I know, I am just trying to think through what I actually did do.
<isd>
wrt. keeping the grain alive, I believe the original intent was to have keeping the page open keep the grain alive. I vageuly recall a conversation at some point where kentonv was surprised to find that it didn't.
<ocdtrekkie>
I possibly also see this the worst because tending to like writing PHP without much frontend code, network requests are pretty sparse to begin with.
<isd>
Yeah, and with mysql startup time won't be negligible.
<isd>
It would indeed probably be better to get the grain to stay alive if the UI is open.
<isd>
It sounds like there are two different issues: keeping the UI open should keep the grain running, and there's something wrong with restarting dev grains. I'm skeptical either is vagrant-spk specific.