Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Deutexrium is non-functional since 36037 #1

Open
F0bes opened this issue Sep 22, 2022 · 3 comments
Open

[Bug] Deutexrium is non-functional since 36037 #1

F0bes opened this issue Sep 22, 2022 · 3 comments

Comments

@F0bes
Copy link

F0bes commented Sep 22, 2022

Hi there, I've managed to bisect this issue to commit #36037

03:08:32.994 [info]  channel-XYZ server: loading
 
03:08:32.994 [info]  channel-XYZ server: creating new meta
 
03:08:32.995 [error] Task #PID<0.704.0> started from #PID<0.675.0> terminating
** (stop) exited in: GenServer.call({:via, Registry, {Registry.Server, {:channel, {XYZ, ABC}}}}, {:generate, :neutral, nil}, 15000)
    ** (EXIT) no process: the process is not alive or there's no process currently associated with the given name, possibly because its application isn't started
    (elixir 1.13.4) lib/gen_server.ex:1019: GenServer.call/3
    (deutexrium 1.3.3) lib/deutexrium.ex:69: Deutexrium.handle_event/1
    (elixir 1.13.4) lib/task/supervised.ex:89: Task.Supervised.invoke_mfa/2
    (stdlib 3.14) proc_lib.erl:226: :proc_lib.init_p_do_apply/3
Function: #Function<7.75347062/0 in Deutexrium.start_link/1>
    Args: []

This is the result whenever a message is received. Thanks.

@portasynthinca3
Copy link
Owner

Interesting. I will take a look at it, thanks for the report

@portasynthinca3
Copy link
Owner

Is it possible that access permissions for the parent directory and/or the possibly existing meta_ file are set up incorrectly? I'm able to recreate this issue when artificially restricting my access to an existing meta_ file. Judging by the code, that's the only possible reason a channel GenServer could fail right after or during startup, causing the subsequent immediate call to the just-crashed server to fail too:

def init({id, guild}) do
# load model and meta
Logger.info("channel-#{id} server: loading")
meta = try do
Meta.load!(id)
rescue
_ ->
Logger.info("channel-#{id} server: creating new meta")
Meta.dump!(id, %Meta{})
%Meta{}
end
model = try do
Model.load!(id)
rescue
_ ->
Logger.info("channel-#{id} server: creating new model")
Model.dump!(id, %Model{})
%Model{}
end
Logger.info("channel-#{id} server: loaded")
timeout = Application.fetch_env!(:deutexrium, :channel_unload_timeout)
{:ok, {{id, guild}, meta, model, timeout}, timeout}
end

The crash itself is not logged because this process is out of any supervisor's field of vision by design.

@F0bes
Copy link
Author

F0bes commented Oct 3, 2022

I usually run the bot as a systemd system job (That way it just runs on my raspberry pi automatically).
I've given the /var/deutex_data (and the meta_ files) full permissions to every user, I've given the folder where I execute it full permissions, and I've ran it as the root user. I still face the same issue unfortunately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants