You are not seriously considering dropping the support of sysVinit?!

[freebsd]

Hello,

systemd is a replacement for the standard init command, which normally 
runs as process id 1 on initialisation of a UNIX bootup. There has been 
a movement, especially around the Red Hat-related developers to copy 
Microsoft Windows and all of its features. Now this interpretation of 
how a userspace should look like is implemented and was introduced with 
big criticism and change in the Open Source world into many 
distributions. The debacle in Debian is the best example in how to not 
introduce such a changing technology into a distribution.


https://suckless.org/sucks/systemd/

I won't repeat the same thing said on many places because now we are 
living with the reality of systemD all around us in corporate 
environments where it was forced down on our throats without even a 
discussion. If Debian drops sysVinit support I will drop Debian and make 
sure to push BSD integration at my workplaces too. Matter of fact I 
already started migrating apps from the old Debian 7 (last good shitD 
free debian distro) to FreeBSD/NetBSD/OpenBSD alternatives.


Dropping sysvinit would also put an enormous amount of work on the 
Devuan project (the only future for Debian) by making them fork more 
packages.


This is your last chance to do the right thing and announce the removal 
of this fucking piece of shit malware(D) from Debian and go back to 
sysVinit or openrc!

Re: You are not seriously considering dropping the support of sysVinit?!

[Ansgar Burchardt]

free...@tango.lu writes:
> If Debian drops sysVinit support I will drop Debian
[...]
> This is your last chance to do the right thing and announce the
> removal of this fucking piece of shit malware(D) from Debian and go
> back to sysVinit or openrc!

So dropping sysvinit support will make you go away?  That sounds like a
positive effect to me, but for some reason you seem to try and use it as
a threat?

Ansgar
  (SCNR)

Re: Debian Buster release to partially drop non-systemd support

[Philipp Kern]

On 17.10.2018 06:52, Russ Allbery wrote:
> I think a package of a daemon that does not inherently require any
> systemd-specific features and would work straightforwardly with sysvinit,
> but has only a systemd unit file and no init script, is not only buggy but
> RC-buggy.  That's what Policy currently says.

And it would not be buggy if it does not ship any init integration or
relies on a non-init service supervision system like runit. (The crux
being that systemd is not modular to be run that way and not portable.)

> It is quite easy to write a sysvinit init script for most daemons that
> will basically work.  I don't think the maintainer is obligated to do much
> more than that (for instance, I don't think you need to try to duplicate
> systemd hardening configuration or other features that are quite
> challenging to do under sysvinit without more tool support, although some
> of that may be coming in start-stop-daemon).
> 
> I don't think it's reasonable to expect every Debian maintainer to have a
> system booted into sysvinit to test the init script, since that can be
> quite an undertaking if one isn't using sysvinit normally, but thankfully
> you don't need to do that to test the init script.  Just delete the unit
> file and then test the init script with systemd.  For nearly all daemons
> that don't involve tight system integration, this will be more than
> adequate.

You say "more than adequate". I don't particularly see it as providing a
solid system as you don't get restart on failure. Now I can see how
people say that this is not a problem as daemons should not crash in the
first place. Maybe I just value reliability of service more highly than
being woken up at night being told that my service is unreliable.

Is a possible answer here to ship an init script and then provide
additional supervision options using override files - to enhance
whatever is provided by the sysv generator?

This statement also does not address a daemon that only runs through
socket activation - passing an fd to the daemon. But I don't have any
example handy and this might be a strawman argument. Except that I could
see that for simplicity newer daemons might be written in this way as it
does cut a significant amount of socket handling code.

To some degree I regret that we cannot provide a fully integrated
distribution by mandating that the core layers (be it kernels or init
systems) can be switched out. systemd still supports init scripts but on
the other side there's pretty much complete stagnation with the onus on
the systemd maintainers to keep things working. There could as well have
been an effort to support a subset of the unit language for sysvinit.

That said, I'm grateful for Petter pointing out /lib/init/init-d-script
and I need to investigate that as an alternative to write a full blown
shell script with logic that needs to be updated everywhere when there
are changes.

> If you want to do more than the minimum and try to replicate more unit
> file features in the init script, that's great, but I think it's also
> reasonable to not do so and wait for sysvinit users to file bugs.  But I
> do think it's a key and important part of our general project-wide
> compromise that maintainers of packages that include daemons continue to
> do the reasonable minimum to keep those daemons basically working with
> other init systems, until such time as the project as a whole decides that
> sysvinit support should not be maintained.

