Excerpts from John Paul Adrian Glaubitz's message of 2013-06-01 03:52:51 -0700:
> On 06/01/2013 12:24 PM, Vincent Bernat wrote:
> > I don't know how systemd behaves in this way (so this is not something
> > to hold against upstart), but there are so many daemons that need to be
> > started after th
Excerpts from Vincent Bernat's message of 2013-06-01 03:24:02 -0700:
> ❦ 1 juin 2013 00:44 CEST, Steve Langasek :
>
> >> start on (local-filesystems and net-device-up IFACE!=lo)
> >> stop on runlevel [016]
> >
> > FYI, it's strongly recommended to use 'start on runlevel [2345]' here as the
> >
> In that light the memory saving trade off for security and practicality
> actually makes sense as you could save lots and lots of resources on a
> massive server or server farm running hundreds or thousands of server
> systems per machine etc..
Unless someone conjures up a targeted attack (pleas
> Like much of systemd it may seem impressive at first on the face of it
> but actually holds little value or doing what are already optional
> functions and has not been thought through or come from any great
> experience.
It has since occured to me that it was alleged on the Gentoo list that
the
> On Aug 23, 2013, at 8:45 PM, James McCoy wrote:
> >
> >> On Fri, Aug 23, 2013 at 04:42:15PM -0400, John Paul Adrian Glaubitz wrote:
> >> Imagine there is a vulnerability in SSH which has not been fixed
> >> yet for whatever reason. Having SSH run in this situation all the
> >> time would make t
On Fri, 23 Aug 2013, John Paul Adrian Glaubitz wrote:
> No, it's not. It's the only reasonable thing to do. Nothing is safer
> than a daemon which is *not* running. The fewer services are running,
A daemon which is not running but which can be made to run by an
unpriviledged connect() is as good a
On Aug 23, 2013, at 8:45 PM, James McCoy wrote:
>
>> On Fri, Aug 23, 2013 at 04:42:15PM -0400, John Paul Adrian Glaubitz wrote:
>> Imagine there is a vulnerability in SSH which has not been fixed
>> yet for whatever reason. Having SSH run in this situation all the
>> time would make the machine a
On Fri, Aug 23, 2013 at 04:42:15PM -0400, John Paul Adrian Glaubitz wrote:
> Imagine there is a vulnerability in SSH which has not been fixed
> yet for whatever reason. Having SSH run in this situation all the
> time would make the machine a target for possible attacks.
If all I have to do is make
On 08/23/2013 04:02 PM, Kevin Chadwick wrote:
>> There is no point to start a daemon unless you actually
>> need it.
>
> This is complete 'modern' crap
No, it's not. It's the only reasonable thing to do. Nothing is safer
than a daemon which is *not* running. The fewer services are running,
the fe
On 31 May 2013 22:44, Ondřej Surý wrote:
>
> It's pretty much equivalent with one exception – I need to send USR2 on
> reload. Does upstart already have the support for custom reload signals?
>
Upstart 1.10 released today has the following new stanza thus you will
be able to specify:
"reload sign
> There is no point to start a daemon unless you actually
> need it.
This is complete 'modern' crap
If you don't want a service started then why are your starting it,
because you might want it is a stupid argument with next to no
positives. SSH takes a blink of an eye to start.
It is far better
On Sat, Jun 01, 2013 at 12:24:02PM +0200, Vincent Bernat wrote:
> It seems that now, we can do this, but the cookbook also says this is
> not here yet:
>
> start on started network-services
>
> I don't know how systemd behaves in this way (so this is not something
> to hold against upstart), bu
Zygmunt Krynicki wrote:
> W dniu sob, cze 1, 2013 o 12:52 ,nadawca John Paul Adrian Glaubitz
> napisał:
> > On 06/01/2013 12:24 PM, Vincent Bernat wrote:
> > I don't know how systemd behaves in this way (so this is not
> > something to hold against upstart), but there are so many
On 06/01/2013 01:51 PM, Zygmunt Krynicki wrote:
I believe there was a counter example of using CUPS where unless you
really start it, other machines won't discover it via avahi and you
won't be able to print to a networked printer.
One exception does not mean that all daemons should be started
W dniu sob, cze 1, 2013 o 12:52 ,nadawca John Paul Adrian Glaubitz
napisał:
On 06/01/2013 12:24 PM, Vincent Bernat wrote:
I don't know how systemd behaves in this way (so this is not
something
to hold against upstart), but there are so many daemons that need to
be
started after the network
On 06/01/2013 12:24 PM, Vincent Bernat wrote:
I don't know how systemd behaves in this way (so this is not something
to hold against upstart), but there are so many daemons that need to be
started after the network has been configured that it should be easy to
do this. For example, most daemons b
❦ 1 juin 2013 00:44 CEST, Steve Langasek :
>> start on (local-filesystems and net-device-up IFACE!=lo)
>> stop on runlevel [016]
>
> FYI, it's strongly recommended to use 'start on runlevel [2345]' here as the
> start condition, for several reasons:
>
> - The 'filesystem' events are one-time e
On Fri, May 31, 2013 at 11:44:53PM +0200, Ond??ej Surý wrote:
> cat > php5-fpm.service << EOF
> [Unit]
> Description=The PHP FastCGI Process Manager
> After=syslog.target network.target
Small nitpick here: Specifying syslog.target in an After is completely
unnecessary and counterproductive. At the
Hi Ondřej,
On Fri, May 31, 2013 at 11:44:53PM +0200, Ondřej Surý wrote:
> I have tried to rewrite php5-fpm init.d file for systemd and upstart and
> ended up with:
> cat > php5-fpm.service << EOF
> [Unit]
> Description=The PHP FastCGI Process Manager
> After=syslog.target network.target
> [Servi
On 2013-05-31 14:44, Ondřej Surý wrote:
Hi,
I have tried to rewrite php5-fpm init.d file for systemd and upstart
and ended up with:
cat > php5-fpm.service << EOF
[Unit]
Description=The PHP FastCGI Process Manager
After=syslog.target network.target
[Service]
Type=forking
PIDFile=/var/run/php5
20 matches
Mail list logo
