Suse 12.2 x86_64 - ISDN-Treiber laden dauert 5min

Deutsch (German) Installation/Administration
#1

Hallo Forum,

das Laden der ISDN-Treiber, sowohl beim Systemstart, als auch ein manueller Start durch Aufruf des Scripts /etc/init.d/isdn start dauert exakt 5min lang.
Die ersten 10sek werden alle Treiber erfolgreich geladen, danach beendet sich das Script nicht oder wird vom System-D nicht beendet. Erst nach dem Timeout von 5min wird das ganze abgebrochen und mit der falschen Meldung kommentier, dass das Laden der Treiber fehlgeschlagen sei.

Kann das jemand nachvollziehen, bestätigen oder weiß vielleicht sogar jemand Abhilfe?

System:
openSUSE 12.2 x86_64, kernel 3.4.11_2.16

Gruß
bol_d_or

#2

Welcher Treiber ist es denn? Schau doch mal in /var/log/messages was während des Bootens und des Ladens des Treibers passiert.

#3

Es ist nicht “irgend ein Treiber” - es geht um das Laden des gesamten ISDN-Systems. Da wird zunächst die ISDN-Karte als controller 0 definiert, der capi20-Treiber geladen, dann die diversen Treiberelemente für die ISDN-Karte geladen. Wie gesagt, das ganze passiert in den ersten 10sek, danach passiert nichts mehr, bis ein Timeout das ganze abbricht.
In /var/log/messages sieht das ganze so aus:


Dec 31 15:10:33 linux isdn[4006]: Setting up ISDN card contr0 AVM FRITZ!Card PCI v2.0..done
Dec 31 15:10:33 linux udevd[3360]: NAME="capi20" ignored, kernel device nodes can not be renamed; please fix it in /etc/udev/rules.d/45-isdn.rules:4
Dec 31 15:10:33 linux kernel:   243.423655] CAPI 2.0 started up with major 68 (middleware)
Dec 31 15:10:43 linux isdn[4006]: Loading Driver contr0 1 kcapi capi..done
Dec 31 15:10:43 linux kernel:   254.033692] fcpci: AVM FRITZ!Card PCI driver, revision 0.7.2
Dec 31 15:10:43 linux kernel:   254.033698] fcpci: (fcpci built on Dec  2 2012 at 20:18:11)
Dec 31 15:10:43 linux kernel:   254.033701] fcpci: -- 64 bit CAPI driver --
Dec 31 15:10:43 linux kernel:   254.033758] fcpci: AVM FRITZ!Card PCI found: port 0xec00, irq 20
Dec 31 15:10:43 linux kernel:   254.033761] fcpci: Loading...
Dec 31 15:10:43 linux kernel:   254.033765] fcpci: Driver 'fcpci' attached to fcpci-stack. (304)
Dec 31 15:10:44 linux kernel:   254.252670] fcpci: Stack version 3.11-07
Dec 31 15:10:44 linux kernel:   254.252718] kcapi: controller [001]: fcpci-ec00-20 attached
Dec 31 15:10:44 linux kernel:   254.252719] kcapi: controller [001] "fcpci-ec00-20" ready.
Dec 31 15:10:44 linux kernel:   254.252739] fcpci: Loaded.
Dec 31 15:10:44 linux kernel:   254.264088] ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/1.1.2.3/1.1.2.2/1.1.2.2 loaded
Dec 31 15:10:44 linux kernel:   254.264779] capidrv-1: now up (2 B channels)
Dec 31 15:10:44 linux kernel:   254.264784] capidrv-1: D2 trace enabled
Dec 31 15:10:44 linux isdnlog: isdnlog Version 4.71 starting
Dec 31 15:10:44 linux isdn[4006]: Initializing capi for contr0 (1)..done
Dec 31 15:10:44 linux isdnlog: Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from /usr/lib/isdn/holiday-de.dat]
Dec 31 15:10:44 linux isdnlog: Dest V1.01: File '/usr/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE NL CH BE CN
Dec 31 15:10:44 linux isdnlog: Zone V1.25: Provider 0 File '/usr/lib/isdn/zone-de-dtag.cdb' opened fine - V1.25 K2 C2 N256 T157147 O1 L5
Dec 31 15:10:44 linux isdnlog: Rates   Version 3.12 [27-Feb-2005 22:15:34] loaded [87 Providers, 0 skipped, 1325 Zones, 4755 Areas, 86 Services, 726 Comments, 10 eXceptions, 65 Redirects, 4298 Rates from /usr/lib/isdn/rate-de.dat]
Dec 31 15:10:44 linux isdnlog: (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available)
Dec 31 15:10:44 linux isdnlog: isdn.conf:2 active channels, 2 MSN/SI entries
Dec 31 15:10:44 linux isdnlog: (Data versions: iprofd=0x06  net_cfg=0x06  /dev/isdninfo=0x01)
Dec 31 15:10:44 linux isdnlog: Everything is fine, isdnlog-4.71 is running in full featured mode.
Dec 31 15:12:03 linux su: (to root) markus on /dev/pts/3
Dec 31 15:12:03 linux su: (to root) markus on /dev/pts/3
Dec 31 15:13:48 linux dbus-daemon[706]: dbus[706]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper)
Dec 31 15:13:48 linux dbus[706]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper)
Dec 31 15:13:48 linux dbus-daemon[706]: dbus[706]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Dec 31 15:13:48 linux dbus[706]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Dec 31 15:15:33 linux systemd[1]: isdn.service operation timed out. Terminating.
Dec 31 15:15:33 linux systemd[1]: Unit isdn.service entered failed state.

