On 8/20/2019 8:02 AM, Bjørn Mork wrote:
> Bernd Zeimetz writes:
>> On 8/11/19 12:01 PM, Adam Borowski wrote:
>>> restart|force-reload)
>>> log_daemon_msg "Restarting $DESC"
>>> do_stop
>>> sleep 1
>>> do_start
>>> log_end_msg $?
>>> ;;
>>>
>>>
Bernd Zeimetz writes:
> On 8/11/19 12:01 PM, Adam Borowski wrote:
>> restart|force-reload)
>> log_daemon_msg "Restarting $DESC"
>> do_stop
>> sleep 1
>> do_start
>> log_end_msg $?
>> ;;
>>
>> Yes, this particular case might fail on a
On 8/11/19 12:01 PM, Adam Borowski wrote:
> restart|force-reload)
> log_daemon_msg "Restarting $DESC"
> do_stop
> sleep 1
> do_start
> log_end_msg $?
> ;;
>
> Yes, this particular case might fail on a pathologically loaded box or with a
> very
On Sun, 11 Aug 2019 10:49:57 +0200, Vincent Bernat
wrote:
>systemd cannot guess if a SysV init script should leave a daemon behind
>or not. Therefore, they are converted as "Type=forking", "Restart=no"
>"GuessMainPID=no" and "RemainAfterExit=yes". So, when a daemon stops
>unexpectedly, it is not
On Sun, 11 Aug 2019, Adam Borowski wrote:
> A SysV init script being naturally a script makes hacking in fixes
> much easier, both for the admin and maintainer. For example,
> restarting connman with systemd means no wifi unless you restart twice
> (or stop, wait, start), this works with sysvinit:
On Sun, Aug 11, 2019 at 10:49:57AM +0200, Vincent Bernat wrote:
> ❦ 11 août 2019 10:27 +02, Marc Haber :
> > We have, however, failed to make use of that. "systemctl restart" is
> > nearly useless in Debian because a non-negligible part of our daemon
> > packages make systemd think the daemon is
❦ 11 août 2019 10:27 +02, Marc Haber :
>>* Better restart semantics and monitoring of services/ways to configure
>> restart.
>
> We have, however, failed to make use of that. "systemctl restart" is
> nearly useless in Debian because a non-negligible part of our daemon
> packages make systemd
On Sat, 10 Aug 2019 19:41:59 -0400, Sam Hartman
wrote:
>I'm one of the people who has found systemd hugely valuable in server
>environments.
So am I, but I see a bunch of shortcomings.
>Things I've found valuable include:
>
>* Avoiding imperative languages for configuration
This makes using
Hi.
I'm one of the people who has found systemd hugely valuable in server
environments.
Things I've found valuable include:
* Avoiding imperative languages for configuration
* Better configuration of security isolation
* Better restart semantics and monitoring of services/ways to configure
Simon Richter writes:
> What I'm not happy with is that we have effectively incorporated systemd
> unit files as an interface into Debian Policy without *explicitly* doing
> so, and that this interface remains "defined by upstream".
> If that is what we want, then we should update Debian
Hi,
On Fri, Aug 09, 2019 at 02:54:55PM +0100, Simon McVittie wrote:
> To a large extent, the design of units and service files *is* systemd.
This is a large part of the systemd criticism as well: the refusal to
commit to an API because it would hinder future development, while at the
same time
On 09.08.19 12:06, Ansgar wrote:
>
> Having sysvinit might make things a bit easier for Hurd/kFreeBSD, but
> it's not an absolute requirement for such a port to exist.
>
> Ansgar
>
Thanks Ansgar, this is the user deep in me - i like things to easy as
possible. More verbose: I will apply all
On 09.08.19 15:51, Tomas Pospisek wrote:
>
> FWIW (I mean it, this is just anecdotical evidence): I have been
> recently upgrading a lot of containers and host and I have been unable
> to make lxc guest with systemd inits even start.
>
> Also, I have been having problems with ssh sessions taking
On 2019-08-09 07:00:41 +0200 (+0200), Vincent Bernat wrote:
> ❦ 8 août 2019 21:47 +02, Simon Richter :
>
> >> inetd performance is very low because it needs to spawn one instance for
> >> each connection. systemd socket activation has absolutely 0 overhead
> >> except on the first connection
On Fri, 09 Aug 2019 at 17:12:17 +0800, Benda Xu wrote:
> Simon Richter writes:
> > For that to happen, we'd have to define .service files as an API
> > though, which would feature-freeze them, and I'm not sure the systemd
> > people would be happy about that.
>
> Thank you for sharing your
Am 07.08.19 um 19:00 schrieb Marc Haber:
> On Wed, 7 Aug 2019 14:44:01 +0100, Ian Jackson
> wrote:
>> Marc Haber writes ("Re: do packages depend on lexical order or
>> {daily,weekly,monthly} cron jobs?"):
>>> We have already thrown sysvinit away.
>>
Alf Gaida writes:
> We need sysvinit for some non-linux things
No: Hurd existed for a long time without using sysvinit/sysv-rc. I
think sysvinit was only ported to Hurd in 2013 or 2014 (I didn't search
much, but found a Summer of Code application from 2013 for this).
Having sysvinit might make
Dear Simon,
Simon Richter writes:
> The sanest thing we could do in Debian is to teach start-stop-daemon
> to parse systemd .service files and pull its command line arguments
> from there, so we could use service definitions as init scripts with a
> #! line.
>
> For that to happen, we'd have to
On 8/7/19 4:14 AM, Marc Haber wrote:
Imo, there should be a possibility in a systemd timer to switch on the
"old" output-to-e-mail behavior. This is probably something that
systemd upstream would never implement, so we'd end up with a wrapper
that is called by the systemd timer unit.
You can
❦ 8 août 2019 21:47 +02, Simon Richter :
>> inetd performance is very low because it needs to spawn one instance for
>> each connection. systemd socket activation has absolutely 0 overhead
>> except on the first connection (where systemd needs to start the
>> service).
>
> If you specify "wait"
Russ Allbery - 08.08.19, 20:33:58 CEST:
> Ondřej Surý writes:
> > So, just to clarify… so, it’s ok to hate systemd, but it’s not ok
> > to
> > hate sysvinit (spaghetti of shell scripts)?
>
> Personally, I'd be happy if people would just stop hating on any free
> software in general. Even buggy
On Thu, Aug 08, 2019 at 01:08:41PM -0700, Russ Allbery wrote:
Simon Richter writes:
In the same way, we could have had automatic restart of services through
sysvinit easily: an include mechanism that allows additional inittab
lines to be pulled from /etc/inittab.d/* would be trivial to
Simon Richter writes:
> In the same way, we could have had automatic restart of services through
> sysvinit easily: an include mechanism that allows additional inittab
> lines to be pulled from /etc/inittab.d/* would be trivial to
> implement. That it hasn't been done is not because no one has
Hi,
On Thu, Aug 08, 2019 at 08:15:29PM +0200, Vincent Bernat wrote:
> inetd performance is very low because it needs to spawn one instance for
> each connection. systemd socket activation has absolutely 0 overhead
> except on the first connection (where systemd needs to start the
> service).
If
I pretty much agree with everything you just said.
O.
--
Ondřej Surý
> On 8 Aug 2019, at 20:34, Russ Allbery wrote:
>
> Ondřej Surý writes:
>
>> So, just to clarify… so, it’s ok to hate systemd, but it’s not ok to
>> hate sysvinit (spaghetti of shell scripts)?
>
> Personally, I'd be
Ondřej Surý writes:
> So, just to clarify… so, it’s ok to hate systemd, but it’s not ok to
> hate sysvinit (spaghetti of shell scripts)?
Personally, I'd be happy if people would just stop hating on any free
software in general. Even buggy free software is someone's effort,
released into the
❦ 8 août 2019 19:10 +02, Simon Richter :
> For servers, the benefit is rather limited. There is no local user who
> makes system-wide policy decisions, and hardware is not changing
> dynamically either. The actual services provided are either implemented as
> daemons (i.e. not microservices),
On Thu, 8 Aug 2019 19:10:42 +0200
Simon Richter wrote:
> For servers, the benefit is rather limited. There is no local user who
i don't agree - systemd just work™ in the most cases. Without changing
a bit.
> The "desktop" and "server" use cases are so vastly different that it
> doesn't make sense
Hi,
On Thu, Aug 08, 2019 at 02:48:48PM +0200, Philipp Kern wrote:
> As a lot of the conflict between sysvinit and systemd was about the
> philosophy.
I wouldn't say "philosophy". These are different technical designs, and
each design has certain capabilities and limitations. It is not possible
Philipp Kern - 08.08.19, 14:48:48 CEST:
> On 2019-08-08 14:43, Holger Levsen wrote:
> > On Thu, Aug 08, 2019 at 02:35:13PM +0200, Ondřej Surý wrote:
> >> And there’s the problem. If we keep with sysvinit as a baseline of
> >> features provided by the init, we end up with just every init
> >>
On Thu, Aug 08, 2019 at 02:48:48PM +0200, Philipp Kern wrote:
[...]
> That's also to some degree why I think a solution to this problem is for the
> init diversity folks to figure out and we should not block on that. And that
> seems fine given the scope they have set for themselves.
I agree
On 2019-08-08 14:43, Holger Levsen wrote:
On Thu, Aug 08, 2019 at 02:35:13PM +0200, Ondřej Surý wrote:
And there’s the problem. If we keep with sysvinit as a baseline of
features provided by the init, we end up with just every init script
having something like this: [...]
it seems several
On Thu, Aug 08, 2019 at 02:35:13PM +0200, Ondřej Surý wrote:
> And there’s the problem. If we keep with sysvinit as a baseline of
> features provided by the init, we end up with just every init script
> having something like this: [...]
it seems several people in this thread have missed the
> On 8 Aug 2019, at 14:08, Philipp Kern wrote:
>
> On 2019-08-08 13:47, Ondřej Surý wrote:
>>> Please stop hating on sysvinit
>> So, just to clarify… so, it’s ok to hate systemd, but it’s not ok to
>> hate sysvinit (spaghetti of shell scripts)?
>
> I don't think that's a constructive line of
On 2019-08-08 13:47, Ondřej Surý wrote:
Please stop hating on sysvinit
So, just to clarify… so, it’s ok to hate systemd, but it’s not ok to
hate sysvinit (spaghetti of shell scripts)?
I don't think that's a constructive line of argument. At the same time
it's not a race to the bottom in
On Thu, 2019-08-08 at 13:47 +0200, Ondřej Surý wrote:
> So, just to clarify… so, it’s ok to hate systemd, but it’s
> not ok to hate sysvinit (spaghetti of shell scripts)?
>
One has a spaghetti of shell scripts, the other has a kimchi of log
commands and hidden config files.
I think "out of
> Please stop hating on sysvinit
So, just to clarify… so, it’s ok to hate systemd, but it’s not ok to hate
sysvinit (spaghetti of shell scripts)?
O.
--
Ondřej Surý
ond...@sury.org
> On 7 Aug 2019, at 15:44, Ian Jackson wrote:
>
> Marc Haber writes ("Re: do packages depend
On 07.08.19 19:00, Marc Haber wrote:
> Marc, who is trying to have neutral view on systemd and has managed to
> be seen as a fanboi by systemd haters and as a hater by the systemd
> community, and now fully expects the CoC to be used to be silenced
Marc, i don't hope so - you are not alone.
On 2019-08-07 18:51, Jeremy Stanley wrote:
On 2019-08-07 10:19:00 +0200 (+0200), Marc Haber wrote:
On Mon, 05 Aug 2019 22:29:41 +0200, Philipp Kern wrote:
[...]
> I'd still expect a Cloud/Compute provider to offer default
> images in any case that could be preconfigured appropriately.
I am
On Wed, Aug 07, 2019 at 07:00:36PM +0200, Marc Haber wrote:
> On Wed, 7 Aug 2019 14:44:01 +0100, Ian Jackson
> wrote:
> >Marc Haber writes ("Re: do packages depend on lexical order or
> >{daily,weekly,monthly} cron jobs?"):
> >> We have already thr
On Wed, 7 Aug 2019 14:44:01 +0100, Ian Jackson
wrote:
>Marc Haber writes ("Re: do packages depend on lexical order or
>{daily,weekly,monthly} cron jobs?"):
>> We have already thrown sysvinit away.
>
>No, we have not.
We have given up on so many ideas that sysvinit h
On 2019-08-07 10:19:00 +0200 (+0200), Marc Haber wrote:
> On Mon, 05 Aug 2019 22:29:41 +0200, Philipp Kern wrote:
[...]
> > I'd still expect a Cloud/Compute provider to offer default
> > images in any case that could be preconfigured appropriately.
>
> I am one of those customers who almost never
Marc Haber writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> We have already thrown sysvinit away.
No, we have not.
https://tracker.debian.org/pkg/sysvinit
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sysvinit#_2_4_5
https://tracker.d
Simon McVittie writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> Trying to make this point more clearly because you seem to be confusing
> systemd with systemd-cron:
You are completely right. I was not aware that systemd-cron was not
On Mon, 05 Aug 2019 22:29:41 +0200, Philipp Kern
wrote:
>With a systemd timer you can declare conflicts as well as a
>lineralization if so needed.
How would that be configured? Should all timers generated from
cron.fooly be grouped together (in a target?) and conflict with that
very target?
>I
On Mon, 5 Aug 2019 16:34:18 +0100, Ian Jackson
wrote:
>So it seems to me that there are the following options for systemd
>users:
>
>A. Continue to use run-parts.
>
> Disadvantages: Bundles the output together.
> Doesn't provide individual status.
>
> Advantages: No work needed.
>
>B. Run
On Tue, Aug 06, 2019 at 05:19:14PM +0200, Philipp Kern wrote:
> On 2019-08-06 13:43, Bill Allombert wrote:
> > On Mon, Aug 05, 2019 at 10:29:41PM +0200, Philipp Kern wrote:
> > > And finally, the load spikes: Upthread it was mentioned that
> > > RandomizedDelaySec exists. Generally this should be
> "Ian" == Ian Jackson writes:
I think this is the big question.
Because of modern thinking about power optimization, if I were designing
this interface today I'd design it to be concurrent.
In particular, you want to use as much concurrency as you can to
maximize utilization of CPU and IO
On Tue, 06 Aug 2019 at 16:58:31 +0100, Ian Jackson wrote:
> The Debian systemd maintainers are of course free to enable
> parallelism for systemd users;
Trying to make this point more clearly because you seem to be confusing
systemd with systemd-cron:
Whether to run cron jobs in lexical order or
Philipp Kern writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> On 2019-08-05 17:34, Ian Jackson wrote:
> > With current code the options are:
> >
> > A. Things run in series but with concatenated output and no individual
&g
On 2019-08-06 13:43, Bill Allombert wrote:
On Mon, Aug 05, 2019 at 10:29:41PM +0200, Philipp Kern wrote:
And finally, the load spikes: Upthread it was mentioned that
RandomizedDelaySec exists. Generally this should be sufficient to even
out
such effects. I understand that there is a case
On Mon, Aug 05, 2019 at 10:29:41PM +0200, Philipp Kern wrote:
> And finally, the load spikes: Upthread it was mentioned that
> RandomizedDelaySec exists. Generally this should be sufficient to even out
> such effects. I understand that there is a case where you run a lot of
> unrelated VMs that
On 2019-08-05 17:34, Ian Jackson wrote:
With current code the options are:
A. Things run in series but with concatenated output and no individual
status.
B. Things run in parallel, giving load spikes and possible concurrency
bugs; vs.
I can see few people who would choose (B).
People
Marc Haber writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> On Mon, 29 Jul 2019 18:42:34 +0100, Simon McVittie
> wrote:
> >On Wed, 24 Jul 2019 at 20:14:22 +0200, Marc Haber wrote:
> >> Scripts with such dependenci
On Mon, 29 Jul 2019 18:42:34 +0100, Simon McVittie
wrote:
>On Wed, 24 Jul 2019 at 20:14:22 +0200, Marc Haber wrote:
>> Scripts with such dependencies will probably fail miserably on systems
>> that are using systemd-cron instead of one of the "classic" cron
>> packaes
>
>I thought so too, but
On Mon, Jul 29, 2019 at 06:36:00PM +0100, Simon McVittie wrote:
> On Mon, 29 Jul 2019 at 18:26:22 +0100, Simon McVittie wrote:
> > Another reason to break them up is that if the same package installs
> > both a cron script like /etc/cron.daily/man-db and a systemd unit like
> >
On Wed, 24 Jul 2019 at 20:14:22 +0200, Marc Haber wrote:
> Scripts with such dependencies will probably fail miserably on systems
> that are using systemd-cron instead of one of the "classic" cron
> packaes
I thought so too, but they don't: systemd-cron uses run-parts for
cron.{hourly,etc.} too.
On Mon, 29 Jul 2019 at 18:26:22 +0100, Simon McVittie wrote:
> On Sun, 28 Jul 2019 at 14:07:59 +0100, Ian Jackson wrote:
> > Why can't systemd run cron.fooly as one big timer job rather than one
> > timer job for each script ?
>
> Of course it could, but perhaps it shouldn't.
>
> To avoid
On Sun, 28 Jul 2019 at 14:07:59 +0100, Ian Jackson wrote:
> Why can't systemd run cron.fooly as one big timer job rather than one
> timer job for each script ?
Of course it could, but perhaps it shouldn't.
To avoid ambiguity, this is not a systemd design decision: it's a design
decision of
On 2019-07-28 15:07, Ian Jackson wrote:
Marc Haber writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
On Sat, 27 Jul 2019 19:02:16 +0100, Ian Jackson
>I worry about additional concurrency. Unlike ordering bugs,
>concurrency bugs are hard to
Marc Haber writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> On Sat, 27 Jul 2019 19:02:16 +0100, Ian Jackson
> >I worry about additional concurrency. Unlike ordering bugs,
> >concurrency bugs are hard to find by testing. So
On 7/28/19 8:47 AM, Marc Haber wrote:
> Setting RandomizeDelaySecs sufficiently high on our daily jobs would
> probably help to chop off the load pike that especially virtualization
> setups running many Debian instances suffer from at 06:25 or 07:35. I
> think this could be a net gain worth
On Sat, 27 Jul 2019 19:02:16 +0100, Ian Jackson
wrote:
>Marc Haber writes ("do packages depend on lexical order or
>{daily,weekly,monthly} cron jobs?"):
>> Do you people know about packages that have cron jobs that depend on
>> execution order? Would it probably be a
Marc Haber writes ("do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> I am wondering whether there are packages that actually do depend on
> that and how do find out short of unpacking the entire archive and
> inspecting the scripts.
My feeling is
Hi,
since cron uses run-parts to execute the scripts from
/etc/cron.{daily,weekly,monthly}, and run-parts is documented to
execute the contents from the directory in lexical sort-order,
packages could theoretically depend on a certain execution order of
cron jobs and fail miserably if the order
65 matches
Mail list logo
