Lightning-AI / Lightning-AI/pytorch-lightning
The training process will stop unexpectedly
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 31.4k
- Forks
- 3.8k
- Avg merge
- 6d 7h
- Merged PRs (30d)
- 6
Description
### Bug description
It seems to be caused by using callback or logger recording in multiple processes?
### What version are you seeing the problem on?
v2.2
### How to reproduce the bug
_No response_
### Error messages and logs
```shell
Traceback (most recent call last):
File "/home/username/.conda/envs/envname/lib/python3.11/multiprocessing/util.py", line 300, in _run_finalizers
finalizer()
File "/home/username/.conda/envs/envname/lib/python3.11/multiprocessing/util.py", line 224, in __call__
res = self._callback(*self._args, **self._kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/username/.conda/envs/envname/lib/python3.11/multiprocessing/util.py", line 133, in _remove_temp_dir
rmtree(tempdir)
File "/home/username/.conda/envs/envname/lib/python3.11/shutil.py", line 737, in rmtree
onerror(os.rmdir, path, sys.exc_info())
File "/home/username/.conda/envs/envname/lib/python3.11/shutil.py", line 735, in rmtree
os.rmdir(path, dir_fd=dir_fd)
OSError: [Errno 39] Directory not empty: '/tmp/pymp-dsg3ubii'
```
### Environment
Current environment
```
#- Lightning Component (e.g. Trainer, LightningModule, LightningApp, LightningWork, LightningFlow):
#- PyTorch Lightning Version (e.g., 1.5.0):
#- Lightning App Version (e.g., 0.5.2):
#- PyTorch Version (e.g., 2.0):
#- Python version (e.g., 3.9):
#- OS (e.g., Linux):
#- CUDA/cuDNN version:
#- GPU models and configuration:
#- How you installed Lightning(`conda`, `pip`, source):
#- Running environment of LightningApp (e.g. local, cloud):
```
### More info
_No response_
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the reported Python multiprocessing finalizer traceback and investigate callback or logger use across processes in v2.2. No reproduction steps, project entry point, or test is provided, so establish a minimal reproduction and add a regression test after locating the failing path. Done means training no longer stops unexpectedly and temporary-process directories clean up without the OSError.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- machine-learning
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100