I guess this thread will show if people other than the systemd folks
actually step up to maintain this support. But I'm more worried about
the externalized cost to the maintainers to contribute work to keep this
working if the user base is minimal. That said, I guess 1.55% of the
popcon base having sysvinit-core installed aka 3k users is way more than
some of the ports have. (Although I actually see the Linux ones as less
of a burden than switching out and supporting multiple core components.)

>> It'd need to run much more often (every 15 minutes). So cron.daily
>> wouldn't fit. For the sake of the argument it'd need to be a shell
>> script that checks multiple conditions (see [1]). And we currently don't
>> have timer/cron deduplication, unfortunately. That means it'd also need
>> to disable itself on systemd systems (but of course cron would still
>> invoke the script periodically). Similarly - as a more general remark -
>> having it as a cronjob doesn't let you monitor it in quite the same way.
> 
> I think we should solve the problem of timer/cron de-duplication before
> opening the door to timer units.  I agree that timer units would be a very
> valuable addition to a lot of packages, but timer/cron de-duplication
> feels like an entirely tractable problem that's useful to resolve in its
> own right.  Maybe we can just do that?

I suppose one answer would be a cron generator. Given that policy
specifies naming schemes for /etc/cron.{hourly,daily,weekly,monthly,d},
there could probably

Re: You are not seriously considering dropping the support of sysVinit?!

[Jonathan Dowland]

On Wed, Oct 17, 2018 at 10:19:31AM +0200, Ansgar Burchardt wrote:

So dropping sysvinit support will make you go away?  That sounds like a
positive effect to me, but for some reason you seem to try and use it as
a threat?


