[Eisfair] [gelöst] Update Base 2.8.2 online

[Helmut Backhaus]

Hallo Marcus,

Am 28.01.2018 um 21:31 schrieb Marcus Roeckrath:
> Hallo Helmut,
> 
> Helmut Backhaus wrote:
> 
>>>> In der Datei steht ja auch nur die Job-Nummer drin ...
>>>> Deshalb hatte ich gedacht das wäre nicht so ganz falsch die Datei dort
>>>> abzulegen. Die Pid-Files liegen ja auch alle dort, aber gut.
>>>
>>> Die PID-Files sind ja nach einem Reboot auch wertlos, denn die
>>> zugehörigen Prozesse überleben einen Reboot sowieso nicht - da können
>>> Intel und Co. noch soviel Schrott verdrahten.
>>
>> Das verstehe ich ja, aber warum tritt das jetzt erst nach dem Update auf?
> 
> Da kann ich gerade nicht folgen.
> 
> Was tritt "erst nach dem Update auf">
>> Das gleiche hätte bei jedem Kernel update auch auftreten müssen, oder?
> 
> Was genau?
> 
> Das dein at-Job hängt?

Jo, es bleibt ja anscheinend sofort nach dem Update hängen!
Dann geht da auch nichts mehr weiter!

Wenn das nur an der Datei in "/run" liegen würde hötte es bei jedem
Kernelupdate auch passieren müssen, oder?

> 
>> Hier mal was passiert ist:
>> ----->
>> Vor dem Update:
>> atq
>> 19612   Sun Jan 28 16:56:00 2018 a root
>>
>> Nach dem Update, vor dem Reboot:
>> 19612   Sun Jan 28 17:11:00 2018 = root
>>
>> Die Datei in /var/spool/cron/atjobs
>> Heist dann:
>> '=04c9c0181d52b' (vorher ohne "=")
> 
> Wenn ein atjob aktiviert wird, wechselt das erste Zeichen des Dateinamens
> nach =. Nach Abarbeiten des Jobs wird die Datei gelöscht.
> 
>> Als das der Fall war, habe ich dann das Base-update durchgeführt und die
>> libffi7 *NICHT* gemacht!
>>
>> Nun lief das Update problemlos durch (tat es ja vorher auch, aber ...)
>> und auch der at-job wurde nach dem reboot ausgelöst und abgearbeitet
>> (der alte). Es wurde zwar kein neuer at-job angelegt, aber dass ist in
>> diesem Fall richtig und liegt in den Prüfkriterien begründet die nicht
>> erfüllt waren. Also alles gut!
>>
>> Nachdem ich nun den Update Checker händisch gestartet habe wurde auch
>> sofort wieder ein at-job angelegt und auch alle 3 Minuten erneuert bis
>> ich das anstehende Update (libffi7) durchgeführt habe.
> 
> Du willst damit sagen, dass nach dem Update auf libffi7 die Probleme
> auftreten?
> 
> Nur wenn während des Update auch ein at-Job aktiv war oder auch wenn der
> erst nach dem Update erzeugt wurde.
> 
>> Es geht also alles wieder!
> 
> Gut.
> 
>> Aber warum das erst jetzt auftritt ist mir wie ja bereits weiter oben
>> geschrieben *nicht_klar!* Wenn es nur an der Datei in /run/ gelegen
>> hätte, hätte es schon viel früher auftreten müssen. Ich nutze dieses
>> Script schon über ein Jahr.
> 
> Das base-Update tauscht einige wesentliche Libs aus, deshalb auch die
> Rebootnotwendigkeit, die die meisten base-Updates nicht erfordern.
> 

Hier sehe ich das Problem!
Ich glaube, dass etwas fehlt um das Script fertig auszuführen.

Bei der Maschine, an der ich den Pfad vorher angepasst habe, hat es
funktioniert weil der laufende Job zwangsweise beendet wurde. Denn das
"atjob01" file war vorhanden. Somit greift das hier:
if [ -s $at_file ]; then
    atjob=$(cat $at_file)
    atrm $atjob &> /dev/null <--- Diese Zeile schießt den Job ab!
    rm -f $at_file
fi

Aber diese Ablaufkontrolle wird ja nicht aktiv wenn das at_file fehlt!,
was dann zur Folge hat, dass der Job nicht beendet wird.

Aber auf der anderen Seite werden wir wohl nicht herausfinden was
letztendlich das Blockieren ausgelöst hat. Und nur um es nun genau zu
wissen, noch mal so eine Maschine aufzusetzen halte ich für übertrieben.

Wissen ist zwar Macht, aber nicht wissen macht auch nix! :-))
Manchmal zumindest ...
Mut zur Lücke ist auch nicht das schlechteste :-))

-- 
Gruß,
Helmut