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
Hi,
On Sat, Aug 10, 2019 at 11:24:37AM +0200, Marc Haber wrote:
> >But there are other ways. Many traditional daemons can start as root
> >and drop privileges.
> How many lines of code have been replicated all along those daemons,
> how many security relevant bugs in this code did we solve it
On Fr, Aug 09, 2019 at 11:00:03 +0200, Ondřej Surý wrote:
Unprivileged access to port < 1024. The socket-activated services can
start as user since the port binding is done by the systemd, not the
daemon.
If the daemon supports different platforms, it needs a wrapper to bind to
a port <
And add correctly implementing capabiliti on top of that. Also lib cap or
libcap-ng?
Sometimes having more choices isn’t advantage...
Ondřej
--
Ondřej Surý
> On 10 Aug 2019, at 11:24, Marc Haber wrote:
>
> On Fri, 9 Aug 2019 10:27:31 +0100, Ian Jackson
> wrote:
>> But there are other
On Fri, 9 Aug 2019 10:27:31 +0100, Ian Jackson
wrote:
>But there are other ways. Many traditional daemons can start as root
>and drop privileges.
How many lines of code have been replicated all along those daemons,
how many security relevant bugs in this code did we solve it he last
decades and
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.
>>
>> No, we have not.
>
> We have given up on
Ian Jackson - 09.08.19, 11:27:31 CEST:
> Ondřej Surý writes ("Re: Please stop hating on sysvinit"):
> > On 9 Aug 2019, at 09:22, Martin Steigerwald
> > wrote:
> > > Actually as a user of my services I do not even notice any
> > > difference,
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
On dv., ag. 09 2019, Vincent Bernat wrote:
❦ 9 août 2019 09:22 +02, Martin Steigerwald
:
Reality seems different. Almost nothing was using inetd (tftpd
is the
I note that you wrote "seems". But still:
As if there would just be *one* reality. Actually there is. But
I never
saw any
Ondřej Surý writes ("Re: Please stop hating on sysvinit"):
> On 9 Aug 2019, at 09:22, Martin Steigerwald wrote:
> > Actually as a user of my services I do not even notice any difference, so
> > for me it is: What is actually the point of starting them on demand?
>
&
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 9 Aug 2019, at 09:22, Martin Steigerwald wrote:
>
> Actually as a user of my services I do not even notice any difference, so
> for me it is: What is actually the point of starting them on demand?
Unprivileged access to port < 1024. The socket-activated services can start
as user since the
❦ 9 août 2019 09:22 +02, Martin Steigerwald :
>> Reality seems different. Almost nothing was using inetd (tftpd is the
>
> I note that you wrote "seems". But still:
>
> As if there would just be *one* reality. Actually there is. But I never
> saw any human being being able to express it in
Vincent Bernat - 09.08.19, 07:00:41 CEST:
> ❦ 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
❦ 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 do
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
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 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 thrown sysvinit away.
> >
> >No, we have not.
>
>
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 has come with that it
doesn't
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
50 matches
Mail list logo