Die ISDN- und Capitreiber wurden alle geladen und funktionieren auch. Nur ist es sehr lästig bei jedem Bootvorgang 5min warten zu müssen, bis endlich dieses ISDN-script vom System abfebrochen wird.

Gruß
bol_d_or

#4

Das Laden des ISDN-Subsystems und des Kartentreibers selbst geht anscheinend schnell vonstatten. Wie sehen denn die Zeilen vor diesem Ausschnitt aus? Ohne den Kontext ist es fast unmöglich zu sagen, was genau zu den Verzögerungen führt

#5

Hast du das Problem auch, wenn du nicht systemd sondern die init-Scripte benutzt?

#6

Guten Abend,

@ cyberiad

mein ursprünglicher Auszug aus der /var/log/messages betraf einen manuellen Start des ISDN-Systems mittels “/etc/init.d/isdn start” auf der root-console. Hier jetzt mal ein Auszug aus einem Boot-Prozess, leider nur ein Teil, da die Zeichen hier auf 15000 beschränkt sind - der gesamte Bootvorgang wird von über 460000 Zeichen kommentiert:


Dec 31 09:11:31 linux kernel:    11.240587] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input6
Dec 31 09:11:31 linux kernel:    11.240659] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input7
Dec 31 09:11:31 linux kernel:    11.609351] firewire_core 0000:04:06.2: created device fw0: GUID 00023c01410172d2, S400
Dec 31 09:11:31 linux kernel:    11.721741] ath: EEPROM regdomain: 0x809c
Dec 31 09:11:31 linux kernel:    11.721745] ath: EEPROM indicates we should expect a country code
Dec 31 09:11:31 linux kernel:    11.721748] ath: doing EEPROM country->regdmn map search
Dec 31 09:11:31 linux kernel:    11.721751] ath: country maps to regdmn code: 0x52
Dec 31 09:11:31 linux kernel:    11.721755] ath: Country alpha2 being used: CN
Dec 31 09:11:31 linux kernel:    11.721757] ath: Regpair used: 0x52
Dec 31 09:11:31 linux kernel:    11.725323] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
Dec 31 09:11:31 linux kernel:    11.725472] ath5k phy0: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45)
Dec 31 09:11:31 linux kernel:    11.725517] cfg80211: Calling CRDA for country: CN
Dec 31 09:11:31 linux kernel:    11.727684] cfg80211: Regulatory domain changed to country: CN
Dec 31 09:11:31 linux kernel:    11.727685] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Dec 31 09:11:31 linux kernel:    11.727687] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Dec 31 09:11:31 linux kernel:    11.727689] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)
Dec 31 09:11:31 linux kernel:    11.733188] ALSA emufx.c:1569 Installing spdif_bug patch: SB Audigy 2 ZS [SB0360]
Dec 31 09:11:31 linux kernel:    12.287754] Adding 4191228k swap on /dev/sdc5.  Priority:-1 extents:1 across:4191228k 
Dec 31 09:11:31 linux kernel:    12.398434] CAPI 2.0 started up with major 68 (middleware)
Dec 31 09:11:31 linux kernel:    12.486500] nvidia: module license 'NVIDIA' taints kernel.
Dec 31 09:11:31 linux kernel:    12.486505] Disabling lock debugging due to kernel taint
Dec 31 09:11:31 linux kernel:    12.500821] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
Dec 31 09:11:31 linux kernel:    12.500953] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  304.64  Tue Oct 30 10:58:20 PDT 2012
Dec 31 09:11:31 linux kernel:    12.863306] ip6_tables: (C) 2000-2006 Netfilter Core Team
Dec 31 09:11:31 linux kernel:    12.867825] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Dec 31 09:11:31 linux kernel:    12.871856] ip_tables: (C) 2000-2006 Netfilter Core Team
Dec 31 09:11:31 linux kernel:    13.094355] vboxdrv: Found 6 processor cores.
Dec 31 09:11:31 linux kernel:    13.094557] vboxdrv: fAsync=0 offMin=0x5f5 offMax=0x5197
Dec 31 09:11:31 linux kernel:    13.094609] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
Dec 31 09:11:31 linux kernel:    13.094611] vboxdrv: Successfully loaded version 4.2.6 (interface 0x001a0004).
Dec 31 09:11:32 linux kernel:    13.304839] vboxpci: IOMMU not found (not registered)
Dec 31 09:11:32 linux [284]: Bumped block_nr parameter of 8:32 to 16384. This is a temporary hack and should be removed one day.
Dec 31 09:11:33 linux [299]: Inserted module 'microcode'
Dec 31 09:11:33 linux systemd[1]: NetworkManager.service: control process exited, code=exited status=1
Dec 31 09:11:33 linux systemd[1]: Job NetworkManager-wait-online.service/start failed with result 'dependency'.
Dec 31 09:11:33 linux systemd[1]: Unit NetworkManager.service entered failed state.
Dec 31 09:11:33 linux systemd-logind[670]: New seat seat0.
Dec 31 09:11:33 linux udevd[319]: RUN+="socket:..." support will be removed from a future udev release. Please remove it from: /etc/udev/rules.d/71-multipath.rules:7 and use libudev to subscribe to events.
Dec 31 09:11:33 linux ifup[485]: Service network not started and mode 'auto' -> skipping
Dec 31 09:11:33 linux mtp-probe: checking bus 4, device 2: "/sys/devices/pci0000:00/0000:00:12.1/usb4/4-2"
Dec 31 09:11:33 linux mtp-probe: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:12.0/usb3/3-1"
Dec 31 09:11:33 linux mtp-probe: bus: 4, device: 2 was not an MTP device
Dec 31 09:11:33 linux mtp-probe: bus: 3, device: 2 was not an MTP device
Dec 31 09:11:33 linux ifup[596]: Service network not started and mode 'auto' -> skipping
Dec 31 09:11:33 linux udevd[334]: NAME="capi20" ignored, kernel device nodes can not be renamed; please fix it in /etc/udev/rules.d/45-isdn.rules:4
Dec 31 09:11:33 linux avahi-daemon[661]: Found user 'avahi' (UID 107) and group 'avahi' (GID 107).
Dec 31 09:11:33 linux avahi-daemon[661]: Successfully dropped root privileges.
Dec 31 09:11:33 linux avahi-daemon[661]: avahi-daemon 0.6.31 starting up.
Dec 31 09:11:33 linux acpid: starting up with proc fs
Dec 31 09:11:34 linux avahi-daemon[661]: Loading service file /etc/avahi/services/sftp-ssh.service.
Dec 31 09:11:34 linux SuSEfirewall2: Firewall rules set to CLOSE.
Dec 31 09:11:34 linux acpid: 2 rules loaded
Dec 31 09:11:34 linux avahi-daemon[661]: Loading service file /etc/avahi/services/ssh.service.
Dec 31 09:11:34 linux acpid: waiting for events: event logging is off
Dec 31 09:11:34 linux avahi-daemon[661]: Loading service file /etc/avahi/services/udisks.service.
Dec 31 09:11:34 linux avahi-daemon[661]: Network interface enumeration completed.
Dec 31 09:11:34 linux avahi-daemon[661]: Registering HINFO record with values 'X86_64'/'LINUX'.
Dec 31 09:11:34 linux avahi-daemon[661]: Server startup complete. Host name is linux.local. Local service cookie is 2205318100.
Dec 31 09:11:34 linux avahi-daemon[661]: Service "linux" (/etc/avahi/services/udisks.service) successfully established.
Dec 31 09:11:34 linux avahi-daemon[661]: Service "linux" (/etc/avahi/services/ssh.service) successfully established.
Dec 31 09:11:34 linux avahi-daemon[661]: Service "linux" (/etc/avahi/services/sftp-ssh.service) successfully established.
Dec 31 09:11:34 linux boot.localnet[297]: Using boot-specified hostname 'linux.site'
Dec 31 09:11:34 linux boot.localnet[297]: Setting up hostname 'linux'..done
Dec 31 09:11:34 linux boot.localnet[297]: Setting up loopback interface RTNETLINK answers: File exists
Dec 31 09:11:34 linux systemd-modules-load[299]: libkmod: kmod_config_parse: /etc/modprobe.d/10-unsupported-modules.conf line 10: ignoring bad line starting with 'allow_unsupported_modules'
Dec 31 09:11:34 linux boot.localnet[297]: ..done
Dec 31 09:11:34 linux cpufreq[635]: Loading CPUFreq modules..done
Dec 31 09:11:34 linux isdn[638]: Setting up ISDN card contr0 AVM FRITZ!Card PCI v2.0..done
Dec 31 09:11:34 linux cupsd[643]: No limit for Validate-Job defined in policy allowallforanybody and no suitable template found.
Dec 31 09:11:34 linux cupsd[643]: No limit for Cancel-Jobs defined in policy allowallforanybody and no suitable template found.
Dec 31 09:11:34 linux cupsd[643]: No limit for Cancel-My-Jobs defined in policy allowallforanybody and no suitable template found.
Dec 31 09:11:34 linux cupsd[643]: No limit for Close-Job defined in policy allowallforanybody and no suitable template found.
Dec 31 09:11:34 linux cupsd[643]: No limit for CUPS-Get-Document defined in policy allowallforanybody and no suitable template found.
Dec 31 09:11:34 linux cupsd[643]: No JobPrivateAccess defined in policy allowallforanybody - using defaults.
Dec 31 09:11:34 linux cupsd[643]: No JobPrivateValues defined in policy allowallforanybody - using defaults.
Dec 31 09:11:34 linux cupsd[643]: No SubscriptionPrivateAccess defined in policy allowallforanybody - using defaults.
Dec 31 09:11:34 linux cupsd[643]: No SubscriptionPrivateValues defined in policy allowallforanybody - using defaults.
Dec 31 09:11:34 linux SuSEfirewall2_init[666]: Loading basic firewall rules ..done
Dec 31 09:11:34 linux vboxdrv[708]: Starting VirtualBox kernel modules..done
Dec 31 09:11:41 linux isdn[638]: Loading Driver contr0 1 kcapi capi..done
Dec 31 09:11:41 linux kernel:    23.000498] fcpci: AVM FRITZ!Card PCI driver, revision 0.7.2
Dec 31 09:11:41 linux kernel:    23.000505] fcpci: (fcpci built on Dec  2 2012 at 20:18:11)
Dec 31 09:11:41 linux kernel:    23.000509] fcpci: -- 64 bit CAPI driver --
Dec 31 09:11:41 linux kernel:    23.000566] fcpci: AVM FRITZ!Card PCI found: port 0xec00, irq 20
Dec 31 09:11:41 linux kernel:    23.000570] fcpci: Loading...
Dec 31 09:11:41 linux kernel:    23.000575] fcpci: Driver 'fcpci' attached to fcpci-stack. (304)
Dec 31 09:11:42 linux kernel:    23.219858] fcpci: Stack version 3.11-07
Dec 31 09:11:42 linux kernel:    23.219907] kcapi: controller [001]: fcpci-ec00-20 attached
Dec 31 09:11:42 linux kernel:    23.219908] kcapi: controller [001] "fcpci-ec00-20" ready.
Dec 31 09:11:42 linux kernel:    23.219928] fcpci: Loaded.
Dec 31 09:11:42 linux kernel:    23.226505] ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/1.1.2.3/1.1.2.2/1.1.2.2 loaded
Dec 31 09:11:42 linux kernel:    23.226843] capidrv-1: now up (2 B channels)
Dec 31 09:11:42 linux kernel:    23.226845] capidrv-1: D2 trace enabled
Dec 31 09:11:42 linux isdn[638]: Initializing capi for contr0 (1)..done
Dec 31 09:11:42 linux isdnlog: isdnlog Version 4.71 starting
Dec 31 09:11:42 linux isdnlog: Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from /usr/lib/isdn/holiday-de.dat]
Dec 31 09:11:42 linux isdnlog: Dest V1.01: File '/usr/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE NL CH BE CN
Dec 31 09:11:42 linux isdnlog: Zone V1.25: Provider 0 File '/usr/lib/isdn/zone-de-dtag.cdb' opened fine - V1.25 K2 C2 N256 T157147 O1 L5
Dec 31 09:11:42 linux isdnlog: Rates   Version 3.12 [27-Feb-2005 22:15:34] loaded [87 Providers, 0 skipped, 1325 Zones, 4755 Areas, 86 Services, 726 Comments, 10 eXceptions, 65 Redirects, 4298 Rates from /usr/lib/isdn/rate-de.dat]
Dec 31 09:11:42 linux isdnlog: (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available)
Dec 31 09:11:42 linux isdnlog: isdn.conf:2 active channels, 2 MSN/SI entries
Dec 31 09:11:42 linux isdnlog: (Data versions: iprofd=0x06  net_cfg=0x06  /dev/isdninfo=0x01)
Dec 31 09:11:42 linux isdnlog: Everything is fine, isdnlog-4.71 is running in full featured mode.
Dec 31 09:12:21 linux kernel:    62.171371] usb 4-2: USB disconnect, device number 2
...USB-Geschichten
Dec 31 09:16:29 linux kernel:   310.317117] generic-usb 0003:046D:C05A.0008: input,hidraw2: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:12.1-2/input0
Dec 31 09:16:29 linux mtp-probe: checking bus 4, device 7: "/sys/devices/pci0000:00/0000:00:12.1/usb4/4-2"
Dec 31 09:16:29 linux mtp-probe: bus: 4, device: 7 was not an MTP device
Dec 31 09:16:31 linux systemd[1]: isdn.service operation timed out. Terminating.
Dec 31 09:16:31 linux systemd[1]: Unit isdn.service entered failed state.
Dec 31 09:16:31 linux network[1283]: Setting up (localfs) network interfaces:
Dec 31 09:16:31 linux network[1283]: lo
Dec 31 09:16:31 linux ifup[1485]:     lo
Dec 31 09:16:31 linux ifup[1485]:     lo
...
Dec 31 09:35:20 linux systemd-logind[670]: New session 2 of user andi.

