Skip to content


Apache 2.4 doesn't start with AH00023: Couldn't create the rewrite-map mutex

Problem: Apache 2.4.6 doesn't start on CentOS 7. error.log shows this confusing error message:

[Mon Mar 16 08:55:03.254104 2026] [core:emerg] [pid 3946] (28)No space left on device: AH00023: Couldn't create the rewrite-map mutex
[Mon Mar 16 08:55:03.254178 2026] [:emerg] [pid 3946] AH00020: Configuration Failed, exiting

We don't have problems with free space on storage device, so this message looks really weird:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        895M     0  895M   0% /dev
tmpfs           920M  105M  815M  12% /run
tmpfs           920M     0  920M   0% /sys/fs/cgroup
/dev/sda1        50G   14G   36G  28% /
 
# df -i
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
devtmpfs         228953    296   228657    1% /dev
tmpfs            235265    521   234744    1% /run
tmpfs            235265     16   235249    1% /sys/fs/cgroup
/dev/sda1      14305488 480611 13824877    4% /
# cat /proc/sys/kernel/sem
250     32000   32      128

Solution:

# sysctl -w kernel.sem="250 32000 100 256"
kernel.sem = 250 32000 100 256

After that change apache starts normally without complains.

Also some of this apache config-file changes might help:

Mutex fcntl:/var/run/httpd default

or

Mutex flock:/var/run/httpd default

I haven't tested it yet.

Posted in *nix, Howto.

Tagged with .


How to fix DNS resolving problem in libvirt guest

Situation: dnsmasq is running on host machine and listens on 192.168.122.1:53 (both TCP and UDP), but resolving in guest machine doesn't work. When dig command shows "status: REFUSED" while querying 192.168.122.1 from inside VM like this

# dig srv.myex.zone @192.168.122.1
 
; <<>> DiG 9.16.23-RH <<>> srv.myex.zone @192.168.122.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49818
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;srv.myex.zone.                 IN      A
 
;; Query time: 0 msec
;; SERVER: 192.168.122.1#53(192.168.122.1)
;; WHEN: Wed Jun 11 10:27:42 CDT 2025
;; MSG SIZE  rcvd: 42

we should check /var/lib/libvirt/dnsmasq/default.conf config-file. Most probably, it has no-resolv directive in it:

##WARNING:  THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
##OVERWRITTEN AND LOST.  Changes to this configuration should be made using:
##    virsh net-edit default
## or other application using the libvirt API.
##
## dnsmasq conf file created by libvirt
strict-order
no-resolv
pid-file=/run/libvirt/network/default.pid
except-interface=lo
bind-dynamic
interface=virbr0
dhcp-range=192.168.122.2,192.168.122.254,255.255.255.0
dhcp-no-override
dhcp-authoritative
dhcp-lease-max=253
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile
addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts

And if it really there, that's the cause of our problem. With no-resolv enabled, it won’t forward the query to upstream DNS servers, resulting in a REFUSED response because it has no answer and is not allowed to query upstream. As comments above state, we can't just edit the file, because our changes will be lost soon (after reboot, for example). The proper way to fix this is:

  1. virsh net-edit default
    add inside <network> tag this lines:

      <dns>
        <forwarder addr='1.1.1.1'/>
        <forwarder addr='8.8.4.4'/>
      </dns>
  2. virsh net-destroy default
  3. virsh net-start default

After this file /var/lib/libvirt/dnsmasq/default.conf will contain new lines

server=1.1.1.1
server=8.8.4.4

and no-resolv will not have any effect anymore.

Posted in *nix.

Tagged with , .


Проблеми ерозії берегів — причини, наслідки та рішення

681a24b2a8009.webpЕрозія берегів — це повільний, але незворотний процес руйнування берегової лінії під впливом води, вітру, снігу, хвиль і діяльності людини. Вона загрожує як природним ландшафтам, так і інфраструктурі, приватним ділянкам, сільськогосподарським угіддям. Особливо небезпечна ерозія на крутих берегах річок, озер і водосховищ, де втрата ґрунту може призвести до зсувів, затоплення, руйнування будівель і доріг.

Щоб запобігти або зупинити ці процеси, необхідно вчасно визначити причини ерозії та застосувати правильні методи берегоукріплення.

Основні причини ерозії берегів

Берегова ерозія може бути спричинена як природними факторами, так і втручанням людини. Найпоширеніші причини:

  • Постійний вплив хвиль, течії або припливів, які вимивають ґрунт
  • Танення снігу, дощі, підвищення рівня ґрунтових вод
  • Вирубка дерев і знищення рослинності, яка утримувала ґрунт
  • Неконтрольована забудова прибережної зони
  • Витоптування схилів людьми або тваринами
  • Розмивання підніжжя берегів без укріплення

