Re: Re: Bug#741930: reportbug: add current init system information

[Steve Langasek]

On Sat, Nov 08, 2014 at 10:15:46AM +, Jonathan de Boyne Pollard wrote:
> There isn't really a reliable way to identify any of these as the current
> running system, and upstart is not checking the running processes either.



>  *  To check for upstart as the running system manager, one checks that
> there's an initctl command and that the output of "initctl version" contains
> the name "upstart" somewhere.  There do exist other initctl commands, aside
> from the one that comes with Upstart. But they don't emit the word
> "upstart".
>  root ~ #initctl version
>  nosh version 1.10
>  root ~ #
> Again, the downside is that this is not checking what's running.  In
> particular, it fails when one has installed Upstart but not yet rebooted in
> order to run it.

This is false. 'initctl version' queries the running upstart over dbus.

>  *  To check for the nosh system-manager, one can do the same "initctl
> version" test as with upstart, and look for "nosh".  Or one can look for the
> /run/system-manager directory.  Both share the weaknesses of the equivalent
> upstart and systemd checks.  initctl isn't present as a command unless one
> has installed the nosh upstart compatibility shims package, and there's no
> guarantee that another initctl won't emit that string any more that there's
> a guarantee that a non-upstart initctl won't emit the string "upstart".

I have never heard of nosh before and it appears to not be in Debian, but
having it implement upstart interfaces (such as the 'initctl' program)
without understanding the semantics of those commands sounds like a pretty
bad idea.

The 'initctl' command, in Debian, is owned by the upstart package.
Implementing something that conflicts with this ownership, and then
asserting that upstart's interfaces are therefore unreliable, is not
appropriate.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Re: Bug#741930: reportbug: add current init system information

[Jonathan de Boyne Pollard]

Sandro Tosi:

what is the recommended way to  identify sysvinit? from the info

> provided above one requires to check a dir existence and the
> checking a command and then execute it to parse its output. it seems
> a bit fragile, and maybe only upstart check really the running
> processes

There isn't really a reliable way to identify any of these as the 
current running system, and upstart is not checking the running 
processes either.


 *  To check for systemd as the running system manager in the 
"official" manner, one checks for the existence of /run/systemd/system 
.  This is a directory, in /run, that systemd itself creates at boot, 
and that other system managers are unlikely to create.  The downside is 
that this check will be fooled if ever someone comes along and 
implements a system that creates these directories for compatibility 
with things that create systemd service units in /run.  I suspect that 
that already is the case for "uselessd" and this test is already broken.


 *  To check for upstart as the running system manager, one checks that 
there's an initctl command and that the output of "initctl version" 
contains the name "upstart" somewhere.  There do exist other initctl 
commands, aside from the one that comes with Upstart. But they don't 
emit the word "upstart".

 root ~ #initctl version
 nosh version 1.10
 root ~ #
Again, the downside is that this is not checking what's running.  
In particular, it fails when one has installed Upstart but not yet 
rebooted in order to run it.


 *  To check for the nosh system-manager, one can do the same "initctl 
version" test as with upstart, and look for "nosh".  Or one can look for 
the /run/system-manager directory.  Both share the weaknesses of the 
equivalent upstart and systemd checks.  initctl isn't present as a 
command unless one has installed the nosh upstart compatibility shims 
package, and there's no guarantee that another initctl won't emit that 
string any more that there's a guarantee that a non-upstart initctl 
won't emit the string "upstart".  And, although there's vanishingly 
small reason to do so, it is possible that something else might create a 
lookalike /run/system-manager directory.  "system-control version" is 
the identical command to "initctl version", however, and that is part of 
the system management package and not a shim.  But on the gripping hand 
this is still a test of the software that is installed and ready to run, 
not of what is currently running.


 *  Ironically, and as people are belatedly discovering, one test for 
System 5 init installed, that is peculiar to Debian, is that no other 
system manager expects the existence of, and no other system management 
toolset Debian package has, the file /etc/inittab . Again, this is not a 
test for System 5 init running.


To check for what system manager is running right now, as opposed to 
what is installed and ready to run, one really has to look at the 
process list or at the various APIs that system managers publish. But 
this isn't wholly without pitfalls.


 *  You've already mentioned the problems with /proc/1/exe .
 *  systemd publishes a whole RPC API over D-Bus, which even contains a 
version name and number; but (a) this isn't covered by the infamous 
"Interface Stability Guarantee" and could change tomorrow or at whim, 
and (b) so too does the lookalike D-Bus server in systemd-shim.

 *  The existence of /run/systemd/private is similarly not guaranteed.
 *  The nosh system-manager doesn't create pipes or sockets in the 
filesystem, and doesn't have an RPC API in the first place.
 *  The nosh service-manager conventionally has an API socket at 
/run/service-manager/control, but one can run the nosh service manager 
under some other system manager; so this doesn't tell one what system 
manager is running as process #1.  In any case, it doesn't set that name 
itself; whatever invoked it does.
 *  The existence of the control API file /dev/initctl isn't specific 
to System 5 init.  systemd has a (non process #1) systemd-initctl server 
that serves this.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545ded52.3040...@ntlworld.com

Re: Bug#741930: reportbug: add current init system information

[Sandro Tosi]

Hello,

On Wed, Nov 5, 2014 at 1:09 AM, Cameron Norman  wrote:
> A few notes I have:
>
> 1. With Jessie and on, with sysvinit /sbin/init //will// be a link,
> not the true init file. This would lead to unknowns when the init was
> actually sysv.

care to explain a bit better? I just upgraded a Wheezy VM to testing
and (except some issues) once I replaced systemd with sysvinit-core
/sbin/init *is* a regular file:

morph@debian:~$ dpkg -l sysvinit-core | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  sysvinit-core  2.88dsf-53.4 amd64System-V-like init utilities
morph@debian:~$ dpkg -S /sbin/init
sysvinit-core: /sbin/init
morph@debian:~$ file /sbin/init
/sbin/init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=0b29c65c4ae879649971cfd1d469ca03421714ff, stripped

> 2. With Upstart, /sbin/init is not a link, so that third test would
> give a false positive for sysvinit when it was actually Upstart
> (assuming the Upstart check gave a false negative).

it should not be a false negative, do you have a situation in mind
where it might happen?

> 3. Maybe you should embed the check for Upstart, so that you do not
> have to source all of the init functions, and if that file is ever not
> available you still get the correct check.

lsb init functions are part of lsb-base, a required package

> 4. There is a tiny typo in the Upstart check. It needs an extra right
> parenthese at the end of the message.

I know I know, I should have probably followed up as i noticed 10
seconds after having sent the email and a lot of people pointed it out
(more of the people actually running the script and report back the
results to me :( ).

Cheers
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAB4XWXzYW9+WeiUaVVTM8C3zr7MONEb6qMOBSr7+O1C2=4f...@mail.gmail.com

Re: Bug#741930: reportbug: add current init system information

[Cameron Norman]

On Tue, Nov 4, 2014 at 5:35 AM, Sandro Tosi  wrote:
> Hi Michael et al,
>
> On Mon, Nov 3, 2014 at 1:19 PM, Michael Biebl  wrote:
>>> provided above one requires to check a dir existence and the checking
>>> a command and then execute it to parse its output. it seems a bit
>>> fragile, and maybe only upstart check really the running processes
>>
>> The systemd system runtime directory is only created when systemd is the
>> active PID 1. Could you elaborate why you think this approach is
>> fragile? If those two tests (for systemd and upstart) would be brittle,
>> we'd have a problem, since they are used all over the place.
>
> well, mkdir can create it too :) but ok, those checks are so embedded
> that i can ignore if the reportbug check if fooled to thing theres
> another systems (there will be bigger problems indeed) so I will just
> mimik their logic in the code; I changed the sample scripts, attached,
> and it would be nice if you all could give it another round (thanks to
> everyone who already did!) in particular to those having an upstart
> init system.

A few notes I have:

1. With Jessie and on, with sysvinit /sbin/init //will// be a link,
not the true init file. This would lead to unknowns when the init was
actually sysv.
2. With Upstart, /sbin/init is not a link, so that third test would
give a false positive for sysvinit when it was actually Upstart
(assuming the Upstart check gave a false negative).
3. Maybe you should embed the check for Upstart, so that you do not
have to source all of the init functions, and if that file is ever not
available you still get the correct check.
4. There is a tiny typo in the Upstart check. It needs an extra right
parenthese at the end of the message.

Cheers,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfr+qngxdby3x+qjwmupeg-9j-jmf5aaou7mdgs-toup...@mail.gmail.com

Re: Bug#741930: reportbug: add current init system information

[Sandro Tosi]

Hi Michael et al,

On Mon, Nov 3, 2014 at 1:19 PM, Michael Biebl  wrote:
>> provided above one requires to check a dir existence and the checking
>> a command and then execute it to parse its output. it seems a bit
>> fragile, and maybe only upstart check really the running processes
>
> The systemd system runtime directory is only created when systemd is the
> active PID 1. Could you elaborate why you think this approach is
> fragile? If those two tests (for systemd and upstart) would be brittle,
> we'd have a problem, since they are used all over the place.

well, mkdir can create it too :) but ok, those checks are so embedded
that i can ignore if the reportbug check if fooled to thing theres
another systems (there will be bigger problems indeed) so I will just
mimik their logic in the code; I changed the sample scripts, attached,
and it would be nice if you all could give it another round (thanks to
everyone who already did!) in particular to those having an upstart
init system.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
import os
import subprocess

init = 'unable to detect'

if os.path.isdir('/run/systemd/system'):
init = 'systemd (via /run/systemd/system)'
if not subprocess.call('. /lib/lsb/init-functions ; init_is_upstart', shell=True):
init = 'upstart (via init_is_upstart()'
elif os.path.isfile('/sbin/init') and not os.path.islink('/sbin/init'):
init = 'sysvinit (via /sbin/init)'

print 'Init: %s' % init

Re: Bug#741930: reportbug: add current init system information

[Sandro Tosi]

On Mon, Nov 3, 2014 at 12:56 PM, Michael Biebl  wrote:
> Am 03.11.2014 um 13:21 schrieb Sandro Tosi:
>> Hello,
>> sorry for resurrecting this post from such a long ago.
>>
>> On Fri, Mar 21, 2014 at 9:19 PM, Sandro Tosi  wrote:
>>> Ok, I think we need a wider audience - what d-d thinks about it? bonus
>>> points if - in case we come out to add init info to every bug report -
>>> a proper way to retrieve the init running is provided :)
>
> Such tests have already been provided in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741930#25
> which reflect the recommendation of the systemd and upstart maintainers.

what is the recommended way to identify sysvinit? from the info
provided above one requires to check a dir existence and the checking
a command and then execute it to parse its output. it seems a bit
fragile, and maybe only upstart check really the running processes

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cab4xwxy8ivs9up-slirukazsy4zumwqzso5lh98k-0umwuw...@mail.gmail.com

Re: Bug#741930: reportbug: add current init system information

[Michael Biebl]

Am 03.11.2014 um 13:21 schrieb Sandro Tosi:
> Hello,
> sorry for resurrecting this post from such a long ago.
> 
> On Fri, Mar 21, 2014 at 9:19 PM, Sandro Tosi  wrote:
>> Ok, I think we need a wider audience - what d-d thinks about it? bonus
>> points if - in case we come out to add init info to every bug report -
>> a proper way to retrieve the init running is provided :)

Such tests have already been provided in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741930#25
which reflect the recommendation of the systemd and upstart maintainers.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#741930: reportbug: add current init system information

[Sandro Tosi]

Hello,
sorry for resurrecting this post from such a long ago.

On Fri, Mar 21, 2014 at 9:19 PM, Sandro Tosi  wrote:
> Ok, I think we need a wider audience - what d-d thinks about it? bonus
> points if - in case we come out to add init info to every bug report -
> a proper way to retrieve the init running is provided :)

Could you try running the attached script on your machines (check the
code first!!) and report in a private email to me the output?
Corrections/comments are welcome to be public either on d-d and/or on
the bug report.

What I want to do is inspecting the running system, instead of relying
on the presence of directories (I will use this latter method if the
first fails).

Thanks,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
from __future__ import with_statement
import os

pid1 = ''
init = '/sbin/init'

