On Wed, 14 Aug 2019 12:04:03 -0400
Brian Reichert wrote:
> On Wed, Aug 14, 2019 at 04:19:46PM +0100, Simon McVittie wrote:
> > On Wed, 14 Aug 2019 at 10:26:53 -0400, Brian Reichert wrote:
> > Doesn't daemonize(1) make stdin, stdout and stderr point
> > to /dev/null, instead of closing them?
>
On Wed, Aug 14, 2019 at 04:19:46PM +0100, Simon McVittie wrote:
> On Wed, 14 Aug 2019 at 10:26:53 -0400, Brian Reichert wrote:
> Doesn't daemonize(1) make stdin, stdout and stderr point to /dev/null,
> instead of closing them?
Looking at the source, yes, it does.
> Expecting arbitrary
On Wed, 14 Aug 2019 at 10:26:53 -0400, Brian Reichert wrote:
> And, if I were to ever use daemonize(1), or any other other canonical
> mechanism for daemonizing code, STDOUT would normally be closed
> under those circumstances, as well.
Doesn't daemonize(1) make stdin, stdout and stderr point to
On Mi, 14.08.19 10:26, Brian Reichert (reich...@numachi.com) wrote:
> On Wed, Aug 14, 2019 at 11:34:21AM +0200, Lennart Poettering wrote:
> > Hence: your code that closes fd1 like this is simply buggy. Don't do
> > that, you are shooting yourself in the foot.
>
> Buggy or no, this is
On Wed, Aug 14, 2019 at 11:34:21AM +0200, Lennart Poettering wrote:
> Hence: your code that closes fd1 like this is simply buggy. Don't do
> that, you are shooting yourself in the foot.
Buggy or no, this is fifteen-year-old code, and prior cron/service
mgmt framework implementations had no issue.
Am 14.08.19 um 14:59 schrieb Ulrich Windl:
Reindl Harald schrieb am 14.08.2019 um 12:22 in
> Nachricht <13150bf2-e0c9-063a-9026-ac95c1fda...@thelounge.net>:
>>
>> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
>> Michael Chapman schrieb am 14.08.2019 um 11:47
>> in
That's all
>>> Reindl Harald schrieb am 14.08.2019 um 12:22 in
Nachricht <13150bf2-e0c9-063a-9026-ac95c1fda...@thelounge.net>:
>
> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
> Michael Chapman schrieb am 14.08.2019 um 11:47 in
>>> That's all true, but the thing we need to check here is that systemd
On Wed, 14 Aug 2019, Lennart Poettering wrote:
> Well, a D-Bus connection can remain open indefinitely, and may even
> have incomplete "half" messages queued in them as long as the client
> desires. After the initial authentication is done, clients may thus
> take up resources as long as they
On Mi, 14.08.19 19:47, Michael Chapman (m...@very.puzzling.org) wrote:
> On Wed, 14 Aug 2019, Lennart Poettering wrote:
> > Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
> > really bad idea in general. That systemctl nowadays is particularly
> > careful and deals with
Am 14.08.19 um 12:48 schrieb Michael Chapman:
> On Wed, 14 Aug 2019, Reindl Harald wrote:
may is ask you to read the thread you are responding to?
nobody is touching the private socket
>>>
>>> systemctl will mostly use /run/systemd/private when run as root
>>
>> that's not the point -
On Wed, 14 Aug 2019, Reindl Harald wrote:
> Am 14.08.19 um 12:41 schrieb Michael Chapman:
> > On Wed, 14 Aug 2019, Reindl Harald wrote:
> >> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
> >> Michael Chapman schrieb am 14.08.2019 um
> >> 11:47 in
> That's all true, but the thing we
Am 14.08.19 um 12:41 schrieb Michael Chapman:
> On Wed, 14 Aug 2019, Reindl Harald wrote:
>> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
>> Michael Chapman schrieb am 14.08.2019 um 11:47
>> in
That's all true, but the thing we need to check here is that systemd
correctly
On Wed, 14 Aug 2019, Reindl Harald wrote:
> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
> Michael Chapman schrieb am 14.08.2019 um 11:47
> in
> >> That's all true, but the thing we need to check here is that systemd
> >> correctly handles junk on the /run/systemd/private socket. The
On Wed, 14 Aug 2019, Ulrich Windl wrote:
> >>> Michael Chapman schrieb am 14.08.2019 um 11:47 in
> Nachricht :
> > On Wed, 14 Aug 2019, Lennart Poettering wrote:
> >> Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
> >> really bad idea in general. That systemctl nowadays is
Am 14.08.19 um 12:10 schrieb Ulrich Windl:
Michael Chapman schrieb am 14.08.2019 um 11:47 in
>> That's all true, but the thing we need to check here is that systemd
>> correctly handles junk on the /run/systemd/private socket. The change on
>> the systemctl side certainly tries to
>>> Michael Chapman schrieb am 14.08.2019 um 11:47 in
Nachricht :
> On Wed, 14 Aug 2019, Lennart Poettering wrote:
>> Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
>> really bad idea in general. That systemctl nowadays is particularly
>> careful and deals with situations
On Wed, 14 Aug 2019, Lennart Poettering wrote:
> Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
> really bad idea in general. That systemctl nowadays is particularly
> careful and deals with situations like that is not an invitation to
> actually invoke things like this.
On Mi, 14.08.19 18:53, Michael Chapman (m...@very.puzzling.org) wrote:
> On Wed, 14 Aug 2019, Michael Chapman wrote:
> > On Wed, 14 Aug 2019, Brian Reichert wrote:
> > > On Thu, Aug 01, 2019 at 07:18:20PM +, Zbigniew J??drzejewski-Szmek
> > > wrote:
> > > > Yes. (With the caveat that there
On Wed, 14 Aug 2019, Michael Chapman wrote:
> On Wed, 14 Aug 2019, Brian Reichert wrote:
> > On Thu, Aug 01, 2019 at 07:18:20PM +, Zbigniew J??drzejewski-Szmek
> > wrote:
> > > Yes. (With the caveat that there *are* legitimate reasons to have new
> > > long-lived fds created, so not every
On Wed, 14 Aug 2019, Brian Reichert wrote:
> On Thu, Aug 01, 2019 at 07:18:20PM +, Zbigniew J??drzejewski-Szmek wrote:
> > Yes. (With the caveat that there *are* legitimate reasons to have new
> > long-lived fds created, so not every long-lived fd is "wrong".)
>
> I finally was able to track
20 matches
Mail list logo