• what happened to dmesg.log?

    From William Unruh@2:250/1 to All on Wed May 4 18:41:42 2022
    It used to be that the dmesg were written to the log file
    /var/log/dmesg.log. However in Mageia 8 this seems to have disappeared.
    How can I get it back?


    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Wed May 4 19:09:20 2022
    On 2022-05-04, William Unruh <unruh@invalid.ca> wrote:
    It used to be that the dmesg were written to the log file
    /var/log/dmesg.log. However in Mageia 8 this seems to have disappeared.
    How can I get it back?

    Sorry, just /var/log/dmesg , not dmesg.log but it has still disappeared.


    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Wed May 4 19:37:04 2022
    On Wed, 04 May 2022 13:41:42 -0400, William Unruh <unruh@invalid.ca> wrote:
    It used to be that the dmesg were written to the log file
    /var/log/dmesg.log. However in Mageia 8 this seems to have disappeared.
    How can I get it back?

    It was dropped with the switch to systemd. It was used to capture as much of the
    boot log as could be captured before rsyslog started. As there was no way to feed
    those messages to the syslog daemon, they were kept in a separate file.

    With systemd and it's journal, those messages (and more that were previously being
    lost at boot) are all included in the journal. You can still use the dmesg command
    to see those messages using a timestamp instead of date/time.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Wed May 4 22:30:10 2022
    On 2022-05-04, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
    On Wed, 04 May 2022 13:41:42 -0400, William Unruh <unruh@invalid.ca> wrote:
    It used to be that the dmesg were written to the log file
    /var/log/dmesg.log. However in Mageia 8 this seems to have disappeared.
    How can I get it back?

    It was dropped with the switch to systemd. It was used to capture as much of the
    boot log as could be captured before rsyslog started. As there was no way to feed
    those messages to the syslog daemon, they were kept in a separate file.

    With systemd and it's journal, those messages (and more that were previously being
    lost at boot) are all included in the journal. You can still use the dmesg command
    to see those messages using a timestamp instead of date/time.


    Hm, /var/log/dmesg was still there even after syslogd was implimented.
    The problem with the journal is that some of the dmesg messages seem to
    not be there if one for example does journalctl -k which is claimed in
    some places to be the equivalent of dmesg.
    dmesg -T will also produce a date/time which is definitely more useful
    than "seconds since 1970"


    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Wed May 4 23:25:52 2022
    On Wed, 04 May 2022 17:30:10 -0400, William Unruh <unruh@invalid.ca> wrote:
    Hm, /var/log/dmesg was still there even after syslogd was implimented.
    The problem with the journal is that some of the dmesg messages seem to
    not be there if one for example does journalctl -k which is claimed in
    some places to be the equivalent of dmesg.
    dmesg -T will also produce a date/time which is definitely more useful
    than "seconds since 1970"

    You're right it wasn't the switch to systemd. My mistake.

    The log file doesn't automatically get deleted on an upgrade. The install I'm using
    right now started as a Mageia 3 install, and has been upgraded each release, currently running Mageia 8.
    # ll /var/log/dmesg
    -rw-r--r-- 1 root root 71781 Oct 26 2019 /var/log/dmesg

    The first line show the kernel used was 5.5.0-1.mga6, so it was the upgrade to Mageia 7 when the file stopped getting updated.

    journalctl -k is intended to be similar to dmesg, but not identical.

    Without -T, dmesg shows time since the kernel started counting, not since the linux epoch.

    I recommend forgetting about dmesg. Just use "journalctl -b --no-h", or "journalctl -b -1 --no-h", etc.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Thu May 5 01:20:12 2022
    On Wed, 4 May 2022 21:30:10 -0000 (UTC), William Unruh wrote:

    Hm, /var/log/dmesg was still there even after syslogd was implimented.

    I am going to guess some systemd update did away /var/log/dmesg .
    Clean mga8 install.

    # cat /var/log/dmesg
    cat: /var/log/dmesg: No such file or directory

    I remember is was there because I had opened a mga7 bug report about its contents
    did not show up in the journal.

    The problem with the journal is that some of the dmesg messages seem to
    not be there if one for example does journalctl -k which is claimed in
    some places to be the equivalent of dmesg.

    Looking pretty close to me.
    $ journalctl -k
    -- Logs begin at Fri 2022-04-29 06:33:13 CDT, end at Wed 2022-05-04 19:02:05 CD>
    May 03 02:36:37 wb.home.test kernel: Linux version 5.15.35-desktop-2.mga8 (iurt>
    May 03 02:36:37 wb.home.test kernel: Command line: BOOT_IMAGE=/boot/vmlinuz roo>
    May 03 02:36:37 wb.home.test kernel: x86/fpu: x87 FPU will use FXSAVE
    May 03 02:36:37 wb.home.test kernel: signal: max sigframe size: 1440
    May 03 02:36:37 wb.home.test kernel: BIOS-provided physical RAM map:
    May 03 02:36:37 wb.home.test kernel: BIOS-e820: [mem 0x0000000000000000-0x00000>

    need a little less noise
    $ journalctl -k --no-hostname
    -- Logs begin at Fri 2022-04-29 06:33:13 CDT, end at Wed 2022-05-04 19:02:05 CD>
    May 03 02:36:37 kernel: Linux version 5.15.35-desktop-2.mga8 (iurt@ecosse.magei>
    May 03 02:36:37 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz root=LABEL=mga8 >
    May 03 02:36:37 kernel: x86/fpu: x87 FPU will use FXSAVE
    May 03 02:36:37 kernel: signal: max sigframe size: 1440
    May 03 02:36:37 kernel: BIOS-provided physical RAM map:
    May 03 02:36:37 kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000098bff] >

    Note to lurkers, if you are in the systemd-journal group you do not have
    to get to a root prompt to view the system jounal.

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Thu May 5 03:35:43 2022
    On Wed, 04 May 2022 20:20:12 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:

    On Wed, 4 May 2022 21:30:10 -0000 (UTC), William Unruh wrote:

    Hm, /var/log/dmesg was still there even after syslogd was implimented.

    Now I'm more confused. I was looking to see where it was being created, to figure out exactly when it was dropped. It wasn't dropped.

    /lib/systemd/system/mandriva-save-dmesg.service still exists and is enabled.

    Running "systemctl start mandriva-save-dmesg.service" causes the file to
    get updated.

    I don't know why it isn't being run automatically. I'll ask around and open
    a bug report, if it's not intentional.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Thu May 5 04:06:08 2022
    On Wed, 04 May 2022 22:35:43 -0400, David W. Hodgins wrote:
    On Wed, 04 May 2022 20:20:12 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:

    On Wed, 4 May 2022 21:30:10 -0000 (UTC), William Unruh wrote:

    Hm, /var/log/dmesg was still there even after syslogd was implimented.

    Now I'm more confused. I was looking to see where it was being created, to figure out exactly when it was dropped. It wasn't dropped.

    /lib/systemd/system/mandriva-save-dmesg.service still exists and is enabled.

    Running "systemctl start mandriva-save-dmesg.service" causes the file to
    get updated.

    I don't know why it isn't being run automatically. I'll ask around and open
    a bug report, if it's not intentional.

    # systemctl status mandriva-save-dmesg.service

    ● mandriva-save-dmesg.service - Save boot dmesg content
    Loaded: loaded (/usr/lib/systemd/system/mandriva-save-dmesg.service; enabled; vendor preset: enabled)
    Active: inactive (dead)

    journalctl | grep save-dmesg

    May 01 05:40:01 drakscanner[659325]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service
    May 01 05:40:08 drakscanner[659325]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service
    May 04 20:16:13 drakscanner[705679]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service
    May 04 20:16:19 drakscanner[705679]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Thu May 5 05:16:49 2022
    On 5/5/22 13:06, Bit Twister wrote:

    # systemctl status mandriva-save-dmesg.service

    ● mandriva-save-dmesg.service - Save boot dmesg content
    Loaded: loaded (/usr/lib/systemd/system/mandriva-save-dmesg.service; enabled; vendor preset: enabled)
    Active: inactive (dead)

    journalctl | grep save-dmesg

    May 01 05:40:01 drakscanner[659325]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service
    May 01 05:40:08 drakscanner[659325]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service
    May 04 20:16:13 drakscanner[705679]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service
    May 04 20:16:19 drakscanner[705679]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service




    ~]$ systemctl status mandriva-save-dmesg.service
    ● mandriva-save-dmesg.service - Save boot dmesg content
    Loaded: loaded
    (/usr/lib/systemd/system/mandriva-save-dmesg.service; enabled; vendor pres>
    Active: inactive (dead)
    [faeychild@unimatrix ~]$ journalctl | grep save-dmesg

    I got a long pause here (4-5) seconds before the prompt returned with
    nothing

    [faeychild@unimatrix ~]$

    --
    faeychild
    Running plasmashell 5.20.4 on 5.15.35-desktop-2.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Thu May 5 05:30:58 2022
    On Thu, 05 May 2022 00:16:49 -0400, faeychild <faeychild@nomail.afraid.org> wrote:
    ~]$ systemctl status mandriva-save-dmesg.service
    ● mandriva-save-dmesg.service - Save boot dmesg content
    Loaded: loaded
    (/usr/lib/systemd/system/mandriva-save-dmesg.service; enabled; vendor pres>
    Active: inactive (dead)
    [faeychild@unimatrix ~]$ journalctl | grep save-dmesg

    I got a long pause here (4-5) seconds before the prompt returned with nothing

    Use "journalctl -b" to limit the search to only the current boot.

    I strongly recommend setting limits on the size of the journal.
    # grep -v -e ^$ -e ^'#' /etc/systemd/journald.conf
    [Journal]
    SystemMaxUse=200M
    RuntimeMaxUse=200M
    ForwardToSyslog=yes
    ForwardToConsole=yes
    TTYPath=/dev/tty12

    See "man journald.conf" for details. The defaults for the MaxUse are 10% and 15%
    of the size of the filesystem where /var/log/journal/ is stored.

    With 200M my system keeps around a month of data, though it varies depending on what I've been doing.

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Thu May 5 06:32:17 2022
    On Thu, 5 May 2022 14:16:49 +1000, faeychild wrote:
    On 5/5/22 13:06, Bit Twister wrote:

    # systemctl status mandriva-save-dmesg.service

    ● mandriva-save-dmesg.service - Save boot dmesg content
    Loaded: loaded (/usr/lib/systemd/system/mandriva-save-dmesg.service; enabled; vendor preset: enabled)
    Active: inactive (dead)

    journalctl | grep save-dmesg

    May 01 05:40:01 drakscanner[659325]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service
    May 01 05:40:08 drakscanner[659325]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service
    May 04 20:16:13 drakscanner[705679]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service
    May 04 20:16:19 drakscanner[705679]: running: /bin/systemctl --quiet is-enabled mandriva-save-dmesg.service




    ~]$ systemctl status mandriva-save-dmesg.service
    ● mandriva-save-dmesg.service - Save boot dmesg content
    Loaded: loaded
    (/usr/lib/systemd/system/mandriva-save-dmesg.service; enabled; vendor pres>
    Active: inactive (dead)
    [faeychild@unimatrix ~]$ journalctl | grep save-dmesg

    I got a long pause here (4-5) seconds before the prompt returned with nothing

    [faeychild@unimatrix ~]$

    Depends on size of journal and speed of system.
    I have a new_boot_logs script to clear/truncate/delete log/journal files and reboot system.

    # ls -l --all --escape --human-readable --color=auto' /var/log/journal/$(cat /etc/machine-id)
    total 153M
    drwxr-sr-x+ 2 root systemd-journal 24K May 4 22:08 .
    drwxr-sr-x+ 3 root systemd-journal 4.0K Jan 14 14:01 ..
    -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 system@688d8b538b6949b397c6928df9bf4ee2-0000000001953c37-0005de3b0c47acc3.journal
    -rw-r-----+ 1 root systemd-journal 8.0M May 5 00:17 system.journal
    -rw-r-----+ 1 root systemd-journal 8.0M May 5 00:16 user-1500.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1501.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1504.journal -rw-r-----+ 1 root systemd-journal 8.0M May 5 00:14 user-1508.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1510.journal -rw-r-----+ 1 root systemd-journal 8.0M May 5 00:14 user-1511.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1512.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1513.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1515.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1522.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1526.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1527.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1528.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1530.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1531.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1534.journal -rw-r-----+ 1 root systemd-journal 8.0M May 4 22:08 user-1535.journal

    Note no size limits set
    # grep -v -e ^$ -e ^'#' /etc/systemd/journald.conf
    [Journal]
    ForwardToConsole=yes
    TTYPath=/dev/tty12

    new_boot_logs calls my new_journal script

    # cat local/bin/new_journal
    #!/bin/bash #*******************************************************************************
    #* new_journal - empty boot/application logs.
    #*
    #*
    #* http://www.freedesktop.org/software/systemd/man/systemd-journald.service
    #* flush logs and request immediate rotation of the journal files
    #* then delete rotated files and all user logs.
    #*
    #* Usage: new_journal
    #* #*******************************************************************************

    PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin

    #**********************************
    #* remove any editor backup files
    #**********************************

    rm --force /etc/modprobe.d/*~
    rm --force /etc/sysconfig/network-scripts/ifcfg-*~


    type dovecot > /dev/null 2>&1
    if [ $? -eq 0 ] ; then
    systemctl --quiet is-active dovecot 2> /dev/null
    if [ $? -eq 0 ] ; then
    systemctl stop dovecot
    fi
    truncate -s 0 /var/log/dovecot/errors.log
    fi

    _log_dir=/var/log/journal/$(cat /etc/machine-id)
    if [ -e $_log_dir ] ; then
    echo "Wiping journal logs"
    journalctl --rotate > /dev/null 2>&1
    journalctl --vacuum-time=1s
    sleep 2
    rm --force $_log_dir/user-*.journal
    rm --force $_log_dir/*@*
    fi

    type dovecot > /dev/null 2>&1
    if [ $? -eq 0 ] ; then
    systemctl --quiet is-enabled dovecot 2> /dev/null
    if [ $? -eq 0 ] ; then
    systemctl start dovecot
    truncate -s 0 /var/log/dovecot/errors.log
    fi
    fi

    pkill --full "fa --no-pager"

    #************************ end new_journal ******************************

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Thu May 5 07:37:48 2022
    On 2022-05-05, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Wed, 4 May 2022 21:30:10 -0000 (UTC), William Unruh wrote:

    Hm, /var/log/dmesg was still there even after syslogd was implimented.

    I am going to guess some systemd update did away /var/log/dmesg .
    Clean mga8 install.

    # cat /var/log/dmesg
    cat: /var/log/dmesg: No such file or directory

    I remember is was there because I had opened a mga7 bug report about its contents
    did not show up in the journal.

    The problem with the journal is that some of the dmesg messages seem to
    not be there if one for example does journalctl -k which is claimed in
    some places to be the equivalent of dmesg.

    Looking pretty close to me.
    $ journalctl -k
    -- Logs begin at Fri 2022-04-29 06:33:13 CDT, end at Wed 2022-05-04 19:02:05 CD>
    May 03 02:36:37 wb.home.test kernel: Linux version 5.15.35-desktop-2.mga8 (iurt>
    May 03 02:36:37 wb.home.test kernel: Command line: BOOT_IMAGE=/boot/vmlinuz roo>
    May 03 02:36:37 wb.home.test kernel: x86/fpu: x87 FPU will use FXSAVE
    May 03 02:36:37 wb.home.test kernel: signal: max sigframe size: 1440
    May 03 02:36:37 wb.home.test kernel: BIOS-provided physical RAM map:
    May 03 02:36:37 wb.home.test kernel: BIOS-e820: [mem 0x0000000000000000-0x00000>

    need a little less noise
    $ journalctl -k --no-hostname
    -- Logs begin at Fri 2022-04-29 06:33:13 CDT, end at Wed 2022-05-04 19:02:05 CD>
    May 03 02:36:37 kernel: Linux version 5.15.35-desktop-2.mga8 (iurt@ecosse.magei>
    May 03 02:36:37 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz root=LABEL=mga8 >
    May 03 02:36:37 kernel: x86/fpu: x87 FPU will use FXSAVE
    May 03 02:36:37 kernel: signal: max sigframe size: 1440
    May 03 02:36:37 kernel: BIOS-provided physical RAM map:
    May 03 02:36:37 kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000098bff] >

    In my case I was looking at the debugging of wpa_supplicant and a number
    of dmesg messages came from the wireless card number. They were not in journalctl -k, which I think just give you the kernel messages, and
    dmesg has more than just kernel messages.

    (for example on one of my machine it also has a bunch of shorewall Drop messages as well.)


    Note to lurkers, if you are in the systemd-journal group you do not have
    to get to a root prompt to view the system jounal.

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Thu May 5 07:37:17 2022
    See https://bugs.mageia.org/show_bug.cgi?id=30380

    Regards, Dave Hodgins

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Doug Laidlaw@2:250/1 to All on Thu May 5 10:19:47 2022
    On 5/5/22 03:41, William Unruh wrote:
    It used to be that the dmesg were written to the log file
    /var/log/dmesg.log. However in Mageia 8 this seems to have disappeared.
    How can I get it back?

    I didn't know that it even existed. dmesg|tail and the systemd journal
    are all that I have ever needed. On BT's advice, I added my username to
    the "journalctl" group, allowing me to view the journal as an ordinary user.


    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: Aioe.org NNTP Server (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Thu May 5 15:02:48 2022
    On Thu, 5 May 2022 06:37:48 -0000 (UTC), William Unruh wrote:

    In my case I was looking at the debugging of wpa_supplicant and a number
    of dmesg messages came from the wireless card number. They were not in journalctl -k, which I think just give you the kernel messages,

    man journalctl suggests you are correct.

    and dmesg has more than just kernel messages.

    Up to a point in time, has been my experience. I have converted my brain
    to always use journalctl for hunting info/messages.

    It greatly helps to have a wrapper script to take any number of keyword arguments to search with.

    Example: $ ujctl enp3s0
    # looking in journalctl
    May 04 22:08:02 systemd-networkd[508]: enp3s0: Failed to send DHCP RELEASE, ignoring: Operation not permitted
    May 04 22:08:02 systemd-networkd[508]: enp3s0: DHCP lease lost
    May 04 22:11:43 kernel: r8169 0000:03:00.0 enp3s0: renamed from eth0
    May 04 22:11:43 systemd-networkd[507]: eth0: Interface name change detected, eth0 has been renamed to enp3s0.
    May 04 22:11:44 systemd-networkd[507]: enp3s0: Link UP
    May 04 22:11:44 kernel: r8169 0000:03:00.0 enp3s0: Link is Down
    May 04 22:11:46 kernel: r8169 0000:03:00.0 enp3s0: Link is Up - 1Gbps/Full - flow control rx/tx
    May 04 22:11:46 systemd-networkd[507]: enp3s0: Gained carrier
    May 04 22:11:49 systemd-networkd[507]: enp3s0: DHCPv4 address 192.168.50.132/24 via 192.168.50.1



    I also automagically launch two xterms upon login.
    One is a 5 line I pin to the desktop and the other in window 0 is a 24
    line I can scroll back to see what went on.

    xterm -title wb_mga8_8_o0_xtail journalctl --no-hostname -fa --no-pager \
    -fn 9x15 -fg black -bg SpringGreen3 -geom 135x5+20+0

    xterm -title wb_mga8_8_o0_xcon journalctl --no-hostname -fa --no-pager \
    -fn 9x15 -fg black -bg SpringGreen3 -geom 135x24+20+130

    --- MBSE BBS v1.0.8 (Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)