Psy-Fer / buttery-eel

The buttery eel - a slow5 guppy/dorado basecaller wrapper
MIT License
34 stars 2 forks source link

Connection error - file name too long #37

Closed denisbeslic closed 4 months ago

denisbeslic commented 4 months ago

Hi,

I am trying to run buttery-eel with guppy (6.5.7). I changed the version in the requirement file to ont-pyguppy-client-lib==6.5.7.

I'm running the following command: buttery-eel -i file.blow5 -o file.fastq -x "cuda:all" -g ont-guppy-6_5_7/bin/ --config dna_r10.4.1_e8.2_400bps_sup.cfg --port 8020 --slow5_threads 4

[guppy/error] basecall_service::BasecallClient::worker_loop: Connection error. [failed] zmq::error_t : File name too long
[guppy/error] basecall_service::BasecallClient::worker_loop: Connection error. [failed] zmq::error_t : File name too long
[guppy/error] basecall_service::BasecallClient::worker_loop: Connection error. [failed] zmq::error_t : File name too long
[guppy/error] basecall_service::BasecallClient::worker_loop: Connection error. [failed] zmq::error_t : File name too long
[guppy/error] basecall_service::BasecallClient::worker_loop: Connection error. [failed] zmq::error_t : File name too long
[guppy/error] basecall_service::BasecallClient::worker_loop: Connection error. [failed] zmq::error_t : File name too long

               ~  buttery-eel - SLOW5 Guppy/Dorado Basecalling  ~
                            version: 0.4.2
==========================================================================
  ARGS
==========================================================================
args:
 Namespace(input='file.blow5', output='file.fastq', guppy_bin=PosixPath('ont-guppy-6_5_7/bin'), config='dna_r10.4.1_e8.2_400bps_sup.cfg', guppy_batchsize=4000, call_mods=False, qscore=None, slow5_threads=4, procs=4, slow5_batchsize=4000, quiet=False, max_read_queue_size=20000, log='buttery_basecaller_logs', moves_out=False, do_read_splitting=False, min_score_read_splitting=50.0, detect_adapter=False, min_score_adapter=60.0, trim_adapters=False, detect_mid_strand_adapter=False, seq_sum=False, barcode_kits=None, enable_trim_barcodes=False, require_barcodes_both_ends=False, detect_mid_strand_barcodes=False, min_score_barcode_front=60.0, min_score_barcode_rear=60.0, min_score_barcode_mid=60.0, profile=False)
['-x', 'cuda:all', '--port', '8020']

==========================================================================
  Starting Guppy/Dorado Basecalling Server
==========================================================================
Setting params...
Connecting...
Traceback (most recent call last):
  File "xxx/.local/bin/buttery-eel", line 8, in <module>
    sys.exit(main())
  File "xxx/.local/lib/python3.9/site-packages/src/buttery_eel.py", line 872, in main
    with start_guppy_server_and_client(args, other_server_args) as client_one:
  File "/opt/miniconda/lib/python3.9/contextlib.py", line 119, in __enter__
    return next(self.gen)
  File "xxx/.local/lib/python3.9/site-packages/src/buttery_eel.py", line 110, in start_guppy_server_and_client
    with client:
  File "xxx/.local/lib/python3.9/site-packages/pyguppy_client_lib/pyclient.py", line 394, in __enter__
    self.connect()
  File "xxx.local/lib/python3.9/site-packages/pyguppy_client_lib/pyclient.py", line 175, in connect
    raise ConnectionError(
ConnectionError: Could not connect. Is the server running? Check your connection parameters. <result.failed: 12> : [failed] zmq::error_t : File name too long

Is 'File name too long' a known bug?

I also tried using dorado (dorado basecall server==7.3.9; ont-pybasecall-client-lib==7.3.10) and reinstalling buttery-eel. I still got the same error message.

hasindu2008 commented 4 months ago

This is a bit strange error. I have not seen this before. Could you add the --use_tcp option and try? Also can we get some information about your system such as the O/S and the processor etc. @Psy-Fer any idea?

Psy-Fer commented 4 months ago

Hey,

Yea that's an error to do with ipc. Please try again using the --use_tcp flag and let us know if that fixes it.

James

denisbeslic commented 4 months ago

Thank you a lot!! Running it with --use_tcp solved the issue. I was just confused, because it worked without the --use_tcp in the past.

Psy-Fer commented 4 months ago

Yea the --use_tcp option didn't exist in these versions

4.2.2, 4.2.3, 4.3.4, 4.4.0, 4.4.1, 4.4.2, 4.5.2, 4.5.3, 4.5.4, 5.0.11, 5.0.13, 5.0.14, 5.0.15, 5.0.16, 5.0.17

as that was the default. Then IPC was introduced and made default, so you had to use the flag to turn it on.

Anyway, glad it's working now :)