Perl "falsch" upgedatet - was tun? (gelöst) (Allgemeines zu Perl)

[thread]18500[/thread]

Perl "falsch" upgedatet - was tun? [gelöst]

Tags: perl5 cpan Installation SpamAssassin aptitude Ähnliche Threads

Leser: 21

Articles: hide open all | hide show old branches

+12 replies
Plenz

2013-08-06 21:22

User since
2013-08-06
6 Artikel
BenutzerIn

Weil eins meiner der Allgemeinheit zur Verfügung gestellten Perl-Scripte hin und wieder meinen Server lahm legt (vermutlich durch zu viele parallele Aufrufe), habe ich dessen Priorität mit Hilfe von POSIX::nice herunter gesetzt. Zu diesem Zwecke musste ich das CPAN-Modul POSIX installieren. Während der Installation wurde ich gefragt, ob mein Perl upgedatet werden soll, ich habe das bestätigt.

Das Resultat: neben dem bisherigen /usr/share/perl5 habe ich jetzt zusätzlich auch /usr/local/lib/perl5/5.18.0

Zuerst sah alles gut aus, die Einbindung von POSIX funktionierte.

Nun wollte ich aber mal wieder an meinem SpamAssassin herumbasteln, genauer gesagt, an einem selbstgeschrieben Modul. Glücklicherweise hatte ich mir mal ein Testscript geschrieben, mit dem ich dieses Modul testen kann, bevor ich SpamAssassin neu kompiliere. Dieses Script meldete nun plötzlich, dass es Mail::SpamAssassin nicht findet. Klarer Fall: die Suchpfade für Perl in @INC sind jetzt alle auf /usr/local/lib/perl5/5.18.0 umgebogen, während SpamAssassin aber im bisherigen /usr/share/perl5 installiert ist.

Daraufhin habe ich in dem neuen Verzeichnis einfach mal ein paar symbolische Links zum bisherigen Verzeichnis eingebaut, z.B. "Mail -> /usr/share/perl5/Mail". Jetzt meldet mein Testscript lapidar "Speicherzugriffsfehler".

Was nun?

- Die neue Perl-Version wieder deinstallieren? Ich wüsste nicht, wie ich das machen sollte. Wenn ich POSIX deinstalliere, wird das CPAN-Script wohl kaum auf die Idee kommen, auch die zusätzliche Perl-Installation rückgängig zu machen.
- Perl einfach per aptitude nochmal zusätzlich updaten?
- SpamAssassin ganz neu installieren?
- Einfach SpamAssassin wie gewohnt kompilieren und hoffen, dass dabei die neue Perl-Version korrekt eingebunden wird? Wäre zu schön, um wahr zu sein. Aber wenn's schief läuft, ist mein SpamAssassin erst mal futsch, und ich werde von einer Spamlawine überrollt.

Bin für jeden nützlichen Tipp dankbar.
Last edited: 2013-08-06 22:21:35 +0200 (CEST)
- hlubenow
  
  2013-08-07 01:20
  
  User since
  2009-02-22
  875 Artikel
  BenutzerIn
  
  Das Problem dürfte sein, daß es eine Menge in C geschriebene Perl-Module gibt, die für die ursprüngliche Perl-Version kompiliert wurden und nicht für die neue.
  Ich persönlich vermeide aus diesem Grund ein Perl-Update und kann daher ansonsten wahrscheinlich nicht viel weiterhelfen.
  
  Edit: Ach so, wenn Dein Executable, meist "/usr/bin/perl" auf die alte Version zeigt, müßtest Du zum alten Perl zurückkommen. Guck doch mal, ob in "/usr/bin" (bzw. bei der Ausgabe von "which perl") jetzt mehrere Perl-Versionen zu finden sind.
  Last edited: 2013-08-07 01:27:28 +0200 (CEST)
