nikosv has asked for the wisdom of the Perl Monks concerning the following question:

I have setup a plack psgi application tha works with cgi files. When I start starman server from the shell of the user 'starman' the service runs fine and responds to requests.
When I try to set it up as a systemd Unit (Centos) , the client gets an error of "Server closed connection without sending any data back" without emitting any data.OS is Centos7. Can't find anything in the log files,expect from dmseg which has error :
111362894.832068 starman master 24776: segfault at c1 ip 00007f29bd8d2057 sp
 00007fff6ba44168 error 4 in XS.so7f29bd8cf000+15000
The service is set up as :
[Unit] Description=StarmanService [Service] Type=simple User=starman Group=starman ExecStart=/home/starman/perl5/bin/starman -E debug --ssl-key=/home/sta +rman/starm anpem+5-key.pem --ssl-cert=/home/starman/starmanpem+5.pem --listen :50 +00:ssl --w orkers=1 /home/starman/app.psgi --access-log /home/starman/access.log +--user=sta rman --error-log /home/starman/error1.log Restart=always WorkingDirectory=/home/starman/cgi-bin [Install] WantedBy=multi-user.target

Replies are listed 'Best First'.
Re: Starman "Server closed connection without sending any data back"
by hippo (Archbishop) on Nov 28, 2023 at 10:45 UTC

    Have you checked the audit log? You can get away with a lot of stuff in an interactive session that will be prohibited by SELinux when started from a systemd service. Systemd then hides that real reason from you in a double-whammy. Worth ruling out at the very least.


    🦛

      nothing in the log unfortunately
Re: Starman "Server closed connection without sending any data back"
by Corion (Patriarch) on Nov 28, 2023 at 10:25 UTC

    My random guess is that the interactive shell for starman has the environment variable PERL5LIB set up to something and the systemd version lacks such an environment variable, and loads a wrong version of the SSL XS modules.

    Or maybe it is some other difference between the starman user when run interactively and when run via systemd...

    Update: But see hippo's reply - SELinux sounds like a more propable culprit to rule out first.

      I did set the PERL5LIB inside the service to any paths I could find by perl -V but unfortunately it didn't make any difference.