Wenn ich Deinen Code richtig verstehe machst du den IO::Socket:SSL im einen Prozess auf, schreibst erfolgreich darauf und forkst später ab. Die Probleme treten dann beim syswrite im Child auf.

Dieses Vorgehen ist ein Problem, weil der SSL-Socket nun im Parent und Child existiert. Im Gegensatz zu einem einfachen Socket haben SSL-Socket einen State im User-Space (normale Sockets nur im OS-Kernel) und ein Fork führt dazu, dass Parent und Child jeweils eine Kopie dieses States haben. Wenn jetzt z.B. der Master (nach dem fork) eine I/O auf dem SSL-Socket macht so ist der State im Child nicht mehr korrekt und Versuche den SSL-Socket im Child für I/O zu benutzen scheitern entsprechend. Eine solche Aktion kann neben explizitem read/write auch ein close sein, da dieser SSL shutdown Alterts verschickt. Und der close kann implizit sein, wenn man den Socket explizit oder implizit destroyed (z.B. %client = () im Master).

Das kann man vermeiden, wenn man den Socket im Master explizit sofort nach dem Fork ohne SSL shutdown schliesst. Siehe SSL_no_shutdown dazu. Sauberer ist es aber, den IO::Socket::SSL nur im Client zu haben, d.h. im Master nur den plain Socket zu haben und den SSL-Handshake erst nach dem Fork durchzuführen.

Für weitere Erklärungen siehe diese github Issue und diesen Post on Stackoverflow.