- +3 replies
- pq
  
  2013-08-07 01:53
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  2013-08-06T19:22:39 Plenz
  Zu diesem Zwecke musste ich das CPAN-Modul POSIX installieren.
  
  das ist merkwürdig. wurde da eine bestimmte version von POSIX verlangt?
  normalerweise ist POSIX seit der ersten perl5-version schon dabei.
  welche perl-version ist das? betriebssystem scheint debian zu sein.
  am besten ist es generell, für das installierte perl weitere module mit apt zu installieren, wenn sie als pakete vorhanden sind, aber POSIX sollte wie gesagt schon dabei sein.
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +2 replies
  - Plenz
    
    2013-08-07 09:02
    
    User since
    2013-08-06
    6 Artikel
    BenutzerIn
    
    Erst mal vielen Dank für die Antworten.
    
    which perl -> /usr/local/bin/perl
    
    dort finden sich die beiden Versionen
    
    perl
    perl5.18.0
    
    Die Sache mit POSIX verstehe ich nicht. Wenn ich nach POSIX suche, finde ich
    
    ./usr/local/lib/perl5/5.18.0/i686-linux/auto/POSIX
    ./usr/lib/perl/5.10.1/auto/POSIX
    ./usr/share/i18n/locales/POSIX
    ./root/.cpan/build/perl-5.18.0-YBv6_i/lib/auto/POSIX
    ./root/.cpan/build/perl-5.18.0-YBv6_i/ext/POSIX
    
    Bei meinem Script hatte ich nur die Zeile
    use POSIX qw(nice);
    eingefügt, und das führte zu einer Fehlermeldung, dass POSIX nicht installiert wäre. Obwohl es unter perl/5.10.1 offensichtlich ja doch schon vorhanden war.
    
    Unabhängig von einer Analyse der Ursache würde ich mich allerdings vor allem über Ratschläge freuen, wie ich diese Mehrfachinstallation wieder vereinfache.
    
    Ach ja, falls das wichtig ist: es handelt sich um einen gemieteten Server mit Debian.
    Last edited: 2013-08-07 09:03:57 +0200 (CEST)
    - pq
      
      2013-08-07 09:23
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      das modul POSIX findest du, wenn du nach der datei POSIX.pm suchst.
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
- +7 replies
- Relais
  
  2013-08-07 09:31
  User since
  2003-08-06
  2244 Artikel
  ModeratorIn
  Die lehne-Dich zurück und alles wird so, wie es sein soll-Methode:
  
  Den Link zu den Modulen wieder entfernen
  (Nur!) Dein eigenes Modul in einen Pfad legen, der gefunden wird
  Weiter benötigte Module vie CPAN nachinstallieren
  
  Erst denken, dann posten --
  26. Deutscher Perl- u. Raku -Workshop 15. bis 17.04.2024 in Frankfurt/M.
  
  Winter is Coming
  - +6 replies
  - Plenz
    
    2013-08-07 11:41
    User since
    2013-08-06
    6 Artikel
    BenutzerIn
    
    2013-08-07T07:31:49 Relais
    Die lehne-Dich zurück und alles wird so, wie es sein soll-Methode:
    
    Den Link zu den Modulen wieder entfernen
    (Nur!) Dein eigenes Modul in einen Pfad legen, der gefunden wird
    Weiter benötigte Module vie CPAN nachinstallieren
    
    Ja, das mit dem Zurücklehnen wäre schön :)
    
    Dass ich diese symbolischen Links wieder entfernen muss, ist klar. Bloß: dann wird Mail::Spamassassin nicht mehr gefunden. Mein Modul ist nicht das Problem, sondern dass Spamassassin auf der Struktur aufgebaut ist, die ich durch die Installation von POSIX sozusagen übergebügelt habe.
    
    Und die große Preisfrage lautet: wenn ich SpamAssassin mit
    /etc/init.d/spamassassin restart
    neu kompiliere - wird das funktionieren oder nicht?
    
    Generell finde ich es blöd, dass ich jetzt zwei Perl-Installationen habe: eine "tote", in der aber die Module für Spamassassin stecken, sowie eine neue "lebendige" ohne Spamassassin. Mein Spamassassin funktioniert ja nur deshalb noch, weil er kompiliert ist.
    - +5 replies
    - Linuxer
      
      2013-08-07 12:02
      
      User since
      2006-01-27
      3875 Artikel
      HausmeisterIn
      
      Ich hoffe aber, dass die "Tote" aber noch etwas lebt ;-)
      
      Wenn die Installation halbwegs sauber gelaufen ist, dann wurde die neue Installation unter /usr/local vorgenommen. Deine PATH Variable enthält wahrscheinlich /usr/local/bin vor /usr/bin .
      Damit wird, wenn Du nur perl auf der Kommandozeile eingibst, das neuere Perl in /usr/local/bin gefunden.
      Wenn Du explizit mal /usr/bin/perl -v aufrufst, sollte sich das alte Perl noch melden.
      
      Wenn Dein Spam-Assassin explizit mit /usr/bin/perl aufgerufen wird, sollte das noch die alte Installation nutzen.
      
      Wie sieht /etc/init.d/spamassassin aus? Wird darin einfach "perl" aufgerufen? Oder wird da ein kompletter Pfad zu einem Perl-Interpreter mitgegeben. Ggfs. kann man das init-Skript einfach modifizieren, so dass es /usr/bin/perl aufruft?
      meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
      Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
      - Plenz
        
        2013-08-07 13:26
        
        User since
        2013-08-06
        6 Artikel
        BenutzerIn
        
        Danke, ich habe gerade mein Modul-Testprogramm mit dem kompletten Pfad aufgeraufen (/usr/bin/perl test.pl), und damit lief es einwandfrei.
        Hmm... und ich dachte, die erste Zeile im Script (#!/usr/bin/perl) sorgt für genau das gleiche.
        
        Ich muss jetzt erst mal weg, die Sache mit Spamassassin versuche ich später.
        
        Aber erst mal danke, jetzt habe ich Hoffnung, dass ich die Sache ohne allzu großen Aufwand geregelt kriege.
      - +3 replies
      - Plenz
        
        2013-08-07 18:30
        
        User since
        2013-08-06
        6 Artikel
        BenutzerIn
        
        2013-08-07T10:02:20 Linuxer
        Wie sieht /etc/init.d/spamassassin aus? Wird darin einfach "perl" aufgerufen? Oder wird da ein kompletter Pfad zu einem Perl-Interpreter mitgegeben. Ggfs. kann man das init-Skript einfach modifizieren, so dass es /usr/bin/perl aufruft?
        
        Ja, im init-Script steht der komplette Pfad /usr/bin/perl
        
        Aber wie gesagt, Spamassassin ist bei mir kompiliert, es gibt einen Daemon "spamd". Mein Exim4 ruft /usr/bin/spamc auf.
        
        Vielleicht sollte ich es einfach mal wagen, Spamassassin neu zu kompilieren?
        
        Aber am liebsten würde ich ja die neue via CPAN installierte Version wieder loswerden und dann über aptitude wieder installieren. Das wäre sicherlich das sauberste. Hab' bloß keine Idee, wie das mit dem Loswerden gemacht wird.
        
        +2 replies
        
        Plenz
        
        2013-08-12 10:22
        
        User since
        2013-08-06
        6 Artikel
        BenutzerIn
        
        So, ich habe es getan...
        Da hätte ich eigentlich auch früher drauf kommen müssen: es gibt ja eine Testfunktion, ob Spamassassin korrekt konfiguriert ist. Diese lief fehlerfrei durch.
        Dann habe ich die Luft angehalten und Spamassassin neu kompiliert - und das Ergebnis funktioniert einwandfrei trotz Benutzung der alten Perl-Version.
        Nun habe ich also zwei Perl-Installationen, die sich aber offensichtlich nicht gegenseitig stören, also lasse ich das einfach so.
        Thema gegessen.
        
        GwenDragon
        
        2013-08-12 11:09
        
        User since
        2005-01-17
        14581 Artikel
        Admin1
        
        Mit cpanp -u ... war wohl nicht mehr zurückzukommen, nichts deinstallierbar?
        
        Na ja, wenns auch so geht. Und sich die beiden Perl-Versionen den Betrieb wirklich nicht stören.
        die Drachin Gwendolyn

View all threads created 2013-08-06 21:22.