Hi,
Max Nikulin wrote:
> > > A bit off-topic question. In what wiki page you would expect to find
> > > suggestions to inspect ~/.xsession-errors file and journalctl output?
I wrote:
> > I pasted ".xsession-errors" into the "Search:" field at the upper right
> > corner of any Debian wiki page and
On 23/07/2024 19:20, Thomas Schmitt wrote:
A bit off-topic question. In what wiki page you would expect to find
suggestions to inspect ~/.xsession-errors file and journalctl output?
I pasted ".xsession-errors" into the "Search:" field at the upper right
corner of any Debian wiki page and clicke
On Tue, Jul 23, 2024 at 14:20:43 +0200, Thomas Schmitt wrote:
> The only helpful match is
>
>
> https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value=.xsession-errors&fullsearch=Text
>
> "What Does The Log Say?
>...
>If you're doing something with your window manage
Hi,
Max Nikulin wrote:
> A bit off-topic question. In what wiki page you would expect to find
> suggestions to inspect ~/.xsession-errors file and journalctl output?
I pasted ".xsession-errors" into the "Search:" field at the upper right
corner of any Debian wiki page and clicked the "Text" butto
On 19 May 2024 11:11 -0400, from monn...@iro.umontreal.ca (Stefan Monnier):
>> If you have read permission on a directory but *not* execute permissions,
>> then the only thing you can do is read the contents of that directory --
>> the filenames and their inode numbers. You cannot stat() the files
On Sun, May 19, 2024 at 05:15:40PM +0200, Richard wrote:
> Then where does the combination rwx come in here? With read the app knows
> the file is there, with write it writes to the file. Question is, where the
> necessity would be to know the owner of the file or even the kind. The
> logger is sup
hrieb Greg Wooledge :
> On Sun, May 19, 2024 at 04:55:09PM +0200, Richard wrote:
> > Dovecot expects execution permissions on the directory it writes the logs
> > to. Because "Standard POSIX permissions for a non-root process to enter a
> > directory." How on earth
> If you have read permission on a directory but *not* execute permissions,
> then the only thing you can do is read the contents of that directory --
> the filenames and their inode numbers. You cannot stat() the files,
> so you can't see who owns them or even what kind of files they are.
> Just
On Sun, May 19, 2024 at 04:55:09PM +0200, Richard wrote:
> Dovecot expects execution permissions on the directory it writes the logs
> to. Because "Standard POSIX permissions for a non-root process to enter a
> directory." How on earth is that even a thing?
That's how Unix
So, I've just written to the Dovecot mailing list, the reality why Dovecot
is complaining is so much worse than anything I could have imagined. While
everything indicates Dovecot is able to write to the log files, it seems
Dovecot expects execution permissions on the directory it writes the
>
> Don't call me a liar, you are just too dumb to understand.
It's sad to see that you need to make it this blatantly obvious that even I
clearly understand more than you do. And you're the one trying to scold me
about sticking to the mailing list rules when you so obviously don't care
for them y
On Fri, May 17, 2024 at 08:20:17AM -0400, Henning Follmann wrote:
> No the point is, you are not setting a file path, you are configure dovecot
> to directly write to these files.
> And dovecot is not just one process, there are multiple running as
> different users all trying t write into one file
#x27;t call me a liar, you are just too dumb to understand.
>
> > Configure the literal industry standard syslog or journald to use a facility
> to your liking and the problem should resolve itself.
> The point is, Dovecot has an option to write certain types of logs to
> differ
nd the problem should resolve itself.
The point is, Dovecot has an option to write certain types of logs to
different files. While it's doing that great, postfix is upset about that
capability. It shouldn't even try to access these files. So the issue is
not being able to log to files, tha
On Thu, May 16, 2024 at 01:00:19PM +0200, Richard wrote:
> But why is postfix even holding a lock on it? And how do I prevent that? I
> never asked it to.
> At least, I don't think there should be a different process holding a lock
> on it.
>
I told you where to look, which is more than you deser
But why is postfix even holding a lock on it? And how do I prevent that? I
never asked it to.
At least, I don't think there should be a different process holding a lock
on it.
Am Mi., 15. Mai 2024 um 18:45 Uhr schrieb Henning Follmann <
hfollm...@itcfollmann.com>:
> On Wed, May 15, 2024 at 12:23:
On Wed, May 15, 2024 at 12:23:35PM +0200, Richard wrote:
>
[...]
> But that's still not that helpful for the main issue. Why on earth is
> postfix throwing issues about the log files, even when they are
> world-readable and -writable? It's not that dovecot doesn't log to them,
> but it's also not
On 15/5/24 18:52, Richard wrote:
mailbox_transport isn't defined anywhere.
Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley
:
On 15/5/24 18:23, Richard wrote:
> Interesting. That's not even configured in our main.cfg. We have
these
> concerning dovecot:
> smtpd_
mailbox_transport isn't defined anywhere.
Am Mi., 15. Mai 2024 um 12:37 Uhr schrieb jeremy ardley <
jeremy.ard...@gmail.com>:
>
> On 15/5/24 18:23, Richard wrote:
> > Interesting. That's not even configured in our main.cfg. We have these
> > concerning dovecot:
> > smtpd_sasl_type = dovecot
> >
On 15/5/24 18:23, Richard wrote:
Interesting. That's not even configured in our main.cfg. We have these
concerning dovecot:
smtpd_sasl_type = dovecot
mailbox_command = /usr/lib/dovecot/deliver -d $USER
The sasl line is not relevant
The mailbox_command is unusual. It means whatever process a
Interesting. That's not even configured in our main.cfg. We have these
concerning dovecot:
smtpd_sasl_type = dovecot
mailbox_command = /usr/lib/dovecot/deliver -d $USER
But that's still not that helpful for the main issue. Why on earth is
postfix throwing issues about the log files, even when they
On 14/5/24 20:17, to...@tuxteam.de wrote:
On Tue, May 14, 2024 at 02:11:53PM +0200, Richard wrote:
[...]
Setting the permissions in /var/log/dovecot to 666 actually didn't
solve the problem [...]
This seems to prove (or, at least, strongly suggest) that I was barking
up the wrong tree. I've
Says the one refusing to stay on topic. What a sad hypocrite.
On Tue, May 14, 2024, 20:10 Henning Follmann
wrote:
> On Tue, May 14, 2024 at 03:11:16PM +0200, Richard wrote:
> > "Top posting" (writing the answer above the text that's being replied to)
> > is literally industry standard behavior.
How exactly do I do that?
Am Di., 14. Mai 2024 um 18:40 Uhr schrieb jeremy ardley <
jeremy.ard...@gmail.com>:
>
> From what I can find out, the postfix local delivery agent is not
> chroot and it communicates with the main postfix processes via shared
> directories and pipes.
>
> To debug the pr
Alain D D Williams (12024-05-14):
> PS: check the dictionary definition of "literally".
I think you should have checked first that it makes the point you want
to make and not the opposite:
2. (degree, figuratively, proscribed, contranym) Used non-literally as
an intensifier for figurative stat
On Tue, May 14, 2024 at 03:11:16PM +0200, Richard wrote:
>"Top posting" (writing the answer above the text that's being replied
>to) is literally industry standard behavior.
Many do top post, but many do not.
Places where it is often frowned on are technical mail lists such as this one.
T
On Tue, May 14, 2024 at 04:08:19PM +0200, Richard wrote:
> Just because something isn't an official ISO standard doesn't mean it's not
> standard behavior. And how it relates to this mailing list? It's called a
> setting.
Most people prefer inline quoting around here (I know I do). That's
because
Just because something isn't an official ISO standard doesn't mean it's not
standard behavior. And how it relates to this mailing list? It's called a
setting.
Am Di., 14. Mai 2024 um 15:57 Uhr schrieb Loris Bennett <
loris.benn...@fu-berlin.de>:
> Hi Richard,
>
> Richard writes:
>
> > "Top posti
Hi Richard,
Richard writes:
> "Top posting" (writing the answer above the text that's being replied
> to) is literally industry standard behavior.
Can you provide a link to the standard you are referring to?
Assuming such a standard exists, how would it apply to this newsgroup?
[snip (51 line
On Tue, May 14, 2024 at 03:11:16PM +0200, Richard wrote:
> "Top posting" (writing the answer above the text that's being replied to)
> is literally industry standard behavior.
>
Whatever.
It is not standard behavior in mailing lists.
https://wiki.debian.org/DebianMailingLists#Posting_Rules.2C_Guid
And you think you're important enough to change that setting for a whole
mailing account? You're funny.
Am Di., 14. Mai 2024 um 15:16 Uhr schrieb Brad Rogers :
> On Tue, 14 May 2024 15:11:16 +0200
> Richard wrote:
>
> Hello Richard,
>
> >"Top posting" (writing the answer above the text that's be
On Tue, 14 May 2024 15:11:16 +0200
Richard wrote:
Hello Richard,
>"Top posting" (writing the answer above the text that's being replied
>to) is literally industry standard behavior.
This 'literally' isn't industry.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ )
"Top posting" (writing the answer above the text that's being replied to)
is literally industry standard behavior.
Also, I don't think you've really cleared out any confusion. Now, how
exactly can dovecot log to /var/log/dovecot/ without (postfix) throwing
errors? Because it clearly is for 2 out o
On Tue, May 14, 2024 at 02:11:53PM +0200, Richard wrote:
[...]
> Setting the permissions in /var/log/dovecot to 666 actually didn't
> solve the problem [...]
This seems to prove (or, at least, strongly suggest) that I was barking
up the wrong tree. I've currently run out of trees and at $DAYJOB,
>
> ps -eo pid,user,group,comm | grep postfix
> 2886706 postfix postfix pickup
> 2886707 postfix postfix qmgr
> 2886764 postfix postfix tlsmgr
Also as far as I know, postfix logs to syslog too. At least there is no
dedicated file or folder for it in /var/log.
Setting the
Le 14/05/2024, to...@tuxteam.de a écrit:
> You might try
>
> ps -eo pid,user,group,comm | grep postfix
>
> or similar.
Yep, and beware that the original message mentions a postfix program
named 'local' (/usr/lib/postfix/sbin/local).
> May 13 20:55:37 mail postfix/local[2824184]: (...)
Regards
For us the situation is even a bit stranger. The inboxes are located in
neither location, but in /maildirs/username/ (no idea why it was set up
that way, but it's a dedicated mail server where the user's don't have
their own home directory). /var/mail is empty.
Am Di., 14. Mai 2024 um 13:45 Uhr sc
On 14/5/24 19:44, Greg Wooledge wrote:
On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote:
Postfix is chrooted (usuallly) to /var/spool/postfix
If this is true, then how would a local delivery agent work? It needs
write access to all users' inboxes, which are either in /var/mail o
On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote:
[...]
> Postfix is chrooted (usuallly) to /var/spool/postfix
>
> If postfix complains about /var/log/dovecot it's actually complaining about
> /var/spool/postfix/var/log/dovecot
I'm sceptical about this -- the error would have been
On Tue, May 14, 2024 at 01:29:17PM +0200, Richard wrote:
> My guess is that postfix runs as postfix.
That would be my guess too (or perhaps as some special "Debian-+postfix".
> At least processes like local,
> smtpd, bounce etc run as that user. But beyond that I have no idea how to
> find that o
On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote:
> Postfix is chrooted (usuallly) to /var/spool/postfix
If this is true, then how would a local delivery agent work? It needs
write access to all users' inboxes, which are either in /var/mail or in
users' home directories.
I could ima
On 14/5/24 19:17, Richard wrote:
But why should it cause issues? I set the logging in dovecot's conf.d,
so I'd expect dovecot to write these logs, not postfix as it has its
own settings.
Am Di., 14. Mai 2024 um 05:00 Uhr schrieb jeremy ardley
:
On 14/5/24 04:16, Ric
My guess is that postfix runs as postfix. At least processes like local,
smtpd, bounce etc run as that user. But beyond that I have no idea how to
find that out. At least there's nothing in the postfix.service or
postfix@.service
about that. So I've changed the files to dovecot:postfix 664, but sam
AppArmor complaints would be shown in journalctl too. But dmseg doesn't
show anything either. Just switched dovecot back to these log files, waited
for the error message, yet dmesg doesn't have anything new since yesterday.
Systemd was also my guess as it was originally set to ProtectSystem=full
fo
But why should it cause issues? I set the logging in dovecot's conf.d, so
I'd expect dovecot to write these logs, not postfix as it has its own
settings.
Am Di., 14. Mai 2024 um 05:00 Uhr schrieb jeremy ardley <
jeremy.ard...@gmail.com>:
>
> On 14/5/24 04:16, Richard wr
On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> Maybe someone here knows how the ownership of these files for Dovecot needs
> to be in order to work, as various distributions of Dovecot packages seem
> to use different users:
> I'd like Dovecot not to log into syslog, but to dedicated fi
On 14/5/24 04:16, Richard wrote:
Maybe someone here knows how the ownership of these files for Dovecot
needs to be in order to work, as various distributions of Dovecot
packages seem to use different users:
I'd like Dovecot not to log into syslog, but to dedicated files.
Therefore I've create
On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> Maybe someone here knows how the ownership of these files for Dovecot needs
> to be in order to work, as various distributions of Dovecot packages seem
> to use different users:
> I'd like Dovecot not to log into syslog, but to dedicated fi
On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=,
> > relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred
> > (temporary failure. Command output: lda(user): Error:
> > net_connect_unix(/run/dovecot/stats-w
Maybe someone here knows how the ownership of these files for Dovecot needs
to be in order to work, as various distributions of Dovecot packages seem
to use different users:
I'd like Dovecot not to log into syslog, but to dedicated files. Therefore
I've created the directory /var/log/dovecot and to
ation
> to have selective copy of the journal in an alternative directory
Hi.
You know what? I think it is exactly the right answer.
I think the principle for this thing is: journald maintains the current
logs in a best-effort manner, but when it comes to archival, the needs
and manners are t
Max Nikulin writes:
> On 24/02/2024 21:09, Byunghee HWANG wrote:
>>> When I read the question I decided that syslog for auth facility is a
>>> kind of solution.
>> Really i would like to learn more. Can you show a more specific
>> example?
>> Also i'm using Debian (sid).
>
> Install rsyslog and l
On 24/02/2024 21:09, Byunghee HWANG wrote:
When I read the question I decided that syslog for auth facility is a
kind of solution.
Really i would like to learn more. Can you show a more specific example?
Also i'm using Debian (sid).
Install rsyslog and logrotate and read their configuration f
Hellow Max!
Max Nikulin writes:
> On 23/02/2024 17:15, Nicolas George wrote:
>> How do I tell systemd's logging system to keep authentication logs
>> for
>> one year and mail logs for one month?
>
> (...)
>
> P.S.
> When I read the question I decided tha
Dnia 2024-02-23, o godz. 15:05:52
Nicholas Geovanis napisał(a):
> On Fri, Feb 23, 2024, 2:57 PM Dan Ritter wrote:
>
> > Stefan Monnier wrote:
> > > Makes one wonder why they don't use naive append-only "plain
> > > text" logs (tho with appropriate
Dnia 2024-02-23, o godz. 12:34:34
Dan Ritter napisał(a):
> Stefan Monnier wrote:
> > Makes one wonder why they don't use naive append-only "plain text"
> > logs (tho with appropriate delimiters (maybe some kind of CSV) to
> > make searches more reliable
On Fri, Feb 23, 2024, 2:57 PM Dan Ritter wrote:
> Stefan Monnier wrote:
> > Makes one wonder why they don't use naive append-only "plain text" logs
> > (tho with appropriate delimiters (maybe some kind of CSV) to make
> > searches more reliable than with old-
Stefan Monnier wrote:
> Makes one wonder why they don't use naive append-only "plain text" logs
> (tho with appropriate delimiters (maybe some kind of CSV) to make
> searches more reliable than with old-style plain text logs)?
>
> What are the advantages of journ
thanks.
> Makes one wonder why they don't use naive append-only "plain text"
> logs (tho with appropriate delimiters (maybe some kind of CSV) to make
> searches more reliable than with old-style plain text logs)?
>
> What are the advantages of journald's represen
On 23/02/2024 17:15, Nicolas George wrote:
How do I tell systemd's logging system to keep authentication logs for
one year and mail logs for one month?
I am realizing that the following is not an answer to the asked
question. The thread is no more than useless arguing anyway.
Some
og/journal/
>
> (I've raised a bug 8 years ago about it
> https://github.com/systemd/systemd/issues/2460 )
Oh, that bug report is quite interesting, thanks.
Makes one wonder why they don't use naive append-only "plain text" logs
(tho with appropriate delimiters (mayb
Dnia 2024-02-23, o godz. 14:23:07
Nicolas George napisał(a):
> Mariusz Gronczewski (12024-02-23):
> > Like, really what kind of person gets angry when they get too much
> > details in instruction?
>
> What kind of person writes pages of angry mail when the details are
> not liked?
>
That wou
Mariusz Gronczewski (12024-02-23):
> Like, really what kind of person gets angry when they get too much
> details in instruction?
What kind of person writes pages of angry mail when the details are not
liked?
--
Nicolas George
Dnia 2024-02-23, o godz. 14:09:45
Nicolas George napisał(a):
> Greg Wooledge (12024-02-23):
> > Have you even *read* this mailing list? Most of the people who ask
> > for help here lack experience that you might consider "baby
> > sysadmin" level, and would greatly appreciate the explanations.
theoretical example of how one misbehaved
> > service could flush out the important logs of well-behaved
> > services.
>
> The selective blindness here is to look only at the bad things. The
> drawbacks mentioned exist, but they are in part there for reasons, in
> order to fix t
Greg Wooledge (12024-02-23):
> Have you even *read* this mailing list? Most of the people who ask
> for help here lack experience that you might consider "baby sysadmin"
> level, and would greatly appreciate the explanations.
It is usually quite easy to tell the difference by the phrasing and
acc
Dnia 2024-02-23, o godz. 13:48:35
Nicolas George napisał(a):
> Mariusz Gronczewski (12024-02-23):
> > So to say it short: It is horrid.
>
> Generic bashing of systemd in favor of a blind cult of the good old
> ways are not what I am looking for either, and the unbalanced tone of
> your reply m
On Fri, Feb 23, 2024 at 02:03:50PM +0100, Nicolas George wrote:
> When somebody spends one line answering the question and then pages
> “offering an alternative” by explaining things a baby sysadmin would
> already know, I deduce they are not much above the level of baby
> sysadmin themselves, and
Greg Wooledge (12024-02-23):
> What was "blind" about his anaylsis? It looked pretty well thought out
> to me. He showed actual examples of how space-inefficient it is, and
> provided a theoretical example of how one misbehaved service could
> flush out the importan
ne of your
> reply makes it look like precisely that.
What was "blind" about his anaylsis? It looked pretty well thought out
to me. He showed actual examples of how space-inefficient it is, and
provided a theoretical example of how one misbehaved service could
flush out the importan
Mariusz Gronczewski (12024-02-23):
> So to say it short: It is horrid.
Generic bashing of systemd in favor of a blind cult of the good old ways
are not what I am looking for either, and the unbalanced tone of your
reply makes it look like precisely that.
--
Nicolas George
e02e7
337M/var/log/journal/
(I've raised a bug 8 years ago about it
https://github.com/systemd/systemd/issues/2460 )
To summarize: the ~61MB of resulting text of logs takes around 337MB
on disk when saved by journald, ~80MB in sqlite (~103MB when I added
index for time and process). Use the
Mariusz Gronczewski (12024-02-23):
> That is not a feature systemd's logging have.
That is what it seems, but I would like second opinions.
> You'd have to make a
> rsyslogd rule to put it in one directory
Thanks, but my question was about systemd's
Dnia 2024-02-23, o godz. 11:15:29
Nicolas George napisał(a):
> Hi.
>
> It might be an obvious question, but I do not manage to find the
> obvious answer:
>
> How do I tell systemd's logging system to keep authentication logs for
> one year and mail logs for one month?
Hi.
It might be an obvious question, but I do not manage to find the obvious
answer:
How do I tell systemd's logging system to keep authentication logs for
one year and mail logs for one month?
Regards,
--
Nicolas George
Some years ago, I ran sid for a few years. Only recall one Xorg issue
where I needed low level deb os surgery during that time.
Is sid still similarly stable, or less so in the wayland era (for
anyone using wayland/mutter)?
A benefit of using sid is that I am using software versions (e.g mpv
and
> Can reproduce on intel free driver too. Reproduced with .gif, .webm and
> .mp4.
>
> For reference, bug reported just now:
>
> https://github.com/intel/media-driver/issues/1743
Anyone know how I can test further, or should I report this against mutter?
mpv bug closed:
https://github.com/mpv-pla
On 11/26/23, Zenaan Harkness wrote:
> On 11/22/23, Zenaan Harkness wrote:
>> On 11/22/23, Zenaan Harkness wrote:
>>> Ok, I did some more testing on this one:
>>>
>>> Does not matter if it's a gif or a video.
>>>
>>> What __does__ matter is if the gif or video is zoomed, AND make
>>> fullscreen,
On 11/22/23, Zenaan Harkness wrote:
> On 11/22/23, Zenaan Harkness wrote:
>> Ok, I did some more testing on this one:
>>
>> Does not matter if it's a gif or a video.
>>
>> What __does__ matter is if the gif or video is zoomed, AND make
>> fullscreen, e.g using
> ...
>
> Fullscreen does not matter
On 11/22/23, Zenaan Harkness wrote:
> Ok, I did some more testing on this one:
>
> Does not matter if it's a gif or a video.
>
> What __does__ matter is if the gif or video is zoomed, AND make
> fullscreen, e.g using
...
Fullscreen does not matter. the video/gif can be not full screen, and
Waylan
keeps playing and doesn't immediately exit.
When the video or gif is zoomed, then when mpv exits, e.g using "q",
then either Wayland crashes or the desktop session auto logs out.
Needless to say, this is annoying.
Found this:
[vo=gpu-next] Video hangs after seek then mpv cra
Using mpv for media - videos, music and gifs.
Running mpv to view a gif, e.g:
mpv /usr/share/cups/doc-root/images/wait.gif
- then immediately type "L" to loop (so mpv does not exit too quickly)
- then type "f" to make mpv full screen
- then type "q" to quit mpv
this causes wayland to die/
\x2dkeyring\x2dpkcs11-1959.scope - Application launched by
gnome-session-binary.
These are the message I have in my logs. I have no idea what it is about.
I would appreciate any help from you guys.
Thanks
Moe
Hello,
what release is this on?
On Buster I had also some issues with tracker mainly
launched by
gnome-session-binary.
These are the message I have in my logs. I have no idea what it is about.
I would appreciate any help from you guys.
Thanks
Moe
Hello,
what release is this on?
On Buster I had also some issues with tracker mainly due to apparmor
missing some rules. I have not
11-1959.scope - Application launched by
> > > gnome-session-binary.
> > >
> > > These are the message I have in my logs. I have no idea what it is
> > > about.
> > > I would appreciate any help from you guys.
> > >
> > > Thanks
>
message I have in my logs. I have no idea what it is about.
I would appreciate any help from you guys.
Thanks
Moe
Hello,
what release is this on?
On Buster I had also some issues with tracker mainly due to apparmor
missing some rules. I have not seen this so far on Bullseye.
-H
e\x2dkeyring\x2dpkcs11-1959.scope - Application launched by
> gnome-session-binary.
>
> These are the message I have in my logs. I have no idea what it is about.
> I would appreciate any help from you guys.
>
> Thanks
>
> Moe
Hello,
what release is this on?
On Buster I had als
systemd: Failed to start
app-gnome-gnome\x2dkeyring\x2dsecrets-1958.scope - Application launched
by gnome-session-binary.
3:23:29 PM systemd: Failed to start
app-gnome-gnome\x2dkeyring\x2dpkcs11-1959.scope - Application launched
by gnome-session-binary.
These are the message I have in my logs
Hello,
On Fri, Jun 16, 2023 at 12:38:40PM -0500, Tom Browder wrote:
> I should have mentioned in OP the logs are in a dir under my own apache
> installation dir, and they are text files. I’ll try to get “logrotate” to
> take them over.
It should happen by default.
Normally logrotate
On Thu, Jun 15, 2023 at 16:57 Andy Smith wrote:
> Hi Tom,
>
> On Thu, Jun 15, 2023 at 01:52:10PM -0500, Tom Browder wrote:
> > Maybe it's related to the rsyslog changes ?
>
> apache by default does not use a syslog for logging though, it
…
Thanks, Andy.
I should hav
Hi Tom,
On Thu, Jun 15, 2023 at 01:52:10PM -0500, Tom Browder wrote:
> Maybe it's related to the rsyslog changes ?
apache by default does not use a syslog for logging though, it
writes logfiles itself directly. On a normal Debian distribution
these are rotated by the logrotate package.
So any am
On Wed, Jun 14, 2023 at 13:18 zithro wrote:
> On 14 Jun 2023 19:30, Tom Browder wrote:
...
> I’ve been running httpd for many years, long before systemd came along.
> > Somewhere in the various upgrades over the years I lost the old rotating
> > logs.
> > Now I wo
On Wed, Jun 14, 2023 at 13:15 Greg Wooledge wrote:
> On Wed, Jun 14, 2023 at 12:30:37PM -0500, Tom Browder wrote:
..,
> If you want text log FILES (e.g. /var/log/whatever), install the rsyslog
> package. For rotation, install logrotate.
Thank you.
...
> Systemd by itself only creates binar
On 14 Jun 2023 19:30, Tom Browder wrote:
I’ve been running httpd for many years, long before systemd came along.
Somewhere in the various upgrades over the years I lost the old rotating
logs.
Now I would like to initiate the rotating logs again. Can I do that with
systemd somehow?
Isn't
On Wed, Jun 14, 2023 at 12:30:37PM -0500, Tom Browder wrote:
> I’ve been running httpd for many years, long before systemd came along.
> Somewhere in the various upgrades over the years I lost the old rotating
> logs.
>
> Now I would like to initiate the rotating logs again. Can
I’ve been running httpd for many years, long before systemd came along.
Somewhere in the various upgrades over the years I lost the old rotating
logs.
Now I would like to initiate the rotating logs again. Can I do that with
systemd somehow?
Thanks,
-Tom
After disabling Intel ME in the laptop BIOS, the kern.log began to be flooded
with thousands of such entries (approximately every 0.5s):
$ dmesg
intel ips :00:1f.6: ME failed to update for more than 1s, likely hung
On some forum I found this advice:
1. add intel_ips to the blacklist
echo
On 04/22/2022 01:50 AM, Jeremy Ardley wrote:
> I'm using Mate 1.20. I noticed a continual flood in my /var/log/Xorg.0.log
>
> modeset(0): Failed to get GBM bo for flip to new front.
>
> I tracked down the error at
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1645553
>
> I used more or less t
I'm using Mate 1.20. I noticed a continual flood in my /var/log/Xorg.0.log
modeset(0): Failed to get GBM bo for flip to new front.
I tracked down the error at
https://bugzilla.redhat.com/show_bug.cgi?id=1645553
I used more or less the procedure documented by pkoz 2018-12-28 08:17:40
UTC and t
On 17/03/22 19:37, mick crane wrote:
On 2022-03-17 05:09, Richard Hector wrote:
On 8/03/22 13:25, Richard Hector wrote:
Hi all,
I've recently set up a small box to run cups, to provide network
access to a USB-only printer. It's a 32-bit machine running bullseye.
I'm seeing log messages like
1 - 100 of 618 matches
Mail list logo