try:
with open('/proc/1/cmdline') as f:
pid1 = 'PID 1 is '
# cmdline contains arguments separated by NULL char
init = f.read().split('\x00')[0]
except IOError:
# ignore if the file is not accessible
pass

initsystem = os.readlink(init)

print 'Init: %s%s linked to %s' % (pid1, init, initsystem)

Re: Bug#741930: reportbug: add current init system information

[Matthias Urlichs]

Hi,

Michael Biebl:
> I do think it might be useful information, at least during the
> transition period. We can always revisit this decision in jessie+X, if
> by that time the vast majority is running systemd.
> 
We'd still want that information, if/when the current init is *not* systemd.

Likewise, we might want to suppress the "current shell" line if it's dash.

Personally, though, I tend to disregard that whole block of lines as
mostly-irrelevant for the vast majority of bug reports. If there's
two more lines of useless-to-me text in there, who cares?

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Bug#741930: reportbug: add current init system information

[Michael Biebl]

Am 25.03.2014 17:14, schrieb Russ Allbery:
> Sandro Tosi  writes:
>> On Fri, Mar 21, 2014 at 10:19 PM, Sandro Tosi  wrote:
> 
>>> Ok, I think we need a wider audience - what d-d thinks about it? bonus
>>> points if - in case we come out to add init info to every bug report -
>>> a proper way to retrieve the init running is provided :)
> 
>> could we please stop talking about shell & stuff and concentrate on
>> whether we want the init information in every report or not? thanks :)
> 
> I vote yes, but not in any great detail, just a single line like the
> current information about /bin/sh. 

Nod.

 It is going to at least be potentially
> relevant to any package with an init script plus anything that uses logind
> or the rest of the desktop infrastructure, which is enough packages
> combined that I think it would save effort all around.

I do think it might be useful information, at least during the
transition period. We can always revisit this decision in jessie+X, if
by that time the vast majority is running systemd.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#741930: reportbug: add current init system information

[Russ Allbery]

Sandro Tosi  writes:
> On Fri, Mar 21, 2014 at 10:19 PM, Sandro Tosi  wrote:

>> Ok, I think we need a wider audience - what d-d thinks about it? bonus
>> points if - in case we come out to add init info to every bug report -
>> a proper way to retrieve the init running is provided :)

> could we please stop talking about shell & stuff and concentrate on
> whether we want the init information in every report or not? thanks :)

I vote yes, but not in any great detail, just a single line like the
current information about /bin/sh.  It is going to at least be potentially
relevant to any package with an init script plus anything that uses logind
or the rest of the desktop infrastructure, which is enough packages
combined that I think it would save effort all around.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvm69rwk@windlord.stanford.edu

Re: Bug#741930: reportbug: add current init system information

[Sandro Tosi]

On Fri, Mar 21, 2014 at 10:19 PM, Sandro Tosi  wrote:
> Ok, I think we need a wider audience - what d-d thinks about it? bonus
> points if - in case we come out to add init info to every bug report -
> a proper way to retrieve the init running is provided :)

could we please stop talking about shell & stuff and concentrate on
whether we want the init information in every report or not? thanks :)

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAB4XWXynG0Y7omhiN=mb+gwckfb8jevjr3ijkgzv6x-x0ho...@mail.gmail.com

Re: Bug#741930: reportbug: add current init system information

[brian m. carlson]

On Tue, Mar 25, 2014 at 08:12:06AM +0100, Thomas Weber wrote:
> The fact that a lot of people use a variety of shells does not mean that
> it makes sense to include it in *every* bug report. How important is the
> user's shell for every database-, web- or fileserver? How for every office
> application? How important is it for requests to the release team?
> Every single bug report for these (pseudo)packages will include this
> information, so it better be important.

As Russ pointed out, it's one line.  My suggestion was to avoid people
wasting time troubleshooting when a small bit of information might help.
I know that I prefer having a little extra information than not enough
when trying to fix a bug.

> > It's much better to have this information up front than to have to guess
> > about it, especially since many reporters won't think to mention it.
>
> If you know that your package might break by using a certain shell, you
> can use reportbug's scripts.

I don't think the maintainers even considered whether debconf would be
broken under zsh.  I certainly didn't think it would be, or I wouldn't
have set zsh as /bin/sh.