Please don't feed the trolls. I enjoy mail from you, and it's a shame
when stuff leaks through my killfile via quotes in your (or other
people's) mails.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#911219: ITP: r-cran-plumber -- API Generator for GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-plumber
  Version : 0.4.6
  Upstream Author : Trestle Technology, LLC,
* URL : https://cran.r-project.org/package=plumber
* License : MIT
  Programming Lang: GNU R
  Description : API Generator for GNU R
 This GNU R package gives the ability to automatically generate and serve
 an HTTP API from R functions using the annotations in the R documentation
 around your functions.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-plumber

Re: PHP Support in Debian

[Ondřej Surý]

Hi,

> Is it possible to support these versions properly for our
> users as long as there is security/LTS support for our releases?


the PHP 7.0 will be supported like any other package in Debian - the security 
fixes will be cherrypicked and applied for the lifetime of Debian stretch. Then 
the LTS team will (or will not) take over.

> Lots of applications require php 7.1 or 7.2 these days. As
> there is no official backport, the only option right now is
> to use CentOS with SCLs

PHP 7.0 and 7.1 are gone from unstable and testing and PHP 7.2 will be removed 
as soon as the transition to PHP 7.3 is finished. That means the only version 
of PHP that’s backportable according to Debian backport rules would be PHP 7.3.

If somebody else wants to do the backport, feel free to do so, I am not 
blocking anyone to do the work. As a fact, all the PHP packages could be 
compiled as far as to Debian Jessie and Ubuntu Trusty (which means jumping 
through more hoops than strictly necessary). I am just declaring there’s only 
so much time one person can have, so I am not doing the official PHP backport.

> I know that there is
> https://deb.sury.org - but prefer to trust stuff that was
> built on Debian machines and is distributed/signed with a
> key we trust.

Shrug, all the packages that I upload to Debian and to the DPA are signed by 
the same key - mine.

> Will there be a proper solution for that soon?

That’s very vague - there’s already a proper solution in place - backporting 
the security fixes is the *Debian way* of maintaining packages in stable. The 
exception of uploading new PHP patch releases to stable is well an exception 
and it took some time and effort to negotiate it.

Cheers,
Ondrej
--
Ondřej Surý 

> On 16 Oct 2018, at 17:06, Bernd Zeimetz  wrote:
> 
> Hi,
> 
> we (as in several customers and I) are wondering about the status
> of php support in Debian.
> 
> * According to http://php.net/supported-versions.php upstream
> security support for 5.6 (jessie) and 7.0 (stretch) will be gone
> soon. Is it possible to support these versions properly for our
> users as long as there is security/LTS support for our releases?
> 
> * Lots of applications require php 7.1 or 7.2 these days. As
> there is no official backport, the only option right now is
> to use CentOS with SCLs. I know that there is
> https://deb.sury.org - but prefer to trust stuff that was
> built on Debian machines and is distributed/signed with a
> key we trust.
> 
> 
> Will there be a proper solution for that soon?
> 
> 
> Thanks,
> 
> Bernd
> 
> 
> -- 
> Bernd ZeimetzDebian GNU/Linux Developer
> http://bzed.dehttp://www.debian.org
> GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: PHP Support in Debian

[Holger Levsen]

On Wed, Oct 17, 2018 at 11:04:00AM +0200, OndÅ?ej Surý wrote:
> > I know that there is
> > https://deb.sury.org - but prefer to trust stuff that was
> > built on Debian machines and is distributed/signed with a
> > key we trust.
> Shrug, all the packages that I upload to Debian and to the DPA are signed by 
> the same key - mine.

yes, but when using your repo one has to add your key to the keys apt
trusts, and this is something completly different than using proper
backports.

(I'm very thankful for you providing your repo, but it's not the same as
if those packages were on backports.)

(A workaround for those not wanting to add your key to apt is of course
to download your sources and rebuild them, and then put in a repo of
local packages, and then tell apt to trust that local key. It's more
work but c'est la vie.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: PHP Support in Debian

[Marco d'Itri]

On Oct 17, Holger Levsen  wrote:

> yes, but when using your repo one has to add your key to the keys apt
> trusts, and this is something completly different than using proper
> backports.
Well... I trust much more Ondrej's archive since over the years it has 
proven its quality and scope, while new packages are uploaded to 
backports sometimes without much testing.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: wpa_supplicant cannot authenticate against freeradius 3.0.16+dfsg-4.1+b1

[Marvin Renich]

* Kamil Jońca  [181017 01:27]:
> 
> Recently I tried to upgrade my freeradius package to 3.0.16+dfsg-4.1+b1
> And after that my laptop with wpa_supplicant stops authenticate:
> 
> with version 3.0.16+dfsg-3+b1 everything works ok.
> Any hints what to check in logs?

Please ask user questions on debian-user, not debian-devel.  You might
also try to find a freeradius  support channel; they are likely to have
both a mailing list and an IRC channel (I don't use freeradius, so I
don't know).

>From your description, this could certainly be a bug in either
freeradius or wpa_supplicant, but doing the triage on a user support
mailing list is usually very helpful to the maintainer.  Afterwards, you
can use reportbug to file a bug for the correct package.  debian-devel
is not the correct mailing list for this.

...Marvin

Re: A problem with a watch file

[Tommi Höynälänmaa]

On 16.10.2018 15:40, Xavier wrote:

Hello,
you must install upstream key in debian/upstream/signing-key.asc: uscan
should verify key with its own keystore, not yours.

Cheers,
Xavier


I have installed the key to both debian/upstream/signing-key.pgp and 
debian/upstream/signing-key.asc. It still doesn't work.


Regards,

 Tommi

Re: A problem with a watch file

[Georg Faerber]

Hi,

On 18-10-17 15:11:00, Tommi Höynälänmaa wrote:
> I have installed the key to both debian/upstream/signing-key.pgp and
> debian/upstream/signing-key.asc. It still doesn't work.

Run uscan with increased verbosity (-v), it might give you a hint what
is going wrong.

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#911235: ITP: multiblend -- multi-level image blender for the seamless blending of panoramic images

[Fernando Toledo]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

Package name: multiblend
Version: 0.6.2

Upstream Author: David Horman 

URL: http://horman.net/multiblend/

License: GPL-2+
Description:

*multiblend* is a multi-level image blender for the
seamless blending of panoramic images, such as those created with
PTAssembler  (my personal 
favourite), Hugin , or PTGui 
. It is a significantly faster drop-in 
alternative to /Enblend/ , although it 
lacks /Enblend's/ advanced features.


I'm working on build this package https://github.com/ftoledo/pkg-multiblend

 

Re: PHP Support in Debian

[Jonas Meurer]

Am 17.10.18 um 12:00 schrieb Marco d'Itri:
> On Oct 17, Holger Levsen  wrote:
> 
>> yes, but when using your repo one has to add your key to the keys apt
>> trusts, and this is something completly different than using proper
>> backports.
> Well... I trust much more Ondrej's archive since over the years it has 
> proven its quality and scope, while new packages are uploaded to 
> backports sometimes without much testing.

I agree that Odrej's packages (from deb.sury.org) have been of good
quality in the past and I'm a happy user of them myself for situations
where php7.1 or newer is needed on servers running Stretch.

Still I agree with Holger and would prefer packages from official Debian
infrastructure for two reasons:

* The packages (except for binary uploads) are known to be *built* on
  Debian infrastructure. In case of sury.org I have no doubts that
  Ondrej takes care of a good build environment. But for average users,
  being able to get packages from official Debian infrastructure gives
  them more confidence.

* Adding backports to my sources.list doesn't automatically pull any
  packages from there. I have to choose particular packages in a manual
  process in order to install them from backports. That's different for
  repositories like sury.org that provide packages under the release
  target (e.g. 'stretch').
  If I add deb.sury.org to my sources.list, then installed packages with
  newer versions in this repo are automatically upgraded. This makes it
  much easier to abuse the repo, e.g. in order to spread malware. In
  other words, the attack vector is way larger.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

wpa_supplicant cannot authenticate against freeradius 3.0.16+dfsg-4.1+b1

[Kamil Jońca]

(previously sent to debian-devel by mistake)


Recently I tried to upgrade my freeradius package to 3.0.16+dfsg-4.1+b1
And after that my laptop with wpa_supplicant stops authenticate:

excerpt from wpa_supplicant

network={
ssid=<<...>
proto=RSN
key_mgmt=WPA-EAP
pairwise=CCMP
group=CCMP
eap=TLS
identity=<<...>>
ca_cert=<<...>>
client_cert=<<...>>
private_key=<<...>>
private_key_passwd=<<...>>
}

with version 3.0.16+dfsg-3+b1 everything works ok.
Any hints what to check in logs?

On first sight there is nothing strange in freeradius logs, but
wpa_suplicant seems to wait for reply.

My other devices (Windows 7 + some androids ) works.

KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
The last vestiges of the old Republic have been swept away.
-- Governor Tarkin

Re: wpa_supplicant cannot authenticate against freeradius 3.0.16+dfsg-4.1+b1

[Andrey Rahmatullin]

On Wed, Oct 17, 2018 at 04:04:15PM +0200, Kamil Jońca wrote:
> (previously sent to debian-devel by mistake)
You've repeated that mistake.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#911243: ITP: sockperf -- Network benchmarking utility for testing latency and throughput

[Talat Batheesh]

Package: wnpp
Severity: wishlist
Owner: Talat Batheesh 

* Package name: sockperf
  Version : 3.5.0
  Upstream Author : Liran Oz 
* URL : https://github.com/Mellanox/sockperf
* License : BSD
  Programming Lang: C, C++
  Description : Network benchmarking utility for testing latency and 
throughput

sockperf is a network benchmarking utility over socket API that was 
designed for testing performance (latency and throughput) of 
high-performance systems (it is also good for testing performance of 
regular networking systems as well). It covers most of the socket API 
calls and options.
Specifically, in addition to the standard throughput tests, sockperf, 
does the following:

Measure latency of each discrete packet at sub-nanosecond  
resolution (using TSC register that counts CPU ticks with very  low 
overhead).

* Does the above for both ping-pong mode and for latency under  load 
mode. This means that we measure latency of single packets  even under 
load of millions Packets Per Second (without waiting  for reply of 
packet before sending subsequent packet on time)

* Enable spike analysis by providing histogram, with various  
percentiles of the packets' latencies (for example: median, min,  max, 
99% percentile, and more), (this is in addition to average  and 
standard deviation). Also, sockperf provides full log with  all 
packet's tx/rx times that can be further analyzed with  external 
tools, such as MS-Excel or matplotlib - All this  without affecting 
the benchmark itself.

* Support MANY optional settings for good coverage of socket API  and 
network configurations, while still keeping very low  overhead in the 
fast path to allow cleanest results.

Bug#911245: ITP: libvma -- libvma is a LD_PRELOAD-able library that boosts performance

[Talat Batheesh]

Package: wnpp
Severity: wishlist
Owner: Talat Batheesh 

* Package name: libvma
  Version : 8.7.1
  Upstream Author : Liran Oz 
* URL : https://github.com/Mellanox/libvma
* License : GPLv2 and BSD
  Programming Lang: C, C++
  Description : libvma is a LD_PRELOAD-able library that boosts performance

libvma is a LD_PRELOAD-able library that boosts performance of TCP and UDP 
traffic.
It allows application written over standard socket API to handle fast path data
traffic from user space over Ethernet and/or Infiniband with full network stack
bypass and get better throughput, latency and packets/sec rate.

No application binary change is required for that.
libvma is supported by RDMA capable devices that support "verbs" 
IBV_QPT_RAW_PACKET QP for Ethernet and/or IBV_QPT_UD QP for IPoIB.

Re: Debian Buster release to partially drop non-systemd support

[Russ Allbery]

Philipp Kern  writes:
> On 17.10.2018 06:52, Russ Allbery wrote:

>> I think a package of a daemon that does not inherently require any
>> systemd-specific features and would work straightforwardly with
>> sysvinit, but has only a systemd unit file and no init script, is not
>> only buggy but RC-buggy.  That's what Policy currently says.

> And it would not be buggy if it does not ship any init integration or
> relies on a non-init service supervision system like runit. (The crux
> being that systemd is not modular to be run that way and not portable.)

No, I think that's also buggy.  If it's a daemon that should be started at
boot and it doesn't include init integration, I think that's an obvious
bug.  It's very hard to write a Policy rule that says this, since it's
more of a common sense sort of bug.

> You say "more than adequate". I don't particularly see it as providing a
> solid system as you don't get restart on failure. Now I can see how
> people say that this is not a problem as daemons should not crash in the
> first place. Maybe I just value reliability of service more highly than
> being woken up at night being told that my service is unreliable.

My point is that sysvinit is a non-default configuration and it's
reasonable to expect that it may be missing some features or robustness.
If you have the time and resources to put into equaling the robustness
that you would get under systemd, that's great, but sysvinit is much more
of a fire-and-forget system and is known to in general not have that
robustness property.  sysvinit users who care will run something like
monit that watches health externally and takes appropriate action.

I think every packager owes it to the social fabric of the project to make
the effort to provide a basic init script, in the same way that we do
basic porting to other architectures and investigate build failures.
There is some point, which is subjective, beyond which I think it's
reasonable to ask someone who cares about sysvinit to do more complicated
work, but I think a basic init script tested under systemd's init support
is a reasonable request.

My personal concern is more about the social community of the project than
about the technical details.  I consider providing an init script even if
I don't personally use sysvinit to be extending the hand of community and
solidarity to other Debian community members who use it.  To say to them
that their concerns have been heard and supported, even if I don't agree
with their concerns.  Personally, I find that extremely important, a
principle that's as important as the technical quality bar we try to reach
in our packages.

> Is a possible answer here to ship an init script and then provide
> additional supervision options using override files - to enhance
> whatever is provided by the sysv generator?

I personally would tend to maintain separate init and systemd unit files
and only lightly test the init script unless I knew there was something
tricky going on, but this answer varies based on the complexity of the
daemon.

> This statement also does not address a daemon that only runs through
> socket activation - passing an fd to the daemon. But I don't have any
> example handy and this might be a strawman argument. Except that I could
> see that for simplicity newer daemons might be written in this way as it
> does cut a significant amount of socket handling code.

Yes, at the point where we have an upstream daemon that was written
explicitly for use with systemd in that fashion, I think that turns into a
different sort of question.  This is now more akin to porting, and that's
a different bar.  I don't think we can place hard requirements on what a
maintainer chooses to do here, other than asking for them to take patches
from porters if those are offered.

> To some degree I regret that we cannot provide a fully integrated
> distribution by mandating that the core layers (be it kernels or init
> systems) can be switched out. systemd still supports init scripts but on
> the other side there's pretty much complete stagnation with the onus on
> the systemd maintainers to keep things working. There could as well have
> been an effort to support a subset of the unit language for sysvinit.

I do completely agree with the general thrust of this thread: sysvinit
needs an active maintenance team, and without that work, it will
eventually die.  There's a limit to how much people who don't use it
should feel obligated to keep it working.  Hopefully those who do use it
will be able to find the resources to support and improve it (and indeed
being able to support the unit *syntax* would be a huge step towards
making sysvinit support in Debian more robust).

> I suppose one answer would be a cron generator. Given that policy
> specifies naming schemes for /etc/cron.{hourly,daily,weekly,monthly,d},
> there could probably be a mapping from filename to timer. But the cron
> language itself does not contain identifiers, so there's still

Re: Debian Buster release to partially drop non-systemd support

[Paul Wise]

On Thu, Oct 18, 2018 at 5:24 AM Russ Allbery wrote:

> Timer units are also a more complicated problem since they're not a
> superset of cron behavior.  They do some things better than cron jobs;
> they do other things much *worse* than cron jobs.  I have cron jobs that I
> wanted to convert to timer units and discovered I couldn't because timers
> simply wouldn't work for what I was trying to do.

Could you give some examples of the issues you discovered with systemd timers?

BTW, we have in systemd-cron a tool for generating systemd units from
crontab/etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian Buster release to partially drop non-systemd support

[Russ Allbery]

Paul Wise  writes:
> On Thu, Oct 18, 2018 at 5:24 AM Russ Allbery wrote:

>> Timer units are also a more complicated problem since they're not a
>> superset of cron behavior.  They do some things better than cron jobs;
>> they do other things much *worse* than cron jobs.  I have cron jobs
>> that I wanted to convert to timer units and discovered I couldn't
>> because timers simply wouldn't work for what I was trying to do.

> Could you give some examples of the issues you discovered with systemd
> timers?

> BTW, we have in systemd-cron a tool for generating systemd units from
> crontab/etc.

MAILTO was the main thing that I remember missing in terms of pure
functionality.

The other problem I can recall wasn't functionality, but was ease of use:
a timer unit can only trigger a service unit, and service units aren't
suitable for doing arbitrary shell scripting.  Here, this wasn't for
packaging but was instead as a local system administrator.  I have a lot
of cases where I drop a simple 20-line shell script into /etc/cron.daily
that has some logic intermixed with variables that list things like, say,
directories to back up to another host.  I looked at replacing that with a
timer unit, just as an experiment, but I would have had to write the timer
unit to control the timing, a separate exec unit that specifies what
command to run, and then put the shell script into yet a third file (with
no particularly obvious location for the local system administrator).
Since I don't like using /usr/local/bin for such things, I'd probably end
up extracting configuration from the script, sticking the script in a
local Debian package, and installing the configuration separately.  I now
have four different files just to replace a single file dropped into a
directory.

Admittedly, this was to replace something run from cron.daily, and maybe
the solution there (if one is considering a system that doesn't need a
separate cron daemon, which in theory should be possible if one wanted to
do it although not necessary of course) would be to have a single timer
unit that uses run-parts the way that cron runs cron.daily.  Timer units
were a closer match for cron.d, although I'm still missing MAILTO.

-- 
Russ Allbery (r...@debian.org)   

Re: Debian Buster release to partially drop non-systemd support

[Jonathan Dowland]

On Wed, Oct 17, 2018 at 08:33:47PM -0700, Russ Allbery wrote:

MAILTO was the main thing that I remember missing in terms of pure
functionality.


This is not a complete substitute for all uses of MAILTO, but I found
the following useful so I share it in case you weren't aware of it.

Define a service specifically designed for sending status emails:

status-email-user@.service:

[Service]
Type=oneshot
ExecStart=-/usr/local/bin/systemd-email %i
User=nobody
Group=systemd-journal


(I also switch on a little status LED I have with another ExecStart
line)

/usr/local/bin/systemd-email:

systemctl status --full "$1" | mail -s "unit $1 failed" root


Put an OnFailure= line in systemd units that you want to mail you if
they go wrong


[Unit]
OnFailure=status-email-user@%n.service


I think I probably got this from the Arch wiki and it suffers many of
the problems you outlined in your follow-on paragraph (needing a
separate unit, to the timer, an external shell script, etc.)

Since I switched to this, I've made the scripts I run on timers much
more verbose in the non-failure case, because I know I am not going
to generate mail. And this has turned out to be a good habit, because
I have a lot of useful information in my journal.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.