Re: systemd - some more considerations
Chow Loong Jin hyperair at debian.org writes: For the record, there's CONFIG_BINFMT_SCRIPT, which when disabled, causes all #! scripts to be run under /bin/sh unconditionally. *everything* runs under /bin/sh, including Perl, Python, and Bash scripts. Yes, and /bin/sh is supposed to parse the shebang and call out to the interpreter. AFAICT, mksh does. That the kernel can also do it is just a shortcut. bye, //mirabilos -- 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/loom.20140404t102614-...@post.gmane.org
Re: systemd - some more considerations
On Fri, Apr 04, 2014 at 08:27:01AM +, Thorsten Glaser wrote: Chow Loong Jin hyperair at debian.org writes: For the record, there's CONFIG_BINFMT_SCRIPT, which when disabled, causes all #! scripts to be run under /bin/sh unconditionally. *everything* runs under /bin/sh, including Perl, Python, and Bash scripts. Yes, and /bin/sh is supposed to parse the shebang and call out to the interpreter. AFAICT, mksh does. That the kernel can also do it is just a shortcut. Are you sure about this? AFAICT this seems to be the exception rather than the rule. Running my Python scripts (with appropriate #!s) through zsh, bash, and dash don't seem to automagically redirect them to Python. Some references would be helpful. I can't seem to find anything on this through some cursory googling. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: systemd - some more considerations
On Fri, Apr 04, 2014 at 08:27:01AM +, Thorsten Glaser wrote: For the record, there's CONFIG_BINFMT_SCRIPT, which when disabled, causes all #! scripts to be run under /bin/sh unconditionally. *everything* runs under /bin/sh, including Perl, Python, and Bash scripts. Yes, and /bin/sh is supposed to parse the shebang and call out to the interpreter. Supposed by whom? -- WBR, wRAR -- 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/20140404095034.gb24...@belkar.wrar.name
Re: systemd - some more considerations
Chow Loong Jin wrote...
Some references would be helpful. I can't seem to find anything on this
through
some cursory googling.
Perl scripts, when installed by ExtUtils::MakeMaker or similar, do
have
| eval 'exec /usr/bin/perl -S $0 ${1+$@}'
| if 0; # not running under some shell
in the very first lines. Yes, it works. However I wasn't aware there
still was a need for that.
Christoph
--
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/1396605...@msgid.manchmal.in-ulm.de
Re: systemd - some more considerations
In other news for Fri, Apr 04, 2014 at 05:24:50PM +0800, Chow Loong Jin has been seen typing: On Fri, Apr 04, 2014 at 08:27:01AM +, Thorsten Glaser wrote: Chow Loong Jin hyperair at debian.org writes: Yes, and /bin/sh is supposed to parse the shebang and call out to the interpreter. AFAICT, mksh does. That the kernel can also do it is just a shortcut. Are you sure about this? AFAICT this seems to be the exception rather than the rule. Running my Python scripts (with appropriate #!s) through zsh, bash, and dash don't seem to automagically redirect them to Python. For myself, I'd *prefer* the latter behavior -- if I explicitly tell bash to parse a script, I want it to assume I have a good reason, and not silently follow a shebang line to execute a different parser altogether. -- Rens Houben |opinions are mine Resident linux guru and sysadmin | if my employers have one Systemec Internet Services. |they'll tell you themselves PGP key at http://proteus.systemec.nl/~shadur/shadur.key.asc -- 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/20140404100415.ga4...@proteus.systemec.nl
shebang (was Re: systemd - some more considerations)
On Fri, 4 Apr 2014, Chow Loong Jin wrote: Are you sure about this? Yes. Some references would be helpful. I can't seem to find anything on this through Sure. I’ve patched mksh to use “#?” ipv “#!” as shebang, to simulate a kernel not supporting the shebang: Index: exec.c === RCS file: /cvs/src/bin/mksh/exec.c,v retrieving revision 1.129 diff -u -p -u -p -r1.129 exec.c --- exec.c 11 Jan 2014 16:26:27 - 1.129 +++ exec.c 4 Apr 2014 09:34:58 - @@ -893,7 +893,7 @@ scriptexec(struct op *tp, const char **a /* restore begin of shebang position (buf+0 or buf+3) */ cp = (unsigned char *)(buf + fd); /* bail out if read error (above) or no shebang */ - if ((cp[0] != '#') || (cp[1] != '!')) + if ((cp[0] != '#') || (cp[1] != '?')) goto noshebang; cp += 2; (Some comment on the side: “buf+0 or buf+3” is because mksh additionally strips an UTF-8 BOM before the shebang. This is beyond standard.) Then I run this: tglase@tglase:~ $ cat x #?/usr/bin/python import sys print sys.version tglase@tglase:~ $ ls -l x -rwxr-xr-x 1 tglase tglase 47 Apr 4 12:54 x tglase@tglase:~ $ ./x import.im6: unable to grab mouse ': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047. sys.version tglase@tglase:~ $ b/mksh tglase@tglase:~ $ ./x 2.7.6 (default, Mar 22 2014, 17:40:27) [GCC 4.8.2] (This is Debian sid/i386 (still waiting for x32, that’s why i386).) some cursory googling. Try duckduckgoïng instead ☻ or searching POSIX, or something. Also, “man mksh” look for EXECSHELL (which is the interpreter the shell uses if the script doesn’t even have a shebang). bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- 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/alpine.deb.2.10.1404041254520.25...@tglase.lan.tarent.de
Re: shebang (was Re: systemd - some more considerations)
On Fri, Apr 04, 2014 at 12:58:23PM +0200, Thorsten Glaser wrote: Are you sure about this? Yes. Some references would be helpful. I can't seem to find anything on this through Sure. I’ve patched mksh mksh doesn't count as a reference. some cursory googling. Try duckduckgoïng instead ☻ or searching POSIX, or something. That's quite helpful. -- WBR, wRAR -- 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/20140404113812.ga27...@belkar.wrar.name
Re: shebang (was Re: systemd - some more considerations)
Hi, Thorsten Glaser t.gla...@tarent.de writes: On Fri, 4 Apr 2014, Chow Loong Jin wrote: Are you sure about this? Yes. Some references would be helpful. I can't seem to find anything on this through Sure. I’ve patched mksh to use “#?” ipv “#!” as shebang, to simulate a kernel not supporting the shebang: [...] Try duckduckgoïng instead ☻ or searching POSIX, or something. I tried and found that POSIX says the shell shall try execve(), and if that fails 'the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of $0 in the new shell may be set to the command name.'[1] No #! involved. [1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_01_01 Furthermore Wikipedia says For this reason and because POSIX does not standardize path names, POSIX does not standardize the feature.[2]. [2] http://en.wikipedia.org/wiki/Shebang_%28Unix%29#Portability I'm interested where POSIX says what you are sure it says (that the shell is responsible for evaluating #!). Also, “man mksh” look for EXECSHELL (which is the interpreter the shell uses if the script doesn’t even have a shebang). I don't think the manual for a not commonly used shell is a good reference... Ansgar -- 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/87ha69xqyj@deep-thought.43-1.org
Re: shebang (was Re: systemd - some more considerations)
* Thorsten Glaser t.gla...@tarent.de, 2014-04-04, 12:58: Try duckduckgoïng instead ☻ or searching POSIX, or something. SUSv4 “helpfully” says: If the first line of a file of shell commands starts with the characters #!, the results are unspecified. -- Jakub Wilk -- 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/20140404114816.ga3...@jwilk.net
Re: shebang (was Re: systemd - some more considerations)
In data venerdì 04 aprile 2014 17.38.12, Andrey Rahmatullin ha scritto: Sure. I’ve patched mksh mksh doesn't count as a reference. Did you even read before replying? He patched it to use #? Instead of #! that was using. He was sure about it being there because he had patched it to behave differently. -- Salvo Tomaselli Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno. -- Galileo Galilei http://ltworf.github.io/ltworf/ -- 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/2629335.D8GMTTWuuY@vulcano
Re: shebang (was Re: systemd - some more considerations)
On Fri, Apr 04, 2014 at 02:04:32PM +0200, Salvo Tomaselli wrote: Sure. I’ve patched mksh mksh doesn't count as a reference. Did you even read before replying? He patched it to use #? Instead of #! that was using. He was sure about it being there because he had patched it to behave differently. And all of that was to prove mksh does something, which cannot be used as an argument about general or standardized behavior, or something. -- WBR, wRAR -- 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/20140404122721.ga29...@belkar.wrar.name
Re: shebang (was Re: systemd - some more considerations)
Hi, Thorsten Glaser: tglase@tglase:~ $ cat x #?/usr/bin/python import sys print sys.version tglase@tglase:~ $ ls -l x -rwxr-xr-x 1 tglase tglase 47 Apr 4 12:54 x tglase@tglase:~ $ ./x import.im6: unable to grab mouse ': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9047. sys.version tglase@tglase:~ $ b/mksh tglase@tglase:~ $ ./x 2.7.6 (default, Mar 22 2014, 17:40:27) [GCC 4.8.2] This just says that mksh handles #! scripts like no other shell. Doesn't mean that it's a good (or bad) idea. In fact, I wonder whether anything would break if we removed the ability to run shebang-less scripts from our shells. Currently, they do this: * bash opens the script and interprets it * ash dash immediately execve() /bin/sh with the script * mksh obviously opens the file and tries to read the #! line, which seems pointless because the kernel already did this. This gets interesting if you point the #! line to something which is not an executable. * ash bash dash obviously behave as if the #! line was not there and interpret the script. * mksh reports the ENOEXEC. I actually like that. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: systemd - some more considerations
El Wed, 2 de Apr 2014 a las 7:12 PM, Norbert Preining prein...@logic.at escribió: Hi recent discussions on lkml really made me rethink the systemd position. How is it possible that: * systemd maintainers (Kay Sievers) considers an obvious bug in his code that locks out users something not in need to be cared for? https://bugs.freedesktop.org/show_bug.cgi?id=76935 * systemd maintainers (Lennart Poettering) does not care for segfaults in his code, even if it happens in pid 1. https://bugs.freedesktop.org/show_bug.cgi?id=74589 * several kernel maintainer propose (not completely serious, but it shows the general opinion), to add + BUG_ON(!strcmp(current-comm, systemd)); Is this the upstream Debian wants to base its life on? Scary scary scary. Norbert This really is not something suitable for debian-devel, unless you are actually proposing a GR to re-choose the init system, which you do not seem to be doing. I also do not like systemd's method of development and maintenance, as well as a few design decisions, so I am working on Upstart support in Debian. If you are interested in helping, please get in touch. Alternatively, you could work on OpenRC, or even Epoch init. Best Regards, -- Cameron Norman
Re: systemd - some more considerations
Hi, Norbert Preining: How is it possible that: * systemd maintainers (Kay Sievers) considers an obvious bug in his code that locks out users something not in need to be cared for? https://bugs.freedesktop.org/show_bug.cgi?id=76935 It's not an obvious bug, it's primarily an issue of interpreting whether a generic boot parameter like debug is intended for just the kernel, or the whole system. Linux has other programs (and a few kernel modules) whose equivalent of verbose=999 will prevent them from working. That's not new. The question is essentially whether requiring systemd.log_target=null (to exclude systemd's debug output from the kernel log buffer) is reasonable. If the maintainer regards this as a design issue which thus should not be discussed in a bug report, that's their prerogative. Calling Kai a d*ck over it (see comment#11) is not going to help. I have no sympathy whatsover for people who complain about the systemd team's hostility when *they* are the one who start the badmouthing. * systemd maintainers (Lennart Poettering) does not care for segfaults in his code, even if it happens in pid 1. https://bugs.freedesktop.org/show_bug.cgi?id=74589 Oh come on. It's a nontrivial amount of work to reproduce that bug. Does not care for is not at all the same as is not willing to spend the effort on something that's not one of his use cases and wants somebody else to provide a patch. Does not care for would be is unwilling to accept a patch for this problem. That's not what's happening. * several kernel maintainer propose (not completely serious, but it shows the general opinion), to add + BUG_ON(!strcmp(current-comm, systemd)); URLs please. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: systemd - some more considerations
]] Norbert Preining Hi recent discussions on lkml really made me rethink the systemd position. How is it possible that: * systemd maintainers (Kay Sievers) considers an obvious bug in his code that locks out users something not in need to be cared for? https://bugs.freedesktop.org/show_bug.cgi?id=76935 That's being moved to systemd.debug instead of overloading debug. * systemd maintainers (Lennart Poettering) does not care for segfaults in his code, even if it happens in pid 1. https://bugs.freedesktop.org/show_bug.cgi?id=74589 systemd needs cgroups, that's pretty well established. Arguably, it should die with a clearer message. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87d2gyixug@xoog.err.no
Re: systemd - some more considerations
On Thu, Apr 03, 2014 at 11:12:12AM +0900, Norbert Preining wrote: Is this the upstream Debian wants to base its life on? According to the technical committee, and the lack of support for the GR, the answer is yes. If you don't like this answer, please put effort into doing the work to provide a viable alternative, rather than bringing this issue up yet again. I, for one, consider this issue/decision to be closed already. Nothing productive will come by revisiting this. Neil -- signature.asc Description: Digital signature
Re: systemd - some more considerations
Hi Tollef, On Thu, 03 Apr 2014, Tollef Fog Heen wrote: https://bugs.freedesktop.org/show_bug.cgi?id=76935 That's being moved to systemd.debug instead of overloading debug. Good news. And please make Kay excuse for his rudeness and ifgnorance. Thanks for letting us know. But why is that not mentioned in the bug report? What is systemd maintainers approach to handling bugs?? * systemd maintainers (Lennart Poettering) does not care for segfaults in his code, even if it happens in pid 1. https://bugs.freedesktop.org/show_bug.cgi?id=74589 systemd needs cgroups, that's pretty well established. Arguably, it should die with a clearer message. No, NO NOO *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that. All the best Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- 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/20140403093342.gg17...@auth.logic.tuwien.ac.at
Re: systemd - some more considerations
Hi, On Thu, 03 Apr 2014, Matthias Urlichs wrote: https://bugs.freedesktop.org/show_bug.cgi?id=76935 It's not an obvious bug, it's primarily an issue of interpreting whether a generic boot parameter like debug is intended for just the kernel, or the whole system. Linux has other programs (and a few kernel modules) whose equivalent of verbose=999 will prevent them from working. That's not new. The question is Besides, they are not PID 1 don't divert attention. If the maintainer regards this as a design issue which thus should not be discussed in a bug report, that's their prerogative. Calling Kai a d*ck over it (see comment#11) is not going to help. That is *exactely* the attitude that is dangerous. You are breaking a system, or many system, but you consider it a design issue that has to be discussed. (you being systemd devs, in particular Kay) See Linus response, and get back to reality https://lkml.org/lkml/2014/4/2/420 I have no sympathy whatsover for people who complain about the systemd team's hostility when *they* are the one who start the badmouthing. WHAT? Did *you* read the bug report. The OP suggested several improvements and discussions, and *only* after Kay refused to show even a *wink* of *understanding*, several of the posters got angry at the ignorance of Kay. Who on earth is the bummer guy here? Please *read* the bug report and before coming to completely wrong and false conclusions. * systemd maintainers (Lennart Poettering) does not care for segfaults in his code, even if it happens in pid 1. https://bugs.freedesktop.org/show_bug.cgi?id=74589 Oh come on. It's a nontrivial amount of work to reproduce that bug. What??? Compiling a kernel with CONFIG_CGROUPS=n is *nontrivial* amount of work. You have a twisted impression of reality. If foobar is developing a program for PID 1 that interacts so tightly with the kernel, I *expect* that developer to have not one, but *many* kernel running and testing at any point in time. * several kernel maintainer propose (not completely serious, but it shows the general opinion), to add + BUG_ON(!strcmp(current-comm, systemd)); URLs please. Ugg, https://lkml.org/lkml/2014/4/2/422 and follow ups. I thought that has proliferated into the farest corners of the internet by now. Followups supporting this idea, of course not 100% serious, unfortunately. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- 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/20140403093508.gh17...@auth.logic.tuwien.ac.at
Re: systemd - some more considerations
On Thu, Apr 03, 2014 at 10:41:45AM +0200, Matthias Urlichs wrote: Hi, [...] * several kernel maintainer propose (not completely serious, but it shows the general opinion), to add + BUG_ON(!strcmp(current-comm, systemd)); URLs please. http://marc.info/?l=linux-kernelm=139646548927947w=2 -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: systemd - some more considerations
Hi, On Thu, Apr 03, 2014 at 05:41:21AM -0007, Cameron Norman wrote: This really is not something suitable for debian-devel, unless you are actually proposing a GR to re-choose the init system, which you do not seem to be doing. GRs are also off-topic on -devel. 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/20140403094247.ga17...@raptor.chemicalconnection.dyndns.org
Re: systemd - some more considerations
Hi, On Thu, Apr 03, 2014 at 10:41:45AM +0200, Matthias Urlichs wrote: Norbert Preining: * several kernel maintainer propose (not completely serious, but it shows the general opinion), to add + BUG_ON(!strcmp(current-comm, systemd)); URLs please. IIRC that's from Andrew Morton in reply to point #1 above. 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/20140403094410.gb17...@raptor.chemicalconnection.dyndns.org
Re: systemd - some more considerations
]] Norbert Preining Hi Tollef, On Thu, 03 Apr 2014, Tollef Fog Heen wrote: https://bugs.freedesktop.org/show_bug.cgi?id=76935 That's being moved to systemd.debug instead of overloading debug. Good news. And please make Kay excuse for his rudeness and ifgnorance. Why on earth would I do that? I'm not going to spend time and effort on something like that. Thanks for letting us know. But why is that not mentioned in the bug report? What is systemd maintainers approach to handling bugs?? It's discussed on the development mailing list. * systemd maintainers (Lennart Poettering) does not care for segfaults in his code, even if it happens in pid 1. https://bugs.freedesktop.org/show_bug.cgi?id=74589 systemd needs cgroups, that's pretty well established. Arguably, it should die with a clearer message. No, NO NOO *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that. Am I understanding you correctly that you don't think there are any situations where compiling out features from the kernel can lead to pid1 not working would be acceptable? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/874n2aivk6@xoog.err.no
Re: systemd - some more considerations
Hi Norbert et al., * systemd maintainers (Lennart Poettering) does not care for segfaults in his code, even if it happens in pid 1. https://bugs.freedesktop.org/show_bug.cgi?id=74589 to me his response does not read as if he didn't care. Systemd on systems without cgroups has never been a supported configuration and is thus not one that he will ever test, so he asks for a patch: To make this work we'd need a patch, as nobody of us tests this Nothing exceptional, IMHO. - Fabian -- 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/1396518843.6930.6.ca...@kff50.ghi.rwth-aachen.de
Re: systemd - some more considerations
On Thu, Apr 03, 2014 at 06:33:42PM +0900, Norbert Preining wrote: Hi Tollef, On Thu, 03 Apr 2014, Tollef Fog Heen wrote: https://bugs.freedesktop.org/show_bug.cgi?id=76935 That's being moved to systemd.debug instead of overloading debug. Good news. And please make Kay excuse for his rudeness and ifgnorance. Thanks for letting us know. But why is that not mentioned in the bug report? What is systemd maintainers approach to handling bugs?? * systemd maintainers (Lennart Poettering) does not care for segfaults in his code, even if it happens in pid 1. https://bugs.freedesktop.org/show_bug.cgi?id=74589 systemd needs cgroups, that's pretty well established. Arguably, it should die with a clearer message. No, NO NOO *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that. You could very well say the same thing about a 64-bit kernel dying on a 32-bit system. SystemD depends on Linux precisely because of its cgroups integration. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: systemd - some more considerations
Tollef Fog Heen tfh...@err.no writes: ]] Norbert Preining systemd needs cgroups, that's pretty well established. Arguably, it should die with a clearer message. No, NO NOO *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that. Am I understanding you correctly that you don't think there are any situations where compiling out features from the kernel can lead to pid1 not working would be acceptable? The main problem is how you resolve the not working. Dying will never a sane way to give up from pid 1. Try exec'ing something else instead, like a shell or a stripped down init not needing all those optional kernel fatures. And wrt the question about required kernel feaures: Why should the systemd pid1 require more features than other init systems? I have been told before when complaining about putting additional complexity into pid1 that this isn't true - that systemd really doesn't add dependencies to pid1 compared to alternative init systems. This doesn't seem to be completely true. Bjørn -- 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/877g768yhm@nemi.mork.no
Re: systemd - some more considerations
On 04/03/2014 05:58 PM, Tollef Fog Heen wrote: Am I understanding you correctly that you don't think there are any situations where compiling out features from the kernel can lead to pid1 not working would be acceptable? I'd say the opposite way. Could you please explain in which case you find it acceptable to *just crash*, and render the system completely unusable, and possibly even not recoverable?!? Even without cgroup support, the way to handle the situation, IMO, would be to at least fall back to the shell with a comprehensive error message. 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/533d4c20.7090...@debian.org
Re: systemd - some more considerations
]] Bjørn Mork Tollef Fog Heen tfh...@err.no writes: ]] Norbert Preining systemd needs cgroups, that's pretty well established. Arguably, it should die with a clearer message. No, NO NOO *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that. Am I understanding you correctly that you don't think there are any situations where compiling out features from the kernel can lead to pid1 not working would be acceptable? The main problem is how you resolve the not working. Dying will never a sane way to give up from pid 1. Try exec'ing something else instead, like a shell or a stripped down init not needing all those optional kernel fatures. You're right that «how to resolve» is one part of the question. It's not clear that execing a shell will fare you any better. Virtual consoles and serial ports are optional kernel features too, after all. And wrt the question about required kernel feaures: Why should the systemd pid1 require more features than other init systems? I have been told before when complaining about putting additional complexity into pid1 that this isn't true - that systemd really doesn't add dependencies to pid1 compared to alternative init systems. This doesn't seem to be completely true. I'm not particularly interested in reiterating the entire discussion here, I'm sure you'll find answers to why systemd requires the features it does in #727708, git commit logs and mailing list archives. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87r45eh7l5@xoog.err.no
Re: systemd - some more considerations
]] Thomas Goirand On 04/03/2014 05:58 PM, Tollef Fog Heen wrote: Am I understanding you correctly that you don't think there are any situations where compiling out features from the kernel can lead to pid1 not working would be acceptable? I'd say the opposite way. Could you please explain in which case you find it acceptable to *just crash*, and render the system completely unusable, and possibly even not recoverable?!? I don't believe I have said that. «die» is not the same as «crash». -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87vbuqh7sg@xoog.err.no
Re: systemd - some more considerations
Hi, Tollef Fog Heen: I don't believe I have said that. «die» is not the same as «crash». If you're talking about PID1, the end result is the same. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: systemd - some more considerations
On Thu, 2014-04-03 at 19:55 +0800, Thomas Goirand wrote: On 04/03/2014 05:58 PM, Tollef Fog Heen wrote: Am I understanding you correctly that you don't think there are any situations where compiling out features from the kernel can lead to pid1 not working would be acceptable? I'd say the opposite way. Could you please explain in which case you find it acceptable to *just crash*, and render the system completely unusable, and possibly even not recoverable? 1. If the kernel is configured without a driver for the disk controller, that happens. 2. If the kernel is configured without the filesystem for the root partition, that happens. 3. If the kernel is configured without VT or block support, that probably happens. 4. If the kernel is configured without networking support, the system may boot but if it's a server it's unusable. etc. (I've had boot failures due to several of the above configuration errors, while doing kernel development and trying to use a minimal config.) If cgroups are essential for init, why is this so different from any of the above? Even without cgroup support, the way to handle the situation, IMO, would be to at least fall back to the shell with a comprehensive error message. That would be better, though not much better. You'll need either local access or a remote serial console either to use the shell or to select a fallback entry at the GRUB menu. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Re: systemd - some more considerations
On Thu, 03 Apr 2014 16:39:29 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2014-04-03 at 19:55 +0800, Thomas Goirand wrote: On 04/03/2014 05:58 PM, Tollef Fog Heen wrote: Am I understanding you correctly that you don't think there are any situations where compiling out features from the kernel can lead to pid1 not working would be acceptable? I'd say the opposite way. Could you please explain in which case you find it acceptable to *just crash*, and render the system completely unusable, and possibly even not recoverable? 1. If the kernel is configured without a driver for the disk controller, that happens. It says unable to mount root fs, which indicates what's going wrong. 2. If the kernel is configured without the filesystem for the root partition, that happens. It says unable to mount root fs, which indicates what's going wrong. 3. If the kernel is configured without VT or block support, that probably happens. It says unable to mount root fs, which indicates what's going wrong. 4. If the kernel is configured without networking support, the system may boot but if it's a server it's unusable. It comes up, one can log in on the console, one can debug and will find out fast what's going on. If cgroups are essential for init, why is this so different from any of the above? From what one reads in this thread, init segfaults if cgroups is not available. This is unacceptable. IMO, it would be just fine if it would say kernel support for cgroups not found and die. Even without cgroup support, the way to handle the situation, IMO, would be to at least fall back to the shell with a comprehensive error message. That would be better, though not much better. You'll need either local access or a remote serial console either to use the shell or to select a fallback entry at the GRUB menu. A segfault will lead the debugging process in a totally false direction. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- 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/e1wvkqs-dj...@swivel.zugschlus.de
Re: systemd - some more considerations
On Thu, Apr 03, 2014 at 10:26:22AM +0100, Neil McGovern wrote: On Thu, Apr 03, 2014 at 11:12:12AM +0900, Norbert Preining wrote: Is this the upstream Debian wants to base its life on? According to the technical committee, and the lack of support for the GR, the answer is yes. The GR that was proposed was not about reversing the choice of default. In any case, the only conclusion we can draw from the lack of GR is that developers have chosen not to have a GR to override the TC. If you don't like this answer, please put effort into doing the work to provide a viable alternative, rather than bringing this issue up yet again. There absolutely are viable alternatives, regardless of which one the TC happened to choose in a split decision. This our way is the right way attitude from systemd is nothing new (cf. non-Linux portability) and should not be surprising to anyone involved; and was a significant reason why I voted upstart above systemd at the TC. But as far as I'm concerned, this kerfuffle is too little, too late. Maybe if kernel upstream developers have such strong opinions on the choice of init system, they should have engaged in the discussions with the distros *before* everyone settled on systemd. The avalanche has already started; it is too late for the pebbles to vote. -- 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: systemd - some more considerations
On Thu, Apr 03, 2014 at 06:23:36PM +0200, Marc Haber wrote: I'd say the opposite way. Could you please explain in which case you find it acceptable to *just crash*, and render the system completely unusable, and possibly even not recoverable? 1. If the kernel is configured without a driver for the disk controller, that happens. It says unable to mount root fs, which indicates what's going wrong. 2. If the kernel is configured without the filesystem for the root partition, that happens. It says unable to mount root fs, which indicates what's going wrong. 3. If the kernel is configured without VT or block support, that probably happens. It says unable to mount root fs, which indicates what's going wrong. 4. If the kernel is configured without networking support, the system may boot but if it's a server it's unusable. It comes up, one can log in on the console, one can debug and will find out fast what's going on. If cgroups are essential for init, why is this so different from any of the above? From what one reads in this thread, init segfaults if cgroups is not available. This is unacceptable. IMO, it would be just fine if it would say kernel support for cgroups not found and die. https://lists.debian.org/87d2gyixug@xoog.err.no -- WBR, wRAR signature.asc Description: Digital signature
Re: systemd - some more considerations
previously on this list Matthias Urlichs contributed: I don't believe I have said that. «die» is not the same as «crash». If you're talking about PID1, the end result is the same. It is not because one is a foreseen issue and the other indicates a lack of polish on PID1! -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- 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/199497.53700...@smtp120.mail.ir2.yahoo.com
Re: systemd - some more considerations
previously on this list Steve Langasek contributed: The avalanche has already started; it is too late for the pebbles to vote. Winston Churchill said It is never too late a few times and I think some of his quotes are quite fitting. A lie gets halfway around the world before the truth has a chance to get its pants on. Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing has happened. You have enemies? Good. That means you´ve stood up for something, sometime in your life. It has been said that democracy is the worst form of government except all the others that have been tried. Never give in-never, never, never, never, in nothing great or small, large or petty, never give in except to convictions of honour and good sense. Never yield to force; never yield to the apparently overwhelming might of the enemy. And one that's funny to lighten the mood. Lady Astor: Winston, if I were your wife I´d put poison in your coffee. Winston Churchill: Nancy, if I were your husband I´d drink it. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- 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/679110.53700...@smtp120.mail.ir2.yahoo.com
Re: systemd - some more considerations
On Thu, Apr 03, 2014 at 11:58:17AM +0200, Tollef Fog Heen wrote: [...] Am I understanding you correctly that you don't think there are any situations where compiling out features from the kernel can lead to pid1 not working would be acceptable? For the record, there's CONFIG_BINFMT_SCRIPT, which when disabled, causes all #! scripts to be run under /bin/sh unconditionally. *everything* runs under /bin/sh, including Perl, Python, and Bash scripts. sysvinit as pid1 still works, sure, but everything else doesn't, and you won't even finish booting without that option set. -- Kind regards, Loong Jin signature.asc Description: Digital signature
systemd - some more considerations
Hi recent discussions on lkml really made me rethink the systemd position. How is it possible that: * systemd maintainers (Kay Sievers) considers an obvious bug in his code that locks out users something not in need to be cared for? https://bugs.freedesktop.org/show_bug.cgi?id=76935 * systemd maintainers (Lennart Poettering) does not care for segfaults in his code, even if it happens in pid 1. https://bugs.freedesktop.org/show_bug.cgi?id=74589 * several kernel maintainer propose (not completely serious, but it shows the general opinion), to add + BUG_ON(!strcmp(current-comm, systemd)); Is this the upstream Debian wants to base its life on? Scary scary scary. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- 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/20140403021212.gr17...@auth.logic.tuwien.ac.at