@ Fruchtratte:

Nein, system-V habe ich nicht ausprobiert. Diese Möglichkeit gabs in openSUSE 12.1 - in meiner 12.2 ist dies seitens SUSE angeblich nicht mehr vorgesehen und laut diverser Artikel im Netz ein richtiger Aufwand nötig, um dies hier noch hinzubekommen. Ich möchte diesen Aufwand auch gar nicht erst anfangen, weiß der Teufel, was man sich da für andere Probleme wieder einfängt. Ganz abgesehen davon, welche Zeit man da reinsteckt - die muss man erst mal haben.

Gruß
bol_d_or

#7

Hm … kannst du mal probieren die wesentlichen Befehle in /etc/init.d/isdn von Hand auszuführen, also ohne das ohne das Script zu starten?

#8

Klongt einfach - ist es aber nicht - zumindest nicht für mich. Bei Scripten dieses Umfangs muss ich passen. Vielleicht kann mir einer ja sagen, was da wo aufgerufen wird. Ich poste mal hier den für den Start entsprechenden Abschnitt:

case "$ACTION" in
    start)
    MESSAGE="Setting up ISDN card"
    test -c /dev/ippp0 || . scripts/mkdev.sh
    set -- $CONTR_FILES
    for CONTR in "${@#cfg-contr}"; do
        ID="contr${CONTR}"
        test -f "cfg-${ID}" || continue
        STARTMODE=manual
        . cfg-${ID}
        echo -n "$MESSAGE $ID $NAME"
        test_startmode
        RET=$?
        if  $RET -eq 0 ]; then
        test "$MODE" = "hotplug" || test_driver_loaded $DRIVER
        RET=$?
        if  $RET -eq 10 ]; then
            echo -n " ${warn}$DRIVER busy${norm}"
            RET=1
        fi
        if  $RET -eq 15 ]; then
            echo -n " in use"
            RET=0 
        fi
        elif  $RET -eq 99 ]; then
        # MODE = all with hotplug, if device is here (driver loaded)
        # execute to catch first configure (all is used by yast)
        test_driver_loaded $DRIVER
        RET=$?
        if  $RET -ne 10 ]; then
            RET=5
        else
            RET=0
        fi
        fi
        if  $RET -eq 0 ]; then
        test_driver_loaded
        if  -x scripts/add-$DRIVER ] ; then
            . scripts/add-$DRIVER
        else
            LOAD_CONTR="$LOAD_CONTR $CONTR"
            RET=0
        fi
        fi
        rc_failed $RET
        rc_status -v
        MESSAGE="                    "
    done
    CONTR_CNT=0
    test -n "$LOAD_CONTR" && for CONTR in $LOAD_CONTR; do
            MESSAGE="Loading Driver"
        ID="contr$CONTR"
        echo -n "${MESSAGE} ${ID}"
        . cfg-${ID}
        RET=0
        if  -x scripts/load-$DRIVER ] ; then
        . scripts/load-$DRIVER
        else
        /sbin/modprobe $DRIVER $PARAMETER
        RET=$?
        if  -n "$EAZMAP" ]; then
            eval I4L_EAZMAP_$CONTR="\"${ID} ${EAZMAP}\""
            I4L_EAZMAP_IDX="$I4L_EAZMAP_IDX $CONTR"
        fi
        fi
        if  $RET -ge 6 ]; then
        RET=1;
        fi
        rc_failed $RET
        rc_status -v
    done
    MESSAGE="Mapping EAZ"
    test -n "$I4L_EAZMAP_IDX" && for idx in $I4L_EAZMAP_IDX; do
        echo -n "${MESSAGE} contr${idx}"
        eval I4L_EAZMAP=\$I4L_EAZMAP_$idx
        $SBIN/isdnctrl mapping $I4L_EAZMAP >& /dev/null
        RET=$?
        rc_failed $RET
        rc_status -v
        MESSAGE="           "
    done
    # reload smpppd if exist
    test -x /etc/init.d/smpppd && \
        /etc/init.d/smpppd reload >& /dev/null
    ;;
    stop)

Gruß
bol_d_or

#9

Ich habe mir jetzt mal das Programm “systemadm” installiert.
Dieses zeigt vom systemd geladene Dienste an und per Häkchen auch noch nicht geladene, welche zur Verfügung stehen. Solche lassen sich dann mit dem Programm starten. Außerdem zeigt das Programm auch eventuelle Abhängigkeiten diverser Dienste an (welche Dienste vorher geladen sein müssen, welche erst danach funktionieren).

  1. Ergebnis:
    Das Laden der isdn-services läuft genau wie vorher ab - die ersten 10sek werden alle benötigen Treiber und Dienste gestartet, nach 5min gibts ein Timeout mit Fehlermeldung “systemd[1]: isdn.service operation timed out. Terminating.” Die Treiber sind geladen, die Dienste funktionieren.
  2. Ergebnis:
    Ein Versuch, die “capisuite” vor den isdn-services zu laden gelang auf Anhieb, obwohl in den Abhängigkeiten von capisuite explizit erwähnt wird, dass die isdn-services vorher geladen werden müssen (sollen). Ich hatte eigentlich erwartet dass das Laden der capisuite auf Grund nicht aufgelöster Abhängigkeiten entweder nicht durchgeführt wird oder - was perfekt gewesen wäre, die isdn-services automatisch vorher noch geladen werden.

