My OS is debian 12 without GUI.

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Nov 29, 2024 at 08:07:20 +0800, Bitfox wrote:

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

Install the rsyslog package also. This will give you traditional, human-readable log files in /var/log/.

Without that package, all of your logs live in systemd's journal.
You should be able to find them there, with some effort, but many
people (including me) prefer to have text files in /var/log/.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bitfox wrote:

My OS is debian 12 without GUI.

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

by default, it's in /var/log.

If it is not there:

- does /etc/postfix/*.cf specify some other place?
- is systemd's journal swallowing it?
- is it being swallowed by another syslog program that is
sending logs elsewhere?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Nov 28, 2024 at 19:13:12 -0500, Dan Ritter wrote:

Bitfox wrote:

My OS is debian 12 without GUI.

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

by default, it's in /var/log.

No. As of bookworm, rsyslog is no longer installed by default, and
there are no human-readable log files by default.

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#changes-to-system-logging

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

I hope this helps.

As other have said, there has been a move to let systemctl manage log files, and we now access the logs via journalctl.

That said, I did find this command returned some info:

# grep "postfix\|open" /var/log/syslog
Nov 29 02:20:35 mail postfix/postfix-script[1522]: starting the Postfix mail system
Nov 29 02:20:35 mail postfix/master[1524]: daemon started -- version 3.5.25, configuration /etc/postfix

But to manage postfix, I have been using these commands:

# journalctl -u postfix

or

# journalctl -u [email protected]e

or if I have also implemented DKIM and DMARC, then

# journalctl -u [email protected]e -u opendkim -u opendmarc

If in a terminal I want to monitor in real time I use the -f option:

# journalctl -f -u [email protected]e -u opendkim -u opendmarc

I have seen the use of -t which allows the specification of multiple identifiers.
journalctl -t postfix

journalctl -t postfix -t postfix/anvil -t postfix/bounce -t postfix/cleanup -t postfix_container -t postfix/error -t postfix/local -t postfix/master -t postfix/pickup -t postfix/postalias -t postfix/postfix-script -t postfix/proxymap -t postfix/qmgr -t
postfix/scache -t postfix/sendmail -t postfix/smtp -t postfix/smtpd -t postfix/tlsmgr -t postfix/trivial-rewrite


https://man7.org/linux/man-pages/man1/journalctl.1.html

To show all fields emitted by a unit and about the unit, option
-u/--unit= should be used.

-t, --identifier=SYSLOG_IDENTIFIER
Show messages for the specified syslog identifier
SYSLOG_IDENTIFIER.

This parameter can be specified multiple times.

Today I discovered this useful line ( read up on the options from "man journalctl" :

journalctl --no-pager --quiet --identifier='postfix/smtp' --since='2022-10-30 00:00:00' --until='2024-12-06 23:59:59' --output='short'
journalctl --no-pager --quiet --identifier='postfix/smtp' --since='2022-10-30 00:00:00' --until='2024-12-06 23:59:59' --output='short'

PAGER CONTROL OPTIONS top

The following options control page support:

--no-pager
Do not pipe output into a pager.

-q, --quiet
Suppresses all informational messages (i.e. "-- Journal
begins at ...", "-- Reboot --"), any warning messages
regarding inaccessible system journals when run as a normal
user.

-t, --identifier=SYSLOG_IDENTIFIER
Show messages for the specified syslog identifier
SYSLOG_IDENTIFIER.

FILTERING OPTIONS top
The following options control how to filter journal records: -S, --since=, -U, --until= Start showing entries on or newer than the specified date, or on or older than the specified date, respectively.

-o, --output=
Controls the formatting of the journal entries that are
shown. Takes one of the following options:

short
is the default and generates an output that is mostly
identical to the formatting of classic syslog files,
showing one line per journal entry.

Added in version 206.

short-full
is very similar, but shows timestamps in the format the
--since= and --until= options accept. Unlike the
timestamp information shown in short output mode this
mode includes weekday, year and timezone information in
the output, and is locale-independent.

Added in version 232.

George.

On Friday, 29-11-2024 at 11:07 Bitfox wrote:

My OS is debian 12 without GUI.

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-11-29 10:08, Greg Wooledge wrote:

On Thu, Nov 28, 2024 at 19:13:12 -0500, Dan Ritter wrote:

Bitfox wrote:

My OS is debian 12 without GUI.

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

by default, it's in /var/log.

No. As of bookworm, rsyslog is no longer installed by default, and
there are no human-readable log files by default.

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#changes-to-system-logging

Thank you so much Greg.
I will install rsyslog instead.
Some tools like pflogsumm must use plain text logging.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-11-29 10:08, Greg Wooledge wrote:

On Thu, Nov 28, 2024 at 19:13:12 -0500, Dan Ritter wrote:

Bitfox wrote:

My OS is debian 12 without GUI.

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

by default, it's in /var/log.

No. As of bookworm, rsyslog is no longer installed by default, and
there are no human-readable log files by default.

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#changes-to-system-logging

Update:

following Greg's help, I run 'apt install rsyslog' and 'service postfix restart', now mail.log has been working.

2024-11-29T18:27:50.514443+08:00 mgw postfix/postfix-script[61549]:
starting the Postfix mail system
2024-11-29T18:27:50.522266+08:00 mgw postfix/master[61551]: daemon
started -- version 3.7.11, configuration /etc/postfix

Thanks a lot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday 28 November 2024 07:15:48 pm Greg Wooledge wrote:

On Fri, Nov 29, 2024 at 08:07:20 +0800, Bitfox wrote:

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

Install the rsyslog package also. This will give you traditional, human-readable log files in /var/log/.

Without that package, all of your logs live in systemd's journal.
You should be able to find them there, with some effort, but many
people (including me) prefer to have text files in /var/log/.

What's gained by them having changed this? (I wonder that about a lot of stuff.)

--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, �a critter that can
be killed but can't be tamed. �--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Nov 29, 2024 at 15:13:24 -0500, Roy J. Tellason, Sr. wrote:

On Thursday 28 November 2024 07:15:48 pm Greg Wooledge wrote:

Install the rsyslog package also. This will give you traditional, human-readable log files in /var/log/.

Without that package, all of your logs live in systemd's journal.
You should be able to find them there, with some effort, but many
people (including me) prefer to have text files in /var/log/.

What's gained by them having changed this? (I wonder that about a lot of stuff.)

My understanding is that the systemd journal Is Not Going Away And Tough
Nuts To You If You Don't Like It. With that in mind, the human-readable
log files were considered redundant, and removing rsyslog from the
default package set reduces "wasted" disk space storing two copies of
the same logs.

Now, you might ask why the systemd journal is being preferred and kept
over human-readable log files. I don't think anyone on debian-user
knows the answer to this.

So, I would advise not bothering to ask here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Fri, Nov 29, 2024 at 03:13:24PM -0500, Roy J. Tellason, Sr. wrote:

What's gained by them having changed this? (I wonder that about a lot of stuff.)

Most people don't need anything but the journal and if they do it's work
of seconds to install rsyslogd (and I do), as seen in this thread.
Defaults change and not all defaults will reflect my preferences.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sent: Friday, November 29, 2024 at 3:13 PM
From: "Roy J. Tellason, Sr." <[email protected]>
To: [email protected]
Subject: Re: where is mail.log

On Thursday 28 November 2024 07:15:48 pm Greg Wooledge wrote:

On Fri, Nov 29, 2024 at 08:07:20 +0800, Bitfox wrote:

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

Install the rsyslog package also. This will give you traditional, human-readable log files in /var/log/.

Without that package, all of your logs live in systemd's journal.
You should be able to find them there, with some effort, but many
people (including me) prefer to have text files in /var/log/.

What's gained by them having changed this? (I wonder that about a lot of stuff.)

Because systemd is the init system on most all distributions.
Get used to it.
Debian will need to massively need to change their ways, as the init scripts are not supported by systemd anymore.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/29/24 15:29, Greg Wooledge wrote:

On Fri, Nov 29, 2024 at 15:13:24 -0500, Roy J. Tellason, Sr. wrote:

On Thursday 28 November 2024 07:15:48 pm Greg Wooledge wrote:

Install the rsyslog package also. This will give you traditional,
human-readable log files in /var/log/.

Without that package, all of your logs live in systemd's journal.
You should be able to find them there, with some effort, but many
people (including me) prefer to have text files in /var/log/.

What's gained by them having changed this? (I wonder that about a lot of stuff.)

My understanding is that the systemd journal Is Not Going Away And Tough
Nuts To You If You Don't Like It. With that in mind, the human-readable
log files were considered redundant, and removing rsyslog from the
default package set reduces "wasted" disk space storing two copies of
the same logs.

Now, you might ask why the systemd journal is being preferred and kept
over human-readable log files. I don't think anyone on debian-user
knows the answer to this.

So, I would advise not bothering to ask here.

We are of like minds on this Greg.

I let synaptic update what I thought was just ghostscript about 2 weeks
back, but by the time it was done I had lost the two brother printers I
have, and had to use brothers installer scripts to renew the Brother
drivers from Brothers own repositories. Then they worked again to their
full capabilities as advertised on the box.

Why must there be a constant war between a companies products that
supports their own printers on linux systems? This isn't Epson or Canon
who spits on linux every time they make a new printer or scanner, this
is Brother, who _does_ /fully support/ their product on linux. Stop it.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Nov 29, 2024 at 10:36:50PM +0100, [email protected] wrote:

[...]

Because systemd is the init system on most all distributions.

It's the default, though, which is fine. That said, you can still
use SysV instead. Some assembly needed.

Get used to it.

Or apply some assembly.

Debian will need to massively need to change their ways, as the init scripts are not supported by systemd anymore.

But still by SysV...

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0qylwAKCRAFyCz1etHa RgcsAJ9PEQltN5BaGXXE1pOIdwsVSlDoQQCfZdqI7dIRjpAHdtMR+v2M2+U07Sw=
=mx3I
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 29-11-2024 at 21:30 Bitfox wrote:

On 2024-11-29 10:08, Greg Wooledge wrote:

On Thu, Nov 28, 2024 at 19:13:12 -0500, Dan Ritter wrote:

Bitfox wrote:

My OS is debian 12 without GUI.

After I installed postifx by apt, I can't find the path to mail.log.

the log file in /var/log doesn't exist.

do you know where is my mail.log now?

by default, it's in /var/log.

No. As of bookworm, rsyslog is no longer installed by default, and
there are no human-readable log files by default.

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#changes-to-system-logging

Update:

following Greg's help, I run 'apt install rsyslog' and 'service postfix restart', now mail.log has been working.

2024-11-29T18:27:50.514443+08:00 mgw postfix/postfix-script[61549]:
starting the Postfix mail system
2024-11-29T18:27:50.522266+08:00 mgw postfix/master[61551]: daemon
started -- version 3.7.11, configuration /etc/postfix

Thanks a lot.

Thank you for your update.

And thanks to others pointing out that rsyslog has been removed since Bookworm. Now I know that I will want to install rsyslog in Trixie servers once Trixie moves to production.

I am slowly learning journald and journalctl because as others have reported "it has been chosen as the way of the future".

As you said, for now there are still programs which still use rsyslog files.

I was pleased to learn "fail2ban works with journald" as I like to use fail2ban with postfix to block those who try to use postfix as a mail relay.

I read that journald does not allow for forwarding to remote logging servers. Many people suggest using journald to collect the log entires, and then rsyslog to do send them to a remote centralised log server. However I also found that systemd-journal-
remote.service, systemd-journal-remote.socket, and systemd-journal-remote are available, and have been available for quite some time.
https://www.digitalocean.com/community/tutorials/how-to-centralize-logs-with-journald-on-debian-10

Has anyone implemented remote logging with systemd-journal-remote and can say how well this works?

Checking with Synaptic found a package called "systemd-journal-remote" :
This package provides tools for sending and receiving remote journal logs:
* systemd-journal-remote
* systemd-journal-upload
* systemd-journal-gatewayd


George.








--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-11-30 20:31, [email protected] wrote:

You did not comprehend what I posted. I am on the systemd mail list.
They have dropped all sysV support.

May I ask what's the main difference between systemd and sysv for init
system?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sent: Saturday, November 30, 2024 at 1:37 AM
From: [email protected]
To: [email protected]
Subject: Re: where is mail.log

On Fri, Nov 29, 2024 at 10:36:50PM +0100, [email protected] wrote:

[...]

Because systemd is the init system on most all distributions.

It's the default, though, which is fine. That said, you can still
use SysV instead. Some assembly needed.

Get used to it.

Or apply some assembly.

Debian will need to massively need to change their ways, as the init scripts are not supported by systemd anymore.

But still by SysV...

You did not comprehend what I posted. I am on the systemd mail list.
They have dropped all sysV support.
The only way you'll have init script support is if you rip out systemd.
Since debian is using systemd for their init system debian will have to come into the here and now.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sent: Saturday, November 30, 2024 at 7:33 AM
From: "Bitfox" <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: where is mail.log

On 2024-11-30 20:31, [email protected] wrote:

You did not comprehend what I posted. I am on the systemd mail list.
They have dropped all sysV support.

May I ask what's the main difference between systemd and sysv for init system?

It is the same as day and nite

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 30, 2024 at 08:33:34PM +0800, Bitfox wrote:

On 2024-11-30 20:31, [email protected] wrote:

You did not comprehend what I posted. I am on the systemd mail list.
They have dropped all sysV support.

May I ask what's the main difference between systemd and sysv for init system?

This would be a very long answer. I'd recommend you start reading the
Wikipedia entry on "init system" [1] to get a rough idea.

Init systems organize the start of a Unix/Linux-type system after the
kernel has booted. Usually the kernel starts a first process (which
typically gets the process ID (PID) 1, which starts everything else
the system needs to get into a useful state.

Very roughly speaking, SysV init consults a bunch of shell scripts
which reside in /etc/init.d to know what is to be started in which
order, whereas systemd has a bunch of files stating which services
depend on which others and starts them whenever they are needed.

Lots and lots of details (like socket activation with systemd) are
missing in the rough description above, of course.

Cheers

[1] https://en.wikipedia.org/wiki/Init_system
--
tomás

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0sQ6wAKCRAFyCz1etHa Rt5PAJsEkVWjj54tQ0gUnxrOvDQMfXI64ACeJWqUEZLyUtC5FpUi4jeAfcUin/k=
=X+Zq
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Greg Wooledge (12024-11-29):

Now, you might ask why the systemd journal is being preferred and kept
over human-readable log files. I don't think anyone on debian-user
knows the answer to this.

The answer is certainly the same as for the rest of systemd: the old
system had terrible flaws and needed to be replaced, and while the Libre Software developers were busy arguing each for their pet project that
fixes about half the flaws while ignoring the other half or even
pretending they are features, the industrial bulldozer of Red Hat
arrived with systemd, that not so much fixed all the flaws as made them irrelevant by the virtue of replacing the board of snakes and ladders
with a board of hungry hungry hippos with its own different set of
flaws, but at least that more or less worked out of the box.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bitfox (12024-11-30):

May I ask what's the main difference between systemd and sysv for init system?

SysV Init is a bunch of fragile shell scripts with 80% boilerplate code
that will misbehave at the first unexpected circumstance and cannot even
tell you if your daemon has crashed or is running in five instances
stepping on each other toes.

Systemd is an over-engineered monstrosity that invalidates all the
intuition you have built based on Unix tradition, where the
documentation tells you it has six different ways of doing the bizarre
thing you need between which you cannot guess the difference but you
realize none work as documented and suit your needs, and you end up
abusing another feature in a way that will break on next release.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/30/24 6:55 AM, Scott Andrews wrote:

Sent: Saturday, November 30, 2024 at 7:33 AM
From: "Bitfox" <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: where is mail.log

On 2024-11-30 20:31, [email protected] wrote:

You did not comprehend what I posted. I am on the systemd mail list.
They have dropped all sysV support.

May I ask what's the main difference between systemd and sysv for init
system?

It is the same as day and nite

A better comparison might be gas versus diesel.
End user doesn't see much difference in routine.
*MAJOR* difference when time comes time to refuel or repair.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sat, Nov 30, 2024 at 01:31:12PM +0100, [email protected] wrote:

You did not comprehend what I posted.

I think it is you who are having problems reading.

I am on the systemd mail list.
They have dropped all sysV support.
The only way you'll have init script support is if you rip out systemd.

Yes, that is what is being said: it is still possible to run Debian
without systemd. People are doing it. There are package maintainers that
wish to let people do it. Surprise! It's a funny old world.

Since debian is using systemd for their init system debian will have
to come into the here and now.

Have you been living under a rock for ten years? The only reason why
systemd is able to drop their svsv init script support is *because*
Debian has been ready to also do so for a long time! Nothing operates in
a vacuum. There are multiple Debian developers who are also systemd
developers. They have been working on the goal to make everything in
Debian have a native systemd service unit for a *long* time and we've
been at that stage for some time already. There is no "coming into the
here and now". We are here already because of work done in part by
Debian.

However it is also separately true that many packages still have a sysv
init script that their maintainers support for the purposes of having it
work without systemd. Though I have no interest in doing that personally.

What you seem to not understand is that it has been Debian policy for
*years* for packages to have systemd unit files, but it has not been
policy for packages to get rid of any existing or contributed sysv init scripts. That is optional.

There's plenty of users who do need to "get into the here and now" (as evidenced by this thread), but Debian itself has been there for a full
release cycle at least.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 30, 2024 at 06:31:56PM +0100, Scott Andrews wrote:

[...]

LOL No, just No

Strong emotions, but... why?

[...]

systemd-sysv 252.31-1~deb12u1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Gone not longer supported

Why all of Debian? As a SysV init user, I, of course, don't
have (nor had, ever) that package. That one is for systemd
users wishing some SysV backward compatibility.

I have the impression you don't even know what systemd-sysv
is for.

And oh, BTW. I see that package on Trixie (Testing) and
Sid (Unstable) -- so I have no clue what your "Gone not
longer supported" means.

debian will need to see the lite or change to sysV init

Why "Debian"? You use it this way, I use it that way. It's
like an MTA: Debian's default is, AFAIK, Exim, but you can
have Postfix, you can have Sendmail or whatever.

Be happy and let others be happy.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0tSLgAKCRAFyCz1etHa RnIgAJ4klRXJSbOe9e3wJfaQC/3xQw8HvwCfXCDuDcnM7doiq4ItyAEMxEgtW0U=
=3S8I
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sat, Nov 30, 2024 at 06:31:56PM +0100, Scott Andrews wrote:

From: "Andy Smith" <[email protected]>
Yes, that is what is being said: it is still possible to run Debian
without systemd. People are doing it. There are package maintainers that wish to let people do it. Surprise! It's a funny old world.

Well I didn't say you couldn't

So what exactly *are* you saying?

Bearing in mind you have replied to someone who has said it is
possible to use Debian without systemd with comments like

"You did not comprehend what I posted."

and

"They have dropped all sysV support."

only to then reply

"Well I didn't say you couldn't"

You're not making a consistent argument, so if we have to judge who is
not comprehending…

Since debian is using systemd for their init system debian will have
to come into the here and now.

And debian is light years away from properly using systemd.

What deficiencies do you think exist in Debian 12 with regard to
systemd use?

systemd-sysv 252.31-1~deb12u1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Gone not longer supported

You've already conceded in the this very same email that it's possible
to run Debian without systemd so for those who do, it does not matter
what is or isn't in the systemd package, as they don't have it
installed!

debian will need to see the lite or change to sysV init

What is involved in "seeing the lite" here? What exactly is it that you
think needs to change?

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sent: Saturday, November 30, 2024 at 11:54 AM
From: "Andy Smith" <[email protected]>
To: [email protected]
Subject: Re: where is mail.log

Hi,

On Sat, Nov 30, 2024 at 01:31:12PM +0100, [email protected] wrote:

You did not comprehend what I posted.

I think it is you who are having problems reading.

Again You can not comprehend

I am on the systemd mail list.
They have dropped all sysV support.
The only way you'll have init script support is if you rip out systemd.

Yes, that is what is being said: it is still possible to run Debian
without systemd. People are doing it. There are package maintainers that
wish to let people do it. Surprise! It's a funny old world.

Well I didn't say you couldn't

Since debian is using systemd for their init system debian will have
to come into the here and now.

And debian is light years away from properly using systemd.

Have you been living under a rock for ten years? The only reason why
systemd is able to drop their svsv init script support is *because*
Debian has been ready to also do so for a long time! Nothing operates in
a vacuum. There are multiple Debian developers who are also systemd developers. They have been working on the goal to make everything in
Debian have a native systemd service unit for a *long* time and we've
been at that stage for some time already. There is no "coming into the
here and now". We are here already because of work done in part by
Debian.

However it is also separately true that many packages still have a sysv
init script that their maintainers support for the purposes of having it
work without systemd. Though I have no interest in doing that personally.

OS

What you seem to not understand is that it has been Debian policy for
*years* for packages to have systemd unit files, but it has not been
policy for packages to get rid of any existing or contributed sysv init scripts. That is optional.

Yet you miss the point

There's plenty of users who do need to "get into the here and now" (as evidenced by this thread), but Debian itself has been there for a full release cycle at least.

LOL No, just No

[alarm@alarm ~]$ pacman -Q|grep systemd
systemd 256.8-2
systemd-libs 256.8-2

[alarm@alarm ~]$ cat /etc/hosts
# Static table lookup for hostnames.
# See hosts(5) for details.

dpkg -l|grep systemd
libnss-resolve 252.31-1~deb12u1
libpam-systemd 252.31-1~deb12u1
libsystemd-shared 252.31-1~deb12u1
libsystemd0 252.31-1~deb12u1
systemd 252.31-1~deb12u1
systemd-container 252.31-1~deb12u1
systemd-resolved 252.31-1~deb12u1
systemd-sysv 252.31-1~deb12u1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Gone not longer supported
debian will need to see the lite or change to sysV init

systemd-timesyncd 252.31-1~deb12u1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 30, 2024 at 07:16:16PM +0100, [email protected] wrote:

[...]

And that "SysV backward compatibility" has been eliminated from systemd

Exactly. Thus, as a SysV init user, I don't need that package. Actually,
it would be counterproductive for me to install it...

I have the impression you don't even know what systemd-sysv
is for.

Yes I do know what systemd-sysv is for (I run my own custom distribution).

[...]

I don't know what you know or not. I just reported on my impression.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0tXsQAKCRAFyCz1etHa Rh3eAJwIETiHvbb97bGf/DFPtpu9mxS27gCfcGuPatFwlGNZNxZhgqyJkX5Abac=
=7GkR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sent: Saturday, November 30, 2024 at 12:58 PM
From: [email protected]
To: "Scott Andrews" <[email protected]>
Cc: "Andy Smith" <[email protected]>, [email protected]
Subject: Re: where is mail.log

On Sat, Nov 30, 2024 at 06:31:56PM +0100, Scott Andrews wrote:

[...]

systemd-sysv 252.31-1~deb12u1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Gone not longer supported

Why all of Debian? As a SysV init user, I, of course, don't
have (nor had, ever) that package. That one is for systemd
users wishing some SysV backward compatibility.

And that "SysV backward compatibility" has been eliminated from systemd

I have the impression you don't even know what systemd-sysv
is for.

Yes I do know what systemd-sysv is for (I run my own custom distribution).

* Support for System V service scripts is deprecated and will be
removed in v258. Please make sure to update your software
*now* to include a native systemd unit file instead of a legacy
System V script to retain compatibility with future systemd releases.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sat, Nov 30, 2024 at 07:16:16PM +0100, [email protected] wrote:

From: [email protected]
Why all of Debian? As a SysV init user, I, of course, don't
have (nor had, ever) that package. That one is for systemd
users wishing some SysV backward compatibility.

And that "SysV backward compatibility" has been eliminated from systemd

Okay, there is a fundamental misunderstanding here and I'm afraid it's
yours. I am going to try one last time.

The "SysV backward compatibility" you're talking about is for systemd
users to be able to run things that only have sysv init scripts, not
systemd unit files. There are no significant packages left in Debian
that require it, so it doesn't matter for Debian. Its removal has been a
Debian systemd maintainer goal.

Separately, there are people *not using systemnd* on Debian. They don't
have systemd at all! They do not have the package that you warn is going
away. They will therefore be utterly unaffected by that.

So, what you keep going on about is a non-event for both groups.

Yes I do know what systemd-sysv is for (I run my own custom distribution).

* Support for System V service scripts is deprecated and will be
removed in v258. Please make sure to update your software
*now* to include a native systemd unit file instead of a legacy
System V script to retain compatibility with future systemd releases.

You are lecturing someone who is not a user of systemd, about what systemd requires its users to do.

A piece of software that has a sysv init script keeps working with sysv
init no matter if systemd removes support for ice cream on Tuesdays or
turns your mother into an aardvark. Such people do not care what systemd
does or does not do, because they don't use it! Imagine that!

I am genuinely amazed that this concept is so hard to understand. A new
low for debian-user discourse.

Regards,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 30, 2024 at 19:16:16 +0100, [email protected] wrote:

Yes I do know what systemd-sysv is for (I run my own custom distribution).

* Support for System V service scripts is deprecated and will be
removed in v258. Please make sure to update your software
*now* to include a native systemd unit file instead of a legacy
System V script to retain compatibility with future systemd releases.

The version of systemd in trixie (and also in sid) is 257 according
to packages.debian.org.

I don't know whether that's the version trixie is going to use upon
release, but if it is, then your v258 cutoff won't be relevant until
the *next* release after trixie.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sat, Nov 30, 2024 at 07:51:40PM +0100, Scott Andrews wrote:

The version of systemd in trixie (and also in sid) is 257 according
to packages.debian.org.

I don't know whether that's the version trixie is going to use upon release, but if it is, then your v258 cutoff won't be relevant until
the *next* release after trixie.

It is the future.

But is it Web Scale?

https://www.youtube.com/watch?v=b2F-DItXtZs

Your contributions to this thread have made me long for the farm.

Regards,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sent: Saturday, November 30, 2024 at 1:33 PM
From: "Greg Wooledge" <[email protected]>
To: [email protected]
Subject: Re: where is mail.log

On Sat, Nov 30, 2024 at 19:16:16 +0100, [email protected] wrote:

Yes I do know what systemd-sysv is for (I run my own custom distribution).

* Support for System V service scripts is deprecated and will be
removed in v258. Please make sure to update your software
*now* to include a native systemd unit file instead of a legacy
System V script to retain compatibility with future systemd releases.

The version of systemd in trixie (and also in sid) is 257 according
to packages.debian.org.

I don't know whether that's the version trixie is going to use upon
release, but if it is, then your v258 cutoff won't be relevant until
the *next* release after trixie.

It is the future.

The debian issue will be to deal with all the things systemd is bringing and SysV is not supporting.

Is debian going to drop SysV?

My custom distribution already deals with the v258 cutoff.
It is a rolling release type and does have major releases.

What happens when /etc/hosts goes away?
As you see from my earlier post I have already dealt with that and for that matter /etc/fstab also.

[alarm@alarm ~]$ cat /etc/hosts
# Static table lookup for hostnames.
# See hosts(5) for details.

[alarm@alarm ~]$ cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

Some distributions have dealt with the changes also.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 30, 2024 at 06:56:08PM +0000, Andy Smith wrote:

Hello,

On Sat, Nov 30, 2024 at 07:51:40PM +0100, Scott Andrews wrote:

The version of systemd in trixie (and also in sid) is 257 according
to packages.debian.org.

I don't know whether that's the version trixie is going to use upon release, but if it is, then your v258 cutoff won't be relevant until
the *next* release after trixie.

It is the future.

But is it Web Scale?

https://www.youtube.com/watch?v=b2F-DItXtZs

No, "web scale" would be Chrome ignoring the hosts setting and phoning
home for DNS. Don't ask me how I know.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0tjsAAKCRAFyCz1etHa RpQGAJ4uS+mw9LMSYmTSsbvhtWiCvyTtEQCfcZhcNyvsPCMfD/aKpAYzjmEyW0U=
=Pqwm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday 30 November 2024 08:37:03 am Nicolas George wrote:

Greg Wooledge (12024-11-29):

Now, you might ask why the systemd journal is being preferred and kept
over human-readable log files. I don't think anyone on debian-user
knows the answer to this.

The answer is certainly the same as for the rest of systemd: the old
system had terrible flaws and needed to be replaced, and while the Libre Software developers were busy arguing each for their pet project that
fixes about half the flaws while ignoring the other half or even
pretending they are features, the industrial bulldozer of Red Hat
arrived with systemd, that not so much fixed all the flaws as made them irrelevant by the virtue of replacing the board of snakes and ladders
with a board of hungry hungry hippos with its own different set of
flaws, but at least that more or less worked out of the box.

Regards,

Ah. Now we know who to blame for it... :-)


--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, �a critter that can
be killed but can't be tamed. �--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

since noone mentioned it:

postfix has its own logging mechanism:

https://www.postfix.org/MAILLOG_README.html

greetings...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael (12024-12-02):

postfix has its own logging mechanism:

Making postfix part of the problem: different format for timestamps,
separate rotation and retention configuration, etc.

We do not want a different editor and build system for each programming platform.

We do not want a different packaging system for each language.

We do not want a different logging system for each daemon.

We do not want square wheels reinvented everywhere.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] writes:

You did not comprehend what I posted. I am on the systemd mail list.
They have dropped all sysV support.

Does it really even matter if there's SysV support in systemd? You can
still put

ExecStart=your-sysv-init-script start

in your systemd service file and I don't think that's going away. Same
for other parameters like stop/restart/whatever.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Mon, Dec 02, 2024 at 01:08:52PM +0100, Nicolas George wrote:

We do not want a different logging system for each daemon.

Unfortunately rather common practice though even before systemd-journald
of course: Exim, Apache HTTPD Server, HAProxy, … (some of these CAN be configured to log to syslog, it's just not their default state)

I think in the past syslog was regarded as fairly low throughput and potentially slow to complete. Also older syslog implementations could
only filter by facility and priority. So high throughput logging like for a web server (access logs etc), which also often wanted to split by things like vhost, were encouraged to do own logging.

Decent syslog implementations like rsyslog or syslog-ng have been fast
and full of features for ages though. Maybe app authors don't want to
assume their presence - and assume which one? App-specific logging does
have the benefit that the documentation for splitting the logs by some attribute can come with the app.

I am in two minds whether the prevalence of journald will encourage or discourage projects from growing their own logs. On the one hand it's
easy to display by unit, on the other hand I rarely see people doing
that and when there's a lot of logs they just complain.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Dec 03, 2024 at 10:00:27 +0700, Max Nikulin wrote:

<https://0pointer.de/blog/projects/systemctl-journal.html>
systemd for Administrators, Part XIII
Posted on Fr 18 Mai 2012
Log and Service Status

The original reason we started to work on the journal was one specific feature idea, that to the outsider might appear simple but without the journal is difficult and inefficient to implement: along with the output
of systemctl status we wanted to show the last 10 log messages of the daemon.

I could not recall where I saw a more verbose description of design ideas. Perhaps faster selection of records within a given time range.

Journald&journalctl have their shortcomings, but often they are more convenient during debugging: more precise timestamps, filtering by all processes from a service cgroup.

Separate logs per service aren't a new idea. Service managers that
came before systemd (e.g. daemontools) were doing that already. And
you don't need *binary* files to achieve it.

However, my comment wasn't about systemd's design choices. It was
about Debian's choices.

On 30/11/2024 03:29, Greg Wooledge wrote:

Now, you might ask why the systemd journal is being preferred and kept
over human-readable log files. I don't think anyone on debian-user
knows the answer to this.

What I don't know, and don't think anyone on this list knows, is why
*Debian* chose to toss the human-readable separate text log files away
in favor of the systemd monolithic binary journal.

Anyway, this is all academic at this point. We know what Debian chose,
and we know how to make our own choices, if we want something else.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue Dec 3, 2024 at 3:11 AM GMT, Greg Wooledge wrote:

What I don't know, and don't think anyone on this list knows, is why
*Debian* chose to toss the human-readable separate text log files away
in favor of the systemd monolithic binary journal.

The bug that documents rsyslog moving from priority: 'important' to
to 'optional' (which I think must have been the change which resulted
in rsyslog not being installed by default from Bookworm onwards) is <https://bugs.debian.org/1018788>.

The rationale offered there is "I want to avoid that log data is stored
twice on disk."

The bug also references an earlier 2021 thread on debian-devel@: <https://lists.debian.org/debian-devel/2021/11/msg00179.html>. That
thread did not attract much discussion, IMHO.


--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ [email protected]
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, December 2, 2024 4:04:12 PM CET, Andy Smith wrote:

Unfortunately rather common practice though even before systemd-journald
of course: Exim, Apache HTTPD Server, HAProxy, … (some of these CAN be configured to log to syslog, it's just not their default state)

iirc, and the referenced postfix page confirms that, postfix added its own logfile only because of the shortcomings of systemd's journald.

they never felt the need to add logging in the roughly 20+ years before that...

greetings...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)