Also, it doesn't make sense to make hundreds of packages duplicate the
same (or worse, slightly different and potentially subtly broken) code,
when it could be in one single place.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#741930: reportbug: add current init system information

[Russ Allbery]

Thomas Weber  writes:

> The fact that a lot of people use a variety of shells does not mean that
> it makes sense to include it in *every* bug report. How important is the
> user's shell for every database-, web- or fileserver? How for every
> office application? How important is it for requests to the release
> team?  Every single bug report for these (pseudo)packages will include
> this information, so it better be important.

It's potentially important for any bug report involving a package
containing a shell script, if the bug report involves that shell script,
which is hard to determine in advance.  There are shell scripts in just
about every package we have, given that many packages contain maintainer
scripts.  It's also a single line in the bug report, so I'm having a hard
time understanding why people think it's important enough to even debate.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761n2pvy2@windlord.stanford.edu

Re: Bug#741930: reportbug: add current init system information

[Thomas Weber]

On Sun, Mar 23, 2014 at 05:03:00PM +, brian m. carlson wrote:
> On Sun, Mar 23, 2014 at 08:41:48AM +0100, Thomas Weber wrote:
> > And while we are at it, do we *really* need the information about
> > /bin/sh in at least a significant share of today's bug reports?
> 
> You probably want it, because a decent number of people use a shell
> other than bash or dash as /bin/sh.  For example, one might use
> mksh-static because it's statically linked.  Also, someone might try to
> use zsh as /bin/sh, which doesn't work (it breaks debconf).

The fact that a lot of people use a variety of shells does not mean that
it makes sense to include it in *every* bug report. How important is the
user's shell for every database-, web- or fileserver? How for every office
application? How important is it for requests to the release team?
Every single bug report for these (pseudo)packages will include this
information, so it better be important.
 
> It's much better to have this information up front than to have to guess
> about it, especially since many reporters won't think to mention it.

If you know that your package might break by using a certain shell, you
can use reportbug's scripts. 

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140325071206.GA17855@t61

Re: Bug#741930: reportbug: add current init system information

[Andrei POPESCU]

On Du, 23 mar 14, 17:03:00, brian m. carlson wrote:
> On Sun, Mar 23, 2014 at 08:41:48AM +0100, Thomas Weber wrote:
> > And while we are at it, do we *really* need the information about
> > /bin/sh in at least a significant share of today's bug reports?
> 
> You probably want it, because a decent number of people use a shell
> other than bash or dash as /bin/sh.  For example, one might use
> mksh-static because it's statically linked.  Also, someone might try to
> use zsh as /bin/sh, which doesn't work (it breaks debconf).

Wouldn't it make more sense to have that information conditionally, i.e. 
only if /bin/sh is *not* dash?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Bug#741930: reportbug: add current init system information

[brian m. carlson]

On Sun, Mar 23, 2014 at 08:41:48AM +0100, Thomas Weber wrote:
> And while we are at it, do we *really* need the information about
> /bin/sh in at least a significant share of today's bug reports?

You probably want it, because a decent number of people use a shell
other than bash or dash as /bin/sh.  For example, one might use
mksh-static because it's statically linked.  Also, someone might try to
use zsh as /bin/sh, which doesn't work (it breaks debconf).

It's much better to have this information up front than to have to guess
about it, especially since many reporters won't think to mention it.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#741930: reportbug: add current init system information

[Michael Stapelberg]

Hi Thomas,

Thomas Weber  writes:
> And for those packages where it does not matter, it will cost extra
> developer concentration/time in ignoring the noise. Sorry, but this
> feels like being good for some, bad for all others. Developers
> interested in the information should add bug scripts now and if we then
> have the confirmed information that indeed lots of bug reports profit
> from this information, then the change should be pushed to reportbug. 
The problem with your approach (individual packages should add this) is
that it spreads out the work to a lot of maintainers, and a long time
may pass before a new version with the proper bug-script is uploaded. In
addition, to some maintainers it may not even be clear that the init
system is relevant to how their package works.

I think it’s much better to just add this unconditionally to
bugreports.