Was sich mir nicht erschließt, ist der Zusammenhang zwischen den “alten” init.d-scripten und dem neuen system-d; greift system-d auf die Scripte zurück oder ist das nur eine Einbahnstraße aus Kombatibilitätsgründen in einer nicht genau definierten Übergangsphase?

Mein erstes Fazit im Moment ist, dass das “Monster” system-d noch an gewaltigen Kinderkrankheiten zu leiden hat- die Reaktionen im Netz auf system-d sind ja entsprechend verhalten bis ziemlich ablehnend.
Schade, dass sich die openSUSE Entwickler dazu entschieden haben, so zeitig auf den system-d - Zug aufzuspringen, ohne vernünftige Werkzeuge dafür zur Verfügung zu stellen.

Gruß
bol_d_or

#10

Also meine erste Vermutung wäre, dass er an der Zeile hängt:

$SBIN/isdnctrl mapping $I4L_EAZMAP >& /dev/null

Systemd kann die Init-Scripte aufrufen, muss aber nicht …

Du kannst mal versuche die Ausgabe von dem Befehl nicht nach /dev/null zu pipen sondern in eine Datei. Aber unbedingt vorher ein Backup von dem Script machen!

#11

O.K.

ich hab nun die Zeile in dem isdn-script so verändert:

 $SBIN/isdnctrl mapping $I4L_EAZMAP >& /home/markus/isdn.log

dann habe ich vorsichtshalber diese Datei angelegt und für alle mit Schreibrechten ausgestattet, Eigentürmer ist root.

Das Laden der ISDN-Treiber dauerte die üblichen 5min, die Datei jedoch blieb leer.

Stimmt vielleicht bei der Syntax etwas nicht ?

Gruß
bol_d_or

#12

Probier mal folgende Varianten:

$SBIN/isdnctrl mapping $I4L_EAZMAP 2>& /home/markus/isdn.log

und:

echo $SBIN/isdnctrl mapping $I4L_EAZMAP >& /home/markus/isdn.log

#13

Bei beiden Varianten der Script-Zeile ergibt sich keinerlei Veränderung - meine angelegte log-Datei ist nach wie vor leer (unberührt seit dem Erstellungsdatum) und die Meldungen in /var/log/messages bleiben immer die gleichen.

Zuletzt hatte ich die obige Zeile komplett auskommentiert - auch hier keine Veränderung (5min - dann Abbruch) und die selben Meldungen in /var/log/messages.

Gruß
bol_d_or

#14

Hm … bau mal irgendwo am Anfang folgende Zeile ein (noch vor dem switch-case, so das sie auf alle Fälle aufgerufen wird):

echo “Hallo Welt” > /home/markus/isdn.log

