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

daemon error messages & stored path to aiida module #1031

Closed
ltalirz opened this issue Jan 8, 2018 · 3 comments
Closed

daemon error messages & stored path to aiida module #1031

ltalirz opened this issue Jan 8, 2018 · 3 comments
Assignees

Comments

@ltalirz
Copy link
Member

ltalirz commented Jan 8, 2018

For some reason, on my system (MacOS 10.13.2, aiida 0.10.1) the daemon does not want to start properly:

$ verdi daemon status
# Most recent daemon timestamp:0h:00m:29s ago
Daemon not running (cannot find the PID for it)

$ verdi daemon start
Clearing all locks ...
Starting AiiDA Daemon ...
Daemon started

$ verdi daemon status
# Most recent daemon timestamp:0h:00m:06s ago
## Found 1 process running:
   * aiida-daemon[aiida-daemon] BACKOFF    Exited too quickly (process log may have details)

$ verdi daemon status
# Most recent daemon timestamp:0h:00m:06s ago
## Found 1 process running:
   * aiida-daemon[aiida-daemon] FATAL      Exited too quickly (process log may have details)

$ ps -ef | grep aiida-daemon
  502  1249 98105   0 12:25PM ttys003    0:00.00 grep --color=auto aiida-daemon

How do I go on from here? E.g. where do I find the process log?

@ltalirz
Copy link
Member Author

ltalirz commented Jan 8, 2018

Ok, thanks to @yakutovicha for pointing out verdi daemon logshow

This leads me to a few more questions:

  1. Do you guys agree with replacing Exited too quickly (process log may have details) by Exited too quickly (see "verdi daemon logshow")?

  2. The problem was that the hardcoded path to aiida in ~/.aiida/daemon/aiida_daemon.conf was no longer valid.
    However, the daemon actually still accepted calculation submissions. Error messages from these submissions were pointing to python files that no longer exist, e.g.

+-> ERROR at 2018-01-08 12:13:14.185750+01:00
|   Submission of calc 285 failed, check also the log file! Traceback: Traceback (most recent call last):
|     File "/Users/leopold/Applications/aiida_core/aiida/daemon/execmanager.py", line 475, in submit_calc
|     File "/Users/leopold/Applications/aiida_core/aiida/orm/implementation/general/calculation/job/__init__.py", line 1439, in _presubmit
|     File "/Users/leopold/Applications/aiida_core/aiida/orm/implementation/general/node.py", line 613, in get_inputs_dict
|     File "/Users/leopold/Applications/aiida_core/aiida/orm/implementation/general/node.py", line 675, in get_inputs
|     File "/Users/leopold/Applications/aiida_core/aiida/orm/implementation/sqlalchemy/node.py", line 274, in _get_db_input_links
|     File "/Users/leopold/Applications/aiida_core/aiida/backends/sqlalchemy/models/node.py", line 171, in get_aiida_class
|   TypeError: __init__() takes exactly 2 arguments (1 given)

I think this should not be allowed to happen?!

  1. The fact the path to the aiida python module is stored in the daemon config was something I did not expect. Sasha also told me this also caused him some problems a few days ago.
    Is this necessary? When I do verdi daemon start I would naively expect that the daemon would use the aiida installation in my python path at that time.

@ltalirz ltalirz changed the title how to debug the daemon? daemon error messages & stored path to aiida module Jan 9, 2018
@ltalirz
Copy link
Member Author

ltalirz commented Jan 9, 2018

from my discussions with @sphuber I learned that the .aiida/daemon/aiida_daemon.conf is gone in develop, and with it perhaps also the hard-coded path to the aiida python module?
If these things are solved in develop, this issue can be closed.

P.S. If you need to update the path to aiida in the daemon config, simply re-run verdi setup for your aiida profile (note: verdi quicksetup doesn't work!)

@sphuber sphuber self-assigned this Jan 15, 2018
@sphuber
Copy link
Contributor

sphuber commented Jan 15, 2018

With the removal of supervisord (PR #790) the daemon is now managed by celery and no longer uses a configuration file or a hardcoded path. There was an issue with the daemon as a result of incorrect logging but PR #1030 should have fixed this. Therefore I am closing this.

@sphuber sphuber closed this as completed Jan 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants