On Sun, 10 Aug 2014, Russ Allbery wrote:
> To take a step back, I think this is a fair summary of the discussion.
> Please let me know if you disagree:
...
I agree to all points. It is a fair summary.
> I think you've convinced me that the approach of stopping a socket by the
> same name when s
Sorry about the delay in responding.
Henrique de Moraes Holschuh writes:
> Large time outs can cause bad side-efects on surprising ways. If the
> socket is down, you get an immediate connection refused reply, which
> short-circuits the time out.
> As this is a generic feature, we could be talk
On Sat, Aug 2, 2014 at 8:53 PM, Chris Bannister
wrote:
>
> [snip]
>
> Is there a reason debian-user is subscribed to this bug report?
Please don't top-post.
Probably because it's a debian-user@ thread that resulted in the the
bug report and we were added to the cc as a (thoughtful) courtesy.
-
Is there a reason debian-user is subscribed to this bug report?
On Sat, Aug 02, 2014 at 10:42:38AM -0700, Russ Allbery wrote:
> Jonathan de Boyne Pollard
> writes:
[snip]
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people w
On Sat, 02 Aug 2014, Russ Allbery wrote:
> Henrique de Moraes Holschuh writes:
> > Services being subject to a package update can be down for extended
> > amounts of time (think package update that requires manual intervention,
> > or even a full manual reconfiguration, etc), or may actually invol
Henrique de Moraes Holschuh writes:
> Services being subject to a package update can be down for extended
> amounts of time (think package update that requires manual intervention,
> or even a full manual reconfiguration, etc), or may actually involve an
> ABI break. In both cases, you want that
On Sat, 02 Aug 2014, Russ Allbery wrote:
> Jonathan de Boyne Pollard
> writes:
> > And bugs #734766 and #734848 tell one the answer, which is that in order
> > to preserve its existing conceptual model that there is just the one
> > thing (named simply "acpid") invoke-rc.d should pull out the "soc
Jonathan de Boyne Pollard
writes:
> And bugs #734766 and #734848 tell one the answer, which is that in order
> to preserve its existing conceptual model that there is just the one
> thing (named simply "acpid") invoke-rc.d should pull out the "socket"
> from the "service" by looking for a "Trigge
ZH> $ sudo systemctl stop acpid
ZH> Job for acpid.service canceled.
... because, as noted, it's a socket-activated service, which actually
makes it two separately startable and stoppable things
("acpid.service" and "acpid.socket") in the world of systemd, only one
of which is being stopped when yo
Bug #736258 reopened, set to severity grave, and reassigned to systemd for
further processing and action.
Full explanation added to the bug report and CC'd to the bug report and to
the systemd maintainers.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and i
Hi
Am 26.07.2014 19:44, schrieb Henrique de Moraes Holschuh:
> Since just about everything in a "modern desktop" will pester the acpi
> netlink socket, please ask a systemd expert whether "systemctl stop"
> *blocks* socket activation of that service until further notice, or not.
> If it doesn't
On Sat, 26 Jul 2014, Zenaan Harkness wrote:
> Interrelated problem A:
> $ ps aux|egrep -i acpid
> root 318 0.0 0.0 0 0 ?S< 12:40 0:00 [ktpacpid]
> root 19855 0.0 0.0 4372 972 ?Ss 17:45 0:00
> /usr/sbin/acpid
> $ sudo systemctl stop acpid
> Job for
Debian sid
acpid | 1:2.0.22-3
Interrelated problem A:
$ ps aux|egrep -i acpid
root 318 0.0 0.0 0 0 ?S< 12:40 0:00 [ktpacpid]
root 19855 0.0 0.0 4372 972 ?Ss 17:45 0:00 /usr/sbin/acpid
$ sudo systemctl stop acpid
Job for acpid.service canceled.
$
13 matches
Mail list logo