Wenn die Log-Datei dann immer noch leer ist, benutzt systemd das Init-Script gar nicht. In dem Fall bin ich überfragt …

#15

Ich denke schon ,daß systemd das init-Script benutzt - er mault nämlich nach jeder Änderung des Scripts:

linux:~ # /etc/init.d/isdn start
redirecting to systemctl
Warning: Unit file of created job changed on disk, 'systemctl --system daemon-reload' recommended.

Allerdings hat das Ausführen dieses Befehls bislang noch nie etwas bewirkt!

Und außerdem steht nun in meiner “isdn.log”-Datei:

Hallo Welt

:wink:

Gruß
bol_d_or

#16

Gut … dann können wir noch etwas weiter probieren.

Ich weiß nicht, welche Zeile das Problem macht, aber Arbeit passiert nur im wesentlichen in den Zeilen:


        test_startmode
        test "$MODE" = "hotplug" || test_driver_loaded $DRIVER
        test_driver_loaded $DRIVER
        test_driver_loaded
            . scripts/add-$DRIVER
        . scripts/load-$DRIVER
        /sbin/modprobe $DRIVER $PARAMETER
            eval I4L_EAZMAP_$CONTR="\"${ID} ${EAZMAP}\""
        $SBIN/isdnctrl mapping $I4L_EAZMAP >& /dev/null
        /etc/init.d/smpppd reload

Du kannst versuchen jeweils eine davon auszukommentieren oder ein “echo” davor zu schreiben. Im 2. Fall siehst du, ob das Script überhaupt da hin kommt und was in den Variablen steht.

#17

So… der Test kann ganz schön langwierig werden, wenn man immer 5min warten muss, bis sich was tut - oder auch nichts tut.

Ich liste jetzt mal die einzelnen Befehle und jeweils darunter, was ich so beobachten konnte:


- echo test_startmode

keine Veränderung, keine Meldung auf der Konsole
in /var/log/messages:
Jan 23 21:53:40 linux isdn[22258]: Setting up ISDN card contr0 AVM FRITZ!Card PCI v2.0test_startmode
Jan 23 21:53:40 linux isdn[22258]: ..done


- echo test "$MODE" = "hotplug" || test_driver_loaded $DRIVER

keine Veränderung, keine Meldung auf der Konsole
in /var/log/messages:
Jan 23 22:02:20 linux isdn[22730]: Setting up ISDN card contr0 AVM FRITZ!Card PCI v2.0test manual = hotplug
Jan 23 22:02:20 linux isdn[22730]: ..done


- echo test_driver_loaded $DRIVER

keine Veränderung, keine Meldung auf der Konsole
nix in /var/log/messages


