Re: OpenSMTPD won't start as part of systemd
On 10/29/2021 7:16 AM, Paul M. Foster wrote: On 10/28/21 10:17 PM, David Wright wrote: On Thu 28 Oct 2021 at 21:34:26 (-0400), Paul M. Foster wrote: On 10/28/21 5:11 PM, Greg Wooledge wrote: On Thu, Oct 28, 2021 at 04:42:52PM -0400, Paul M. Foster wrote: This is just an annoyance, but it really shouldn't happen. As my system is rebooting, and all the startup chatter echos to the screen, I notice that OpenSMTPd fails to start. Once I'm logged in, I can start it manually with no problem. When I look at the failure mode, it appears that it thinks the "eno1" interface isn't functioning, so it can't monitor that interface. Are you bringing up eno1 with /etc/network/interfaces? If so, make sure it's marked as "auto", not as "allow-hotplug". Well, that's interesting. Here is my /etc/network/interfaces: === source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback === There's nothing in /etc/network/interfaces.d/ . This is a stock Debian 11 install, so whatever's in this file hasn't been messed with. No mention of eno1. However, it DOES come up. Any clues? Perhaps look at your logs and dmesg; and post how your networking is intended to come up. Cheers, David. A lot to examine... One thing stands out. There is an error of sorts in /etc/daemon.log: Oct 26 17:44:05 dudley systemd-udevd[271]: /usr/lib/udev/rules.d/80-ifupdown.rules: 2 Unknown group 'netdev', ignoring I "accidentally" deleted the "netdev" group a few days ago. I wonder if that's the reason. If it was working before that removal, that's probably it!!! :) -- John Doe
Re: OpenSMTPD won't start as part of systemd
On 10/29/2021 6:39 AM, Paul M. Foster wrote: On 10/28/21 9:59 PM, Greg Wooledge wrote: On Thu, Oct 28, 2021 at 09:34:26PM -0400, Paul M. Foster wrote: Well, that's interesting. Here is my /etc/network/interfaces: === source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback === There's nothing in /etc/network/interfaces.d/ . This is a stock Debian 11 install, so whatever's in this file hasn't been messed with. No mention of eno1. However, it DOES come up. Any clues? There's no such thing as a "stock install". There are many possible installs, depending on which choices you make during the installation. If your interface isn't defined in /e/n/i then the most likely place it's being brought up is in Network-Manager. If it's not N-M then perhaps someone has configured your system to use systemd-networkd, but that's not enabled by default in Debian, so it's far less common. How about "/etc/NetworkManager/system-connections/Wired connection 1" (who comes up with these Windows filenames?): === [connection] id=Wired connection 1 uuid=7bb23b3a-c750-4c65-ae82-164f7359ea7d type=802-3-ethernet [802-3-ethernet] [ipv4] method=auto [ipv6] method=auto ip6-privacy=2 === "Stock install" in this case means I just let the installer set up the networking, etc. Since eno1 is the wired connection, I assume this is where it gets set up. However, this doesn't really answer the question of why eno1 apparently not ready when OpenSMTPd wants to start. Race condition, it looks like your interface is broaght up after the smtp service. -- John Doe
Re: OpenSMTPD won't start as part of systemd
On 10/28/21 10:17 PM, David Wright wrote: On Thu 28 Oct 2021 at 21:34:26 (-0400), Paul M. Foster wrote: On 10/28/21 5:11 PM, Greg Wooledge wrote: On Thu, Oct 28, 2021 at 04:42:52PM -0400, Paul M. Foster wrote: This is just an annoyance, but it really shouldn't happen. As my system is rebooting, and all the startup chatter echos to the screen, I notice that OpenSMTPd fails to start. Once I'm logged in, I can start it manually with no problem. When I look at the failure mode, it appears that it thinks the "eno1" interface isn't functioning, so it can't monitor that interface. Are you bringing up eno1 with /etc/network/interfaces? If so, make sure it's marked as "auto", not as "allow-hotplug". Well, that's interesting. Here is my /etc/network/interfaces: === source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback === There's nothing in /etc/network/interfaces.d/ . This is a stock Debian 11 install, so whatever's in this file hasn't been messed with. No mention of eno1. However, it DOES come up. Any clues? Perhaps look at your logs and dmesg; and post how your networking is intended to come up. Cheers, David. A lot to examine... One thing stands out. There is an error of sorts in /etc/daemon.log: Oct 26 17:44:05 dudley systemd-udevd[271]: /usr/lib/udev/rules.d/80-ifupdown.rules: 2 Unknown group 'netdev', ignoring I "accidentally" deleted the "netdev" group a few days ago. I wonder if that's the reason. Paul
Re: OpenSMTPD won't start as part of systemd
On 10/28/21 9:59 PM, Greg Wooledge wrote: On Thu, Oct 28, 2021 at 09:34:26PM -0400, Paul M. Foster wrote: Well, that's interesting. Here is my /etc/network/interfaces: === source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback === There's nothing in /etc/network/interfaces.d/ . This is a stock Debian 11 install, so whatever's in this file hasn't been messed with. No mention of eno1. However, it DOES come up. Any clues? There's no such thing as a "stock install". There are many possible installs, depending on which choices you make during the installation. If your interface isn't defined in /e/n/i then the most likely place it's being brought up is in Network-Manager. If it's not N-M then perhaps someone has configured your system to use systemd-networkd, but that's not enabled by default in Debian, so it's far less common. How about "/etc/NetworkManager/system-connections/Wired connection 1" (who comes up with these Windows filenames?): === [connection] id=Wired connection 1 uuid=7bb23b3a-c750-4c65-ae82-164f7359ea7d type=802-3-ethernet [802-3-ethernet] [ipv4] method=auto [ipv6] method=auto ip6-privacy=2 === "Stock install" in this case means I just let the installer set up the networking, etc. Since eno1 is the wired connection, I assume this is where it gets set up. However, this doesn't really answer the question of why eno1 apparently not ready when OpenSMTPd wants to start. Paul
Re: OpenSMTPD won't start as part of systemd
On Thu 28 Oct 2021 at 21:34:26 (-0400), Paul M. Foster wrote: > On 10/28/21 5:11 PM, Greg Wooledge wrote: > > On Thu, Oct 28, 2021 at 04:42:52PM -0400, Paul M. Foster wrote: > > > This is just an annoyance, but it really shouldn't happen. As my system is > > > rebooting, and all the startup chatter echos to the screen, I notice that > > > OpenSMTPd fails to start. Once I'm logged in, I can start it manually with > > > no problem. When I look at the failure mode, it appears that it thinks the > > > "eno1" interface isn't functioning, so it can't monitor that interface. > > Are you bringing up eno1 with /etc/network/interfaces? If so, make > > sure it's marked as "auto", not as "allow-hotplug". > > Well, that's interesting. Here is my /etc/network/interfaces: > > === > source /etc/network/interfaces.d/* > # The loopback network interface > auto lo > iface lo inet loopback > === > > There's nothing in /etc/network/interfaces.d/ . This is a stock Debian > 11 install, so whatever's in this file hasn't been messed with. No > mention of eno1. However, it DOES come up. Any clues? Perhaps look at your logs and dmesg; and post how your networking is intended to come up. Cheers, David.
Re: OpenSMTPD won't start as part of systemd
On Thu, Oct 28, 2021 at 09:34:26PM -0400, Paul M. Foster wrote: > Well, that's interesting. Here is my /etc/network/interfaces: > > === > > source /etc/network/interfaces.d/* > > > # The loopback network interface > > auto lo > > iface lo inet loopback > > === > > There's nothing in /etc/network/interfaces.d/ . This is a stock Debian 11 > install, so whatever's in this file hasn't been messed with. No mention of > eno1. However, it DOES come up. Any clues? There's no such thing as a "stock install". There are many possible installs, depending on which choices you make during the installation. If your interface isn't defined in /e/n/i then the most likely place it's being brought up is in Network-Manager. If it's not N-M then perhaps someone has configured your system to use systemd-networkd, but that's not enabled by default in Debian, so it's far less common.
Re: OpenSMTPD won't start as part of systemd
On 10/28/21 5:11 PM, Greg Wooledge wrote: On Thu, Oct 28, 2021 at 04:42:52PM -0400, Paul M. Foster wrote: Folks: This is just an annoyance, but it really shouldn't happen. As my system is rebooting, and all the startup chatter echos to the screen, I notice that OpenSMTPd fails to start. Once I'm logged in, I can start it manually with no problem. When I look at the failure mode, it appears that it thinks the "eno1" interface isn't functioning, so it can't monitor that interface. Are you bringing up eno1 with /etc/network/interfaces? If so, make sure it's marked as "auto", not as "allow-hotplug". Well, that's interesting. Here is my /etc/network/interfaces: === source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback === There's nothing in /etc/network/interfaces.d/ . This is a stock Debian 11 install, so whatever's in this file hasn't been messed with. No mention of eno1. However, it DOES come up. Any clues? Paul
Re: OpenSMTPD won't start as part of systemd
On Thu, Oct 28, 2021 at 04:42:52PM -0400, Paul M. Foster wrote: > Folks: > > This is just an annoyance, but it really shouldn't happen. As my system is > rebooting, and all the startup chatter echos to the screen, I notice that > OpenSMTPd fails to start. Once I'm logged in, I can start it manually with > no problem. When I look at the failure mode, it appears that it thinks the > "eno1" interface isn't functioning, so it can't monitor that interface. Are you bringing up eno1 with /etc/network/interfaces? If so, make sure it's marked as "auto", not as "allow-hotplug".
OpenSMTPD won't start as part of systemd
Folks:
This is just an annoyance, but it really shouldn't happen. As my system
is rebooting, and all the startup chatter echos to the screen, I notice
that OpenSMTPd fails to start. Once I'm logged in, I can start it
manually with no problem. When I look at the failure mode, it appears
that it thinks the "eno1" interface isn't functioning, so it can't
monitor that interface. The config file for OpenSMTPd specifies that it
should listen on localhost and eno1. I looks at the systemd config file
for this package, and it specifies that this unit should executed after
"network.target" ("After=network.target"). I'm not that familiar with
systemd.
Any clues on how to fix this? Is it a systemd problem, or something else?
Paul
Correct way to build in-tree module?
Hi, I'd like to build a module that is in-tree, but not enabled by the Debian kernel by default (module 'pmbus', selected by CONFIG_PMBUS). I would rather not build an entire custom kernel just for one module. Most of the resources out there are for building *out of tree* modules, but this is in-tree. Or, they tell you how to do a one-time build of the module, but not how to get it into DKMS or anything that would keep the module up to date as you install new kernel versions. The module is not listed in module-assistant either. So, what is the right (or at least, best) way to do this, that won't break on a kernel update? Thanks, Matt
Re: Mutt can not delete mails
On Thu, 28 Oct 2021, Hans wrote: I answer yes, and it appears "temporary file could not be created". Pressing again "q" and now answer "no", mutt closes. Does this help? check the ownership/permissions on /tmp Should be: drwxrwxrwt 12 root root 8192 Oct 28 17:05 . I've noticed some issues with upgrading ancient original installs (some going all the way back to potato) where /tmp doesn't have the correct permission but the system has worked perfectly prior to upgrade. I've not tried to investigate - I don't know if the permission/ownership was always wrong or has been changed as part of the upgrade. (One possibility would have been that /tmp was, for some unknown reason, owned by me as mode 775 and got changed to root.root mode 775 instead of mode 1777. These problem systems are sufficiently old that it's perfectly possible that I hacked something I didn't understand all those years ago when writing to /tmp failed) Tim.
Re: Mutt can not delete mails
On Thu, 2021-10-28 at 17:48 +0200, Hans wrote: > Oh, and I forgot to mention or make clear: > > The file /var/mail/myusername does not be reduzed to 0, and as the user > myusername I can not manually delete this file, although (if I am not > wrong!), > I should be able to, as it is rw for me. You can't delete the file because that requires modifying the directory containing it, i.e. /var/mail/ and you don't have permissions for that. These are the permissions you showed us... ls -la /var/mail/ drwxrwsr-x 2 root mail4096 28. Okt 15:12 *.* drwxr-xr-x 13 root root4096 2. Sep 18:37 *..* -rw-rw 1 myusername mail 2090109 28. Okt 15:02 myusername So /var/mail/ has owner 'root', group 'mail', and isn't writeable by others. You do have permission to modify the contents of file 'myusername' as you are the owner, and owner has write permission set. -- Tixy
Re: Mutt can not delete mails
On Thu, Oct 28, 2021 at 05:48:31PM +0200, Hans wrote: > Oh, and I forgot to mention or make clear: > > The file /var/mail/myusername does not be reduzed to 0, and as the user > myusername I can not manually delete this file, although (if I am not > wrong!), > I should be able to, as it is rw for me. Incorrect. Deleting a file requires write permissions on the directory it's in. The permissions on the file itself are irrelevent.
Re: Mutt can not delete mails
Oh, and I forgot to mention or make clear: The file /var/mail/myusername does not be reduzed to 0, and as the user myusername I can not manually delete this file, although (if I am not wrong!), I should be able to, as it is rw for me. Something special (maybe this is important): The directory /var resides on an own partition, which is luks encrypted. But on the other machine (32-bit) where mutt is working well, is the same partition structure. What did I miss? Best Hans
Re: Mutt can not delete mails
Am Donnerstag, 28. Oktober 2021, 16:48:20 CEST schrieb David Wright: Thank you for all the help! First of all, I checked, if there is a nuttrc in my ~/HOME, but there is none. But there is a Muttrc (yes, with capital letter) below /etc, so I suppose this takes the control. However, I never changed this, but maybe there is a configuration issue. The issue I described in my mails appeared in earlier times (one or tw years ago), and then after an updgrade everything worked fine. After a new upgrade (about 1 or 1,5 years ago), I remarked that issue again (I am not sure, but I think, I even wrote a bugreport on it, as I was sure, this was a bug). Since then there was no change, but it could be, that my existing /etc/Muttrc is bad, so that as an upgrade does not ovwerwrite a config file, the bug is in there. There is nothing secret, this is the content of my /etc/Muttrc: # # System configuration file for Mutt # # Default list of header fields to weed when displaying. # Ignore all lines by default... ignore * # ... then allow these through. unignore from: subject to cc date x-mailer x-url user-agent # Display the fields in this order hdr_order date from to cc subject # emacs-like bindings bind editor"\e"kill-word bind editor"\e" kill-word # map delete-char to a sane value bind editor delete-char # some people actually like these settings #set pager_stop #bind pager previous-line #bind pager next-line # Specifies how to sort messages in the index menu. set sort=threads # The behavior of this option on the Debian mutt package is # not the original one because exim4, the default SMTP on Debian # does not strip bcc headers so this can cause privacy problems; # see man muttrc for more info #unset write_bcc # Postfix and qmail use Delivered-To for detecting loops unset bounce_delivered set mixmaster="mixmaster-filter" # System-wide CA file managed by the ca-certificates package set ssl_ca_certificates_file="/etc/ssl/certs/ca-certificates.crt" # imitate the old search-body function macro index \eb "~b " "search in message bodies" # simulate the old url menu macro index,pager,attach,compose \cb "\ set my_pipe_decode=\$pipe_decode pipe_decode\ urlview\ set pipe_decode=\$my_pipe_decode; unset my_pipe_decode" \ "call urlview to extract URLs out of a message" # Show documentation when pressing F1 macro generic,pager " zcat /usr/share/doc/mutt/manual.txt.gz | sensible- pager" "show Mutt documentation" # show the incoming mailboxes list (just like "mutt -y") and back when pressing "y" # note: these macros have been subsumed by the function. # macro index y "?" "show incoming mailboxes list" # macro pager y "?" "show incoming mailboxes list" bind browser y exit # Handler for gzip compressed mailboxes # open-hook '\.gz$' "gzip -cd '%f' > '%t'" # close-hook '\.gz$' "gzip -c '%t' > '%f'" # append-hook '\.gz$' "gzip -c '%t' >> '%f'" # If Mutt is unable to determine your site's domain name correctly, you can # set the default here. (better: fix /etc/mailname) # # set hostname=cs.hmc.edu # If your sendmail supports the -B8BITMIME flag, enable the following # # set use_8bitmime # Use mime.types to look up handlers for application/octet-stream. Can # be undone with unmime_lookup. mime_lookup application/octet-stream # Upgrade the progress counter every 250ms, good for mutt over SSH # see http://bugs.debian.org/537746 set time_inc=250 # Allow mutt to understand References, Cc and In-Reply-To as headers in mailto: mailto_allow = cc in-reply-to references ## ## *** DEFAULT SETTINGS FOR THE ATTACHMENTS PATCH *** ## ## ## Please see the manual (section "attachments") for detailed ## documentation of the "attachments" command. ## ## Removing a pattern from a list removes that pattern literally. It ## does not remove any type matching the pattern. ## ## attachments +A */.* ## attachments +A image/jpeg ## unattachments +A */.*
Re: Mutt can not delete mails
On Thu 28 Oct 2021 at 10:33:58 (-0400), Greg Wooledge wrote: > I'm wondering, in particular, if there is some setting in mutt that > tells it to attempt to delete the inbox file if it reaches 0 messages, > and that perhaps you've enabled it. If so, you'll want to disable it. That /would/ be a bug, because: 3.257. save_empty Type: boolean Default: yes When unset, mailboxes which contain no saved messages will be removed when closed (the exception is $spoolfile which is never removed). If set, mailboxes ↑ are never removed. Note: This only applies to mbox and MMDF folders, Mutt does not delete MH and Maildir directories. Unless, that is, the OP has an unusual idea of what a $spoolfile is. Cheers, David.
Re: Mutt can not delete mails
On Thu, Oct 28, 2021 at 04:16:58PM +0200, Hans wrote: > Am Donnerstag, 28. Oktober 2021, 15:38:34 CEST schrieb Greg Wooledge: > Hi Greg, > > of course I can. This is step-by-step what I do: > > Starting mutt from the commandline as normal user. Mutt in ncurses appears. > Now I want to mark and delete all mails. I press Shift+D, then it asks the > for > the sample and I press . (dot) and * (asterix). > > By pressing the "Enter" key all mails are marked ND+. > > Now pressing "q" (for quit) and it asks me "20 as deletion marked mails > delete? ([yes]/no):" (Note, I have a German environment, so it asks me in > German. This sentence a translated by me). > > I answer yes, and it appears "temporary file could not be created". > > Pressing again "q" and now answer "no", mutt closes. > > Does this help? OK... that's not what I asked for, but let's see if I can reproduce it. I created an account named "tester", and installed procmail, and gave tester a ~/.qmail file containing "|preline procmail" to force delivery to /var/mail. Then I sent a message to it: unicorn:~$ echo test | mailx -s testing tester and verified delivery: tester@unicorn:~$ ls -la /var/mail total 12 drwxrwsr-x 2 root mail 4096 Oct 28 10:25 . drwxr-xr-x 13 root root 4096 Mar 3 2018 .. -rw-rw 1 tester mail 455 Oct 28 10:25 tester Then fired up mutt as tester: tester@unicorn:~$ export MAIL=/var/mail/tester tester@unicorn:~$ mutt I pressed D . * Enter q y Mutt exited cleanly, and wrote: 0 kept, 1 deleted. And now the mailbox is empty: tester@unicorn:~$ ls -la /var/mail total 8 drwxrwsr-x 2 root mail 4096 Oct 28 10:28 . drwxr-xr-x 13 root root 4096 Mar 3 2018 .. -rw-rw 1 tester mail0 Oct 28 10:25 tester This is all acting as I expect. Is there, perhaps, something in your .muttrc which is changing mutt's behavior? You could try repeating your test with the .muttrc file temporarily renamed, and see if you get the same result. I'm wondering, in particular, if there is some setting in mutt that tells it to attempt to delete the inbox file if it reaches 0 messages, and that perhaps you've enabled it. If so, you'll want to disable it. P.S. my system details: Debian 11 amd64 Linux unicorn 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux package mutt version 2.0.5-4.1 Locally installed (non-Debian) qmail (shouldn't matter here)
Re: Mutt can not delete mails
On Thu 28 Oct 2021 at 16:16:58 (+0200), Hans wrote: > Am Donnerstag, 28. Oktober 2021, 15:38:34 CEST schrieb Greg Wooledge: > [ … ] This is step-by-step what I do: > > Starting mutt from the commandline as normal user. Mutt in ncurses appears. > Now I want to mark and delete all mails. I press Shift+D, then it asks the > for > the sample and I press . (dot) and * (asterix). > > By pressing the "Enter" key all mails are marked ND+. > > Now pressing "q" (for quit) and it asks me "20 as deletion marked mails > delete? ([yes]/no):" (Note, I have a German environment, so it asks me in > German. This sentence a translated by me). > > I answer yes, and it appears "temporary file could not be created". > > Pressing again "q" and now answer "no", mutt closes. > > Does this help? Two possibilities spring to mind: 3.349. trash Type: path Default: (empty) If set, this variable specifies the path of the trash folder where the mails marked for deletion will be moved, instead of being irremediably purged. NOTE: When you delete a message in the trash folder, it is really deleted, so that you have a way to clean the trash. You've specified the trash in a place you can't write to, and, a little less likely: 3.56. delete Type: quadoption Default: ask-yes Controls whether or not messages are really deleted when closing or synchronizing a mailbox. If set to yes, messages marked for deleting will automatically be purged without prompting. If set to no, messages marked for deletion will be kept in the mailbox. Cheers, David.
Re: Mutt can not delete mails
Am Donnerstag, 28. Oktober 2021, 15:38:34 CEST schrieb Greg Wooledge: Hi Greg, of course I can. This is step-by-step what I do: Starting mutt from the commandline as normal user. Mutt in ncurses appears. Now I want to mark and delete all mails. I press Shift+D, then it asks the for the sample and I press . (dot) and * (asterix). By pressing the "Enter" key all mails are marked ND+. Now pressing "q" (for quit) and it asks me "20 as deletion marked mails delete? ([yes]/no):" (Note, I have a German environment, so it asks me in German. This sentence a translated by me). I answer yes, and it appears "temporary file could not be created". Pressing again "q" and now answer "no", mutt closes. Does this help? Best regards Hans > On Thu, Oct 28, 2021 at 03:21:47PM +0200, Hans wrote: > > Hi folks, > > > > I got into an issue with mutt. Problem is, mutt can not delete mails and I > > myself can not delete the file below /var/mail/. > > You are not *supposed* to delete your entire inbox file. You're only > supposed to modify it, potentially reducing the size of it to 0 bytes. > > That said, I've been using $HOME/Maildir/ for decades, so I don't know > how Debian currently manages the /var/mail/* mbox files that it defaults > to. /usr/bin/mutt_dotlock is setgid mail on my system, the same as > on yours. /var/mail is writable by group mail (same as yours), so that > appears to be OK. > > Can you give us more details? E.g. describe how you delete a single > message from your inbox in mutt, and exactly what mutt does when you > try it.
[debian-user][packaging] Missing OVN packages in Debian 11
Hi, I'm upgrading a few clusters from older versions of Debian to bullseye and I just noticed there are no OVN packages available. >From the packages list[1] I can see all the openvswitch packages, but I'm not able to find ovn-common, ovn-host, ovn-central, but they appear in buster[2]. Is there anything missing? [1]: https://packages.debian.org/stable/net/ [2]: https://packages.debian.org/buster/ovn-central Thanks, Carlos.
Re: Mutt can not delete mails
On Thu, Oct 28, 2021 at 03:21:47PM +0200, Hans wrote: > Hi folks, > > I got into an issue with mutt. Problem is, mutt can not delete mails and I > myself can not delete > the file below /var/mail/. You are not *supposed* to delete your entire inbox file. You're only supposed to modify it, potentially reducing the size of it to 0 bytes. That said, I've been using $HOME/Maildir/ for decades, so I don't know how Debian currently manages the /var/mail/* mbox files that it defaults to. /usr/bin/mutt_dotlock is setgid mail on my system, the same as on yours. /var/mail is writable by group mail (same as yours), so that appears to be OK. Can you give us more details? E.g. describe how you delete a single message from your inbox in mutt, and exactly what mutt does when you try it.
Mutt can not delete mails
Hi folks, I got into an issue with mutt. Problem is, mutt can not delete mails and I myself can not delete the file below /var/mail/. So I believe, this might be a settings problem, however on my other 32-bit-system it is working. Only on my 64-bit systems it is not working. These are the settings: ls -la /usr/bin/ | grep mutt -rwxr-xr-x 1 root root 1169552 6. Jun 21:11 mutt -rwxr-sr-x 1 root mail 14496 6. Jun 21:11 mutt_dotlock ls -la /var/mail/ insgesamt 2052 drwxrwsr-x 2 root mail4096 28. Okt 15:12 *.* drwxr-xr-x 13 root root4096 2. Sep 18:37 *..* -rw-rw 1 myusername mail 2090109 28. Okt 15:02 myusername ls -la /var/mail/ullhan63 -rw-rw 1 myusername mail 2090109 28. Okt 15:02 /var/mail/ullhan63 groups myusername lp uucp dialout fax cdrom floppy audio dip video plugdev games users powerdev debian-tor netdev scanner wireshark chipcard kismet cyberjack So, what is wrong? Or is this a bug in mutt itself? Mutt always mournes, that it can not create a temporary file, but I can not figure out, which or where this temporary file is going to be created. Any hints are welcome. Thanks for reading this. Best regards Hans
Re: question from total newbie. a little help please
On Fri, Oct 29, 2021 at 12:30:37AM +1300, Richard Hector wrote: > On 18/10/21 2:55 am, john doe wrote: > > With W10 you have also the possibility of using 'WLS' an order > > alternative would be to install Debian as a VM. > > I think perhaps you mean WSL - Windows Subsystem for Linux? > > https://docs.microsoft.com/en-us/windows/wsl/install > > I've never used it myself. > > Richard > WSL2 - effectively a layer that sits on Hyper-V shim and can talk to Windows subsystems. Allows you to run Debian as a VM, effectively. Debian WSL2 bundle is maintained by a Debian developer. Andy C.
Re: question from total newbie. a little help please
On 18/10/21 2:55 am, john doe wrote: With W10 you have also the possibility of using 'WLS' an order alternative would be to install Debian as a VM. I think perhaps you mean WSL - Windows Subsystem for Linux? https://docs.microsoft.com/en-us/windows/wsl/install I've never used it myself. Richard
Re: [Sid] Firefox problem
On 17/10/21 9:55 pm, Grzesiek wrote: Hi there, On some of machines I use, after opening of Firefox I get empty browser window (with menus, decorations etc) but nothing else is displayed. Its impossible to open menu, type address, etc. The only thing you can do is to close the window. After changing display configuration (rotate to portrait, adding external monitor..) it starts to work as expected. You do not even need to reopen. Moreover, it looks that Firefox was running ok all the time but nothing was displayed. After recent updates on some machines I get the same problem using firefox-esr. The only error mesg I get is: ###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost Are you seeing that message in the shell that you started it from? If not, and if you're not running it in a shell, try that to see if there are more messages? Cheers, Richard
Re: replacement of sqsh for debian 11
On 28/10/21 3:05 pm, Greg Wooledge wrote: Nobody could figure out that you were trying to connect to an existing proprietary database. Well, I did. Because that's what sqsh is for - it's a client, not a DBMS. But I guess it could have been clearer. Cheers, Richard