We also have the Kernel and Locale in bugreports, even though for many
reports it doesn’t matter. For those where it does, it’s very very
useful. I think the same applies to the init system.

-- 
Best regards,
Michael


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/x6r45tl1lr@midna.zekjur.net

Re: Bug#741930: reportbug: add current init system information

[Thomas Weber]

On Sat, Mar 22, 2014 at 02:16:10PM +0100, Thijs Kinkhorst wrote:
> I think it should be in every report. reportbug currently adds the kernel
> version and what /bin/sh points to, and for both of those it can just as
> well be argued that they are not relevant to the majority of bug reports.
> For those bugs where it will matter, it will save wasted developer time in
> extra back and forths, which is the most precious resource we have.

And for those packages where it does not matter, it will cost extra
developer concentration/time in ignoring the noise. Sorry, but this
feels like being good for some, bad for all others. Developers
interested in the information should add bug scripts now and if we then
have the confirmed information that indeed lots of bug reports profit
from this information, then the change should be pushed to reportbug. 

And while we are at it, do we *really* need the information about
/bin/sh in at least a significant share of today's bug reports?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140323074148.GA28868@t61

Re: Bug#741930: reportbug: add current init system information

[Thijs Kinkhorst]

>> On Fri, Mar 21, 2014 at 10:00:12PM +0100, Sandro Tosi wrote:
>>> I thought about it a bit, and i'm not sure it's an information every
>>> bug report should have. I suspect there are few packages which are
>>> directly impacted by the possible different init system Debian has,

I think it should be in every report. reportbug currently adds the kernel
version and what /bin/sh points to, and for both of those it can just as
well be argued that they are not relevant to the majority of bug reports.
For those bugs where it will matter, it will save wasted developer time in
extra back and forths, which is the most precious resource we have.


Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/b2599161678d707e3c81852292f5c817.squir...@aphrodite.kinkhorst.nl

Re: Bug#741930: reportbug: add current init system information

[Michael Biebl]

Am 21.03.2014 22:19, schrieb Sandro Tosi:

> a proper way to retrieve the init running is provided :)> 

- systemd
The canonical check for systemd being PID 1 is
[ -d /run/systemd/system ]
See also man 3 sd_booted and [0]

- upstart
For upstart the canonical check is defined in /lib/lsb/init-functions as
init_is_upstart() which checks for initctl and parses the output of the
"initctl version"



Michael

[0] http://cgit.freedesktop.org/systemd/systemd/commit/?id=66e411811b8090

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#741930: reportbug: add current init system information

[Sandro Tosi]

Ok, I think we need a wider audience - what d-d thinks about it? bonus
points if - in case we come out to add init info to every bug report -
a proper way to retrieve the init running is provided :)

cheers,
Sandro

On Fri, Mar 21, 2014 at 10:15 PM, Yves-Alexis Perez  wrote:
> On Fri, Mar 21, 2014 at 10:00:12PM +0100, Sandro Tosi wrote:
>> Hello Yves-Alexis
>>
>> On Mon, Mar 17, 2014 at 12:00 PM, Yves-Alexis Perez  
>> wrote:
>> > with the appearance of multiple init systems, it might be helpful to
>> > know about the currently running init system in the information
>> > collected by reportbug.
>> >
>> > A quick idea would be to report the result of:
>> >
>> > readlink /proc/1/exe
>> >
>> > but that won't work if /proc is mounted with hidepid. I'm unsure about
>> > other ways though.
>>
>> I thought about it a bit, and i'm not sure it's an information every
>> bug report should have. I suspect there are few packages which are
>> directly impacted by the possible different init system Debian has,
>> and it's probably more useful if such packages write a bugscript to
>> retrieve the init which is running on the machine and attach it to the
>> report.
>>
>> what do you think?
>
> Well, a *lot* stuff can actually change behavior depending on the init
> system, especially during transition time. Especially desktop
> environment and stuff handling permissions through policykit and
> logind/consolekit, but not only.
>
> If every package starts shipping a bugscript it'll be unmanageable.
>
> Regards,
> --
> Yves-Alexis Perez



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cab4xwxygbr2lwmsgdr8xwbdf41gj4ep+_qibfznvl1hd+hz...@mail.gmail.com