- echo test_driver_loaded

keine Veränderung, keine Meldung auf der Konsole
in /var/log/messages:
Jan 23 22:24:26 linux isdn[23640]: Setting up ISDN card contr0 AVM FRITZ!Card PCI v2.0 in usetest_driver_loaded
Jan 23 22:24:26 linux isdn[23640]: ..done


- echo . scripts/add-$DRIVER

keine Veränderung, keine Meldung auf der Konsole
nix in /var/log/messages


- echo . scripts/load-$DRIVER

keine Veränderung, keine Meldung auf der Konsole
in /var/log/messages:
Jan 23 22:43:26 linux isdn[24542]: Loading Driver contr0. scripts/load-fcpci
Jan 23 22:43:26 linux isdn[24542]: ..done


- echo /sbin/modprobe $DRIVER $PARAMETER

keine Veränderung, keine Meldung auf der Konsole
nix in /var/log/messages


- echo eval I4L_EAZMAP_$CONTR="\"${ID} ${EAZMAP}\""

keine Veränderung, keine Meldung auf der Konsole
nix in /var/log/messages


- echo $SBIN/isdnctrl mapping $I4L_EAZMAP >& /dev/null

keine Veränderung, keine Meldung auf der Konsole
nix in /var/log/messages


- echo /etc/init.d/smpppd reload

keine Veränderung, keine Meldung auf der Konsole
nix in /var/log/messages

Das “-” Zeichen hatte ich natürlich nicht eingegeben, das steht hier nur der Übersichtlichkeit halber.
Auf der Konsole hatte ich grundsätzlich keine weiteren Ausgaben als sonst wie üblich:

redirecting to systemctl
Job failed. See system journal and 'systemctl status' for details.

Bei diversen Befehlen konnte ich kleine Unterschiede in den Meldungen in /var/log/messages ausmachen - jedoch nichts gravierendes oder gar aufschlußreiches.

Ich habe mich in letzter Zeit im Netz mal zu dem Thema “init-Scripte nach systemd umwandeln” umgesehen und finde ausschließlich Beispiele, in welchen es um lediglich einen einzigen Aufruf eines Dienstes oder ähnlichem handelt - bei dem isdn-start geht es ja gleich um mehrere Startsequenzen (Treiber für Karte, capi-Treiber, usw.) - hierfür gibts keinerlei Beispiele. Das scheint dann nicht mehr so trivial zu sein und anscheinend haben es die SUSE-Entwickler dann gleich ganz bleiben lassen :frowning:

Gruß
bol_d_or

#18

Mir fällt nicht mehr wirklich etwas ein. Hast du mal versucht im Yast mit den ISDN-Einstellungen zu spielen??

#19

Kein schlechter Tipp!!
In Yast gibt es zwar fast nichts zum rumspielen - Treiberauswahl (capi-Treiber ohne Quellcode), Landes- und Ortskennziffern und Startart (beim Systemstart, manuell, etc.) - das wars auch schon und alles wie gehabt die vielen Jahre zuvor, die ich diese Karte nun schon nutze.

ABER:
Beim Verlassen von Yast “Beenden” gedrückt (nicht “Abrechen”) - und Yast entlädt erst die ISDN-Treiber und startet das ISDN-System danach neu - und das ganze ratzfatz innerhalb von 11sek - ohne Timeout nach 5min und ohne Fehlermeldung!!!

Ich habe das ganze dann nach einen Neustart nochmals überprüft - der Neustart dauerte ewig, da Yast die Startart wieder auf “beim Systemstart” gestellt hatte. Beim erneuten Aufrufen des ISDN-Systems in Yast und nach erneutem “Beenden” erledigte Yast das Laden der Treiber erneut innerhalb von 11sek.
Anscheinend benutzt Yast nicht das init-Script “isdn” unter /etc/init.d/ sondern irgendwas anderes. Wenn man das jetzt wüsste, könnte man hier Vergleiche anstellen oder das init-Script gleich “umlinken” auf das Script, welches Yast zu benutzen scheint.

Vieleicht benutzt ja Yast schon den system-d :sarcastic:

Gruß
bol_d_or

#20

Da müsste man vermutlich die Yast-Quellen durchstöbern …

Ich würde an deiner Stelle auf 12.3 warten und wenn es dann immer noch nicht funktioniert mal das englischsprachige Forum probieren und/oder einen Bugreport aufmachen.