Pingviini veeb

Tere!
Leidsin, et veebiserveri access_log fail on juba üle kuu aja tühi. Kahtlustasin, et ehk on mõne paranduse pealelaskmisega seaded muutunud, aga ükski seadefail ei olnud sellal ega hiljuti enne seda kuupäeva muutunud. Lõpuks taipasin vaadata service status-t:

# service apache2 status
[..]
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Niisugune isetegevus käib siis OS-is,
openSUSE-15.1,
init-skriptide kaustad on tühjad, OS-i majandab systemd.

Kas saab kuidagi niisuguseid üllatusi vältida?

Logifail on ära roteeritud, aga apachele unustati sellest rääkida, seega ta kirjutab vana file handle pihta edasi ja sealt tõenäoliselt /dev/nulli

Viisakad apache pakid on teenuse logide roteerimise konffinud nii, et roteerimise hetkel tehakse apachele reload - siis too teab uue logifaili tekitada. Kui Suse-s logrotate veel kasutusel, siis /etc/logrotate.d/apache võiks sisaldada midagi umbes sellist:
Kui logisid roteerib systemd-journald, siis ma ei viitsi hetkel uurida, kuidas see käib.

> Logifail on ära roteeritud, aga apachele unustati sellest rääkida, seega ta kirjutab vana file handle pihta edasi ja sealt tõenäoliselt /dev/nulli

Eelmistel roteerimistel on logimist jätkatud, ainult 5. mail loodud access_log oli tühi:
208332 Feb 6 23:51 access_log-20200207.xz
218972 Mar 23 23:58 access_log-20200324.xz
222180 May 4 23:59 access_log-20200505.xz

> /etc/logrotate.d/apache võiks sisaldada midagi umbes sellist:
> /apache/*log {
> ...
> lastaction
> /bin/apache reload
> endscript
> }

/etc/logrotate.d/apache2-s on:
/var/log/apache2/access_log /var/log/apache2/ssl_request_log {
...
postrotate
systemctl reload apache2.service
sleep 60
endscript
}

See fail on 25.02 kuupäevaga, nii et vähemalt korra on pärast roteerimist logimine jätkunud, aga 5. mail millegipärast nii ei juhtunud.

Kui tegin ise käsitsi:

# service apache2 restart

siis hakkas logima.
Kas peaksin seal skriptis 'systemctl reload ..' välja vahetama?
Pärast järjekordsete paranduste pealelaskmist tekib see ilmselt jälle sinna.

Kõik tundub olevat nii, nagu peab. Siis mul hetkel head nõu pole anda. Kui kuu vanused syslogid veel alles, uuri seda roteerimise hetkel, ehk on midagi huvitavat sealt paista.

DaStoned kirjutas:Kui kuu vanused syslogid veel alles, uuri seda roteerimise hetkel, ehk on midagi huvitavat sealt paista.

See probleem kestab ja kestab. Peale logrotate-i jääb access_log tühjaks.

% ls -l
-rw-r--r-- 1 root root 0 Mar 30 00:00 access_log

error_log failis pole sel kellaajal ühtegi teadet:

[Sun Mar 28 23:48:02.441101 2021] [core:crit] [pid 30333] (13)Permission denied: [client 94.130.9.166:53814] ...
[Mon Mar 29 00:44:58.058353 2021] [php7:error] [pid 30339] [client 121.43.136.173:52032] ...

service apache2 status näitas viga, aga mu xtermi aken oli väike, nii jäi pool veateadet ääre taha:

% service apache2 status
Mar 30 00:00:04 scorpion systemd[1]: Reloading The Apache Webserver.
Mar 30 00:00:04 scorpion systemd[22355]: apache2.service: Failed to set up mount namespacing: /run/systemd/unit-root/tmp: No >
Mar 30 00:00:04 scorpion systemd[22355]: apache2.service: Failed at step NAMESPACE spawning /usr/sbin/start_apache2: No such >
Mar 30 00:00:04 scorpion systemd[1]: apache2.service: Control process exited, code=exited status=226
Mar 30 00:00:04 scorpion systemd[1]: Reload failed for The Apache Webserver.
...skipping...

Uuesti käsitsi service apache2 restart tehes hakkab logima.

Eelinfoks:
Vaata faili /usr/lib/systemd/system/apache2.service
Seal on PrivateTmp=true option kirjas.

Kui sul hetkel apache käib, siis peaksid /tmp/ alla nägema mingit sellist katalooma: systemd-private-66b86c5c159b43ca81bfdc2ad37934a9-apache2.service-GBxktq
Taoline tekib siis kui teenusele öösel viisakalt reload tehakse.
Kustuta see /tmp/systemd-private-66b86c5c159b43ca81bfdc2ad37934a9-apache2.service-GBxktq
Tee viisakalt reload: systemctl reload apache2.service
Sa näed samasuguseid veateateid nagu oma postituses.
Kui aga teed service apache2 restart, siis selliseid veateateid sa ei saa.

Kui tahad, et asi tööle jääks ja logid roteeruks automaagiliselt, siis eelinfos toodud failis muuda PrivateTmp=true PrivateTmp=false vastu
Reloadi: systemctl daemon-reload
Tee viisakalt reload: systemctl reload apache2.service
Enam ei tohiks neid veateateid tulla

Sul mingit automaatikat pole mis /tmp sisu X aja tagant ära kustutab?

> Eelinfoks:
> Vaata faili /usr/lib/systemd/system/apache2.service
> Seal on PrivateTmp=true option kirjas.

On jah.


> Kui sul hetkel apache käib, siis peaksid /tmp/ alla nägema mingit sellist katalooma:
> systemd-private-66b86c5c159b43ca81bfdc2ad37934a9-apache2.service-GBxktq
> Taoline tekib siis kui teenusele öösel viisakalt reload tehakse.
> Kustuta see /tmp/systemd-private-...
> Tee viisakalt reload: systemctl reload apache2.service.

Tegin nii:
# systemctl reload apache2.service
Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details.

> Sa näed samasuguseid veateateid nagu oma postituses.

On jah.

> Kui aga teed service apache2 restart, siis selliseid veateateid sa ei saa.
> Kui tahad, et asi tööle jääks ja logid roteeruks automaagiliselt, siis eelinfos toodud failis
> muuda PrivateTmp=true PrivateTmp=false vastu

Kui nüüd kustutasin uuesti /tmp/-is systemd-private... kausta, siis
# systemctl reload apache2.service lõpetas ikka veaga.
Startisin apache uuesti 'service apache2 restart'-ga ja tegin:

> Reloadi: systemctl daemon-reload
> Tee viisakalt reload: systemctl reload apache2.service
> Enam ei tohiks neid veateateid tulla

Ehk jääb nüüd tööle. Tänan!


> Sul mingit automaatikat pole mis /tmp sisu X aja tagant ära kustutab?

On ikka. /tmp/-is on hetkel kõige vanemad failid 14.03.2021.
Neist varasemad on ära koristatud. up-time on 29 päeva, siis panin peale tuuma parandused.
Veel vanematest on alles ainult mingi 0-suurusega ühe kasutaja srwxrwx--- fail OSL_PIPE_...,
üks mc-kasutaja kaust - ta kasutab Midnight commanderit,
ning OS installeerimise ajast neli .???-unix kausta.