Чим більше факторів діє одночасно — тим швидше руйнується берег і важче його відновити.

Які небезпеки несе ерозія

  • Втрата площі земельної ділянки
  • Руйнування дорожніх під’їздів, комунікацій і будівель
  • Зсуви на схилах
  • Заміулення водойм і зміна русла річки
  • Зниження екологічної цінності ділянки
  • Ускладнення для подальшого благоустрою

У деяких випадках ерозія призводить до щорічної втрати 0,5–1 метра берега. Якщо не втрутитися — наслідки можуть бути катастрофічними для ділянки та всього прибережного ландшафту.

Як вирішити проблему ерозії

Для кожної ситуації потрібне індивідуальне рішення, але загальні методи боротьби з ерозією поділяються на природні, інженерні та комбіновані.

1. Використання георешіток
Тривимірна полімерна георешітка (геоячейка) укладається на схил і заповнюється щебенем або ґрунтом. Вона утримує поверхню від сповзання, дозволяє висаджувати траву, знижує швидкість стікання води.

2. Геотекстиль і дренажні мати
Захищають схил від вимивання, фільтрують воду, запобігають змішуванню шарів ґрунту. Геотекстиль особливо ефективний під георешіткою або під декоративним камінням.

3. Озеленення берегової лінії
Посів трав, висадка чагарників, а в деяких випадках і дерев створює природний захист. Коренева система додатково скріплює ґрунт і уповільнює потоки води.

4. Габіони та кам’яні підпірні стінки
Металеві сітчасті конструкції, заповнені камінням, слугують потужною перешкодою для хвиль і не дозволяють воді розмивати берег знизу. Підходять для крутих і високих берегів.

5. Укладання натурального каменю або плитняку
Це декоративний, але ефективний спосіб захисту від ерозії на невеликих ділянках. Камінь зменшує швидкість води та захищає верхній шар ґрунту.

6. Створення водовідвідних каналів і лотків
Вони потрібні для того, щоб дощова і тала вода не стікала прямо по схилу. Правильна система дренажу захищає навіть круті береги.

Яке укріплення обрати: поради

  • Для пологих берегів річок — достатньо георешітки з ґрунтовим заповненням і травою
  • Для схилів понад 30° — поєднання георешітки, геотекстилю і габіонів
  • Якщо берег постійно підмивається водою — потрібна кам’яна або бетонна підпора
  • Для декоративного благоустрою — газонна решітка і ущільнений шар дерну
  • Якщо є підтоплення — обов’язково проектується дренаж

Найбільш надійні результати дає комбінований підхід: поєднання геосинтетичних матеріалів і природних методів стабілізації.

Зупинити ерозію можливо — важливо діяти на ранньому етапі. Своєчасне укріплення берега дозволяє зберегти ділянку, підвищити її цінність і зробити її безпечною для користування.

Posted in Misc.


fetchmail version 6.4.39 stopped working with Gmail

One day I had fetchmail version 6.4.39 stopped working with Gmail saying in log:

fetchmail: Authorization failure on [email protected]
fetchmail: For help, see http://www.fetchmail.info/fetchmail-FAQ.html#R15
fetchmail: Query status=3 (AUTHFAIL)

That FAQ page wasn't very useful - no thoughts for me to dig further.

In the ~/.fetchmailrc config file I had this string, which was working fine for many years:

poll pop.gmail.com protocol pop3 username '[email protected]' password 'VerySecurePsw0rt' ssl

At the same time I was still able to login successfully to my google account in browser using that credentials from ~/.fetchmailrc. That was pretty wierd, considering I didn't change anything in configs and in my google account. Also, I have double-checked Gmail settings and confirmed that still have "Status: POP is enabled" there.

After some research I found very nice detailed article which says:

App passwords.

It seems like there’s a possibility to generate a 16-digit password, which is specific to an app. So at least in theory, this app password could be given to Fetchmail in order to perform a regular login.

So, I decided to try it considering pretty "low price" for such feature - I just had to enable 2FA for my Google account.

After 2FA has been activated I was able to see the new functionality named "App passwords", which is available under URL https://myaccount.google.com/apppasswords There I created a new password exclusively for fetchmail and pasted it to the ~/.fetchmailrc config instead of main google account password that was there before. And miracle happened! Fetchmail started to fetch my mail from gmail servers as before.

Posted in *nix.

Tagged with , .