My guess is that your "global" variables in package Navi are not always initialized, maybe due to some mod_perl weirdness resp. how it wraps your code in a subroutine. You should see some warning like Variable will not stay shared in the webserver logs maybe.

My first approach would be to move the creation of the CGI object into a subroutine and always call that subroutine instead of hoping that the global variable is still available.

Thanks a lot for this. And it seems that is indeed the solution. The scripts have been running for years without any issues, though. So I find it quite astonishing that this really is the case. oO I uploaded a test3.pl where I tried your suggestion and this one works without any issues. But urgh... That would mean I have to adjust that in dozens of scripts... My whole site is running on Perl... :(


Link: https://digioso.tk/test3.pl

Source code test3.pl

#!/usr/bin/perl -w
use strict;
use CGI;
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
use lib "/home/digioso/web/digioso.tk/stuff";
use Navi2;

my $cgi = Navi2::create_cgi();
Navi2::print_navi($cgi);
print "test";
Navi2::end_navi($cgi);
[download]


Source code Navi2.pm:

#!/usr/bin/perl -w

use strict;
use warnings;
use CGI;
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);

package Navi2;

binmode STDOUT, ":utf8";

sub create_cgi
{
    return new CGI;
}

sub print_navi($)
{
    my $cgi = shift;
    print $cgi->header (-type => 'text/html', -charset => 'UTF-8');
}

sub end_navi($)
{
    my $cgi = shift;
    print $cgi->end_html;
}
[download]

Now I started migrating stuff from my old webhoster to the new server

This is why things changed, and why you have to edit your scripts.

If you are interested, you could use this to migrate to (say) Mojolicious, which allows you to locally test your scripts and move some of your HTML generation into templates etc., but as a first step, instead of passing $cgi into print_navi(), you could create it within print_navi() if you don't need it elsewhere, especially if you're only using it for HTML generation.

You also want to move the binmode STDOUT, ":utf8"; into your first call, likely create_cgi() so it gets called every time.

While your question has already been answered, you should also check the timeout settings of the old vs new webserver, especially if you have some long running scripts.

Also, if you're getting a lot of webcalls (you are implementing some API or something), i would check the new system for any anti-flooding/anti-ddos settings/daemons. While having these is generally a good idea, it's quite annoying when you are doing some API tests and the server suddenly decides to IPTable your home IP for a day. I can neither confirm nor deny that tools like this are a two-edged sword and may or may not have bugs that prevent the tool from removing entries from the block list after the expiry time.