[Pkg-sysvinit-devel] Bug#862217: Bug#862217: initscript does fsck on empty floppy drive and stops booting
On Tue, 09 May 2017, David Lawyer wrote: > My PC has a floppy drive which I seldom use. When I boot linux, it runs > /etc/init.d/checkfs.sh which runs fsck.fat on the floppy drive > /dev/fd0. The fsck fails because there is no floppy in the drive and ... > Linux should not try to run fsck on a floppy drive at boottime, unless > perhaps if it's booting from floppy and the boot fails. I'm booting from > my harddrive. ... > Here's my /etc/fstab file: > # /etc/fstab: static file system information for 80GB Maxtor. > # > # > LABEL=80GB-Maxtor /ext4defaults0 1 > LABEL=80GB-Maxtor-swp noneswapsw0 0 > /dev/cdrom /home/dave/cd iso9660 rw,noauto,user 0 2 > LABEL=8GB-Maxtor /bak ext4rw,noauto,user,exec 0 > 2 > /dev/fd0 /home/dave/fd vfatrw,noauto,user,noexec, 0 > 1 Please change that last line in /etc/fstab to: /dev/fd0 /home/dave/fd vfat rw,noauto,user,noexec 0 0 (i.e. that last "1" needs to be "0"). After updating /etc/fstab, please regenerate the initramfs just in case. As root: update-initramfs -u Then reboot to test the changes, without a floppy inserted. It should not attempt to fsck /dev/fd0. -- Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#851427: Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
On Sat, 14 Jan 2017, Holger Levsen wrote: > On Sat, Jan 14, 2017 at 09:50:43PM +, Holger Levsen wrote: > > and /dev/shm is owned by root:root and has perms 1755? > > actually I have both 1777 and 0755 here, which of the two is correct or > are both fine?? It has to be mode 01777, read+write. Otherwise, it breaks glibc's shm_* and SuS/POSIX compliance, and you get to keep the pieces of everthing that will fail in both subtle, and very non-subtle ways. Such as Google Chrome / chromium. -- Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#826214: Bug#826215: Bug #826214: Bug #826215: init-d-script and systemd: solution
Maintainer scripts (postinst, postrm, etc) in packages are to always use invoke-rc.d, exceptions are almost always a package bug. Even when using systemd. The naming is unfortunate, yes. But users and admins are to use service, and never invoke-rc.d. And the systemd glue in invoke-rc.d is currently broken that it fails to, by default, also stop related socket units, thus ensuring chaos if activated midway during the unpack/configure steps. A bug is already open about it, but stalled. -- Henrique de Moraes Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Bug#826215: Bug #826214: Bug #826215: init-d-script and systemd: solution
On Thu, Dec 29, 2016, at 10:59, Petter Reinholdtsen wrote: > [Martin Pitt] > > "service", not invoke-rc.d, but I do agree that it would be better to Maintainer scripts (postinst, postrm, etc) in packages are to always use invoke-rc.d, exceptions are almost always a package bug. Even when using systemd. The naming is unfortunate, yes. But users and admins are to use service, and never invoke-rc.d. And the systemd glue in invoke-rc.d is currently broken that it fails to, by default, also stop related socket units, thus ensuring chaos if activated midway during the unpack/configure steps. A bug is already open about it, but stalled. -- Henrique de Moraes Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#848121: Bug#848121: File conflict between manpages and initscripts
On Wed, 14 Dec 2016, Ian Jackson wrote:
> Michael Kerrisk (man-pages) writes ("Re: Bug#848121: [Pkg-sysvinit-devel]
> File conflict between manpages and initscripts"):
> > On 14 December 2016 at 16:45, Ian Jackson
> > wrote:
> > > - rename the manpage about /etc/default/tmpfs to tmnfs-config(5)
> > >(or something, better name welcome).
> >
> > FWIW, I think this may be the best option.
>
> I do see that the arguments against changing all the filesystem
> manpages are pretty strong.
>
> It's not quite clear to me quite who the maintainers of the sysvinit
> package are - ie, who needs to agree. I have been following the
Consider this a vote for the use of tmpfs-config(5) in initscripts,
since tmpfs(5) will require "apropos tmpfs" anyway to find it.
Actually, in hindsight, that /etc/default/tmpfs config file was a bad
idea. It should have always been "either override in /etc/fstab or
stick with the defaults".
> (Actually, I should ask to become a member of the team... done.)
Already approved.
--
Henrique Holschuh
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#823680: Bug#823680: systemd + unbound + resolvconf + squid3 == boot hangs: systemctl reload run on inactive service without --no-block
On Sat, 07 May 2016, Helmut Grohne wrote: > I argue that invoke-rc.d changed API. Formerly (with sysv) reloading a > service that isn't started would generally do nothing (or fail). In any > case, one generally wouldn't expect a reload operation to finish before > the invoke-rc.d call returns (as it often just sends a signal). With > systemd that changes to blocking. This behaviour change is unexpected > and can break system boot. > > Marco d'Itri recommeded adding --no-block to the systemctl invocation. > What do you think? Agreed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Adopting Sysvinit
On Sun, 06 Mar 2016, Petter Reinholdtsen wrote: > Hi. I would be happy for skilled people with more time to take over the > maintenance. I would be happy to help with the knowledge I got, but > lack the time required to do a good job maintaining the sysvinit, > insserv and startpar package. Same here. In fact, I've not had the time to properly setup the environment required for pre-upload QA on sysvinit for a *long* time, so I was always in an "advisory" mode anyway. > > It seems Ben's mail didn't make it to the maintainers' mailing list. I'm > > going to poke a few people individually now. > > I just approved them. Thanks. Simon Richter's request for project access arrived after you did your approval run, apparently. I have just approved him. While approving Simon, I noticed we use "junior" developer as the non-admin role level (I initially thought we used "senior" developer). Just to make it clear, there are no differences at all between the junior and senior developer roles in the pkg-sysvinit alioth project. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#777113: Bug#777113: Followup NMU [was: invoke-rc.d, service under systemd: Avoid job dependency loops during boot/shutdown]
On Wed, May 20, 2015, at 02:50, Martin Pitt wrote: > I would like to do a followup NMU with that before the new version > hits testing, as it can break stuff pretty severely. I suggest you file a RC bug ASAP, so that the broken packages cannot migrate to testing. Then, ready, test and upload the NMU closing the RC bug, without the need to rush things ;-) > Sorry about that! You stuck around to fix what got broken, and did it fast. There is nothing to apologise for. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#777113: Bug#777113: invoke-rc.d, service under systemd: Avoid job dependency loops during boot/shutdown
On Tue, May 12, 2015, at 04:09, Martin Pitt wrote: > Martin Pitt [2015-02-15 16:43 +0100]: > > + * service, invoke-rc.d: Avoid deadlocks during bootup and shutdown from > > +units/hooks which call "invoke-rc.d service reload" and similar, since > > the > > +synchronous wait plus systemd's normal behaviour of transactionally > > +processing all dependencies first easily causes dependency loops. Thus > > +during boot/shutdown operate only on the unit and not on its > > dependencies, > > +just like SysV behaves. > > Can we please apply this patch now? It already missed jessie :-/ We do > have some workarounds in systemd, but they can't cover all cases. We can still fix it in jessie, provided enough testing is done to be acceptable by the stable release managers. So, step one is to get this in unstable, then testing, and test it throughoutly. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#784567: Bug#784567: intent to NMU sysvinit really soon
On Tue, May 12, 2015, at 06:38, Andreas Henriksson wrote: > As Martin Pitt already mentioned in Bug#777113, I'm echoing here my > intention to NMU sysvinit. My changes (previously posted on mailing > lists / bugs) now pushed to the collab-maint repo: > > http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?id=4974842b73ddc3417c9e79f33399f673e3e58c48 > http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?id=a067f2dd75fef1aeadd1ff880876b7e46a48c9f8 > http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?id=1b7d726b201b1ea522daadd92ac9eeb317f3 > http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?id=2abc7031f4a4b6f00a285ec630c9dbcfcc15a26b > > Please scream ASAP if you spot any problems or would like to abort the > non-maintainer upload which will be executed really soon (likely this > weekend). I didn't notice any errors, but I am away from any suitably instrumented Debian box with a jessie/sid chroot ATM to test it myself. My main worry would be a multi-package update run (which includes sysvinit and util-linux, as well as other packages that have initscripts) where something needed by invoke-rc.d, update-rc.d or an initscript is missing at the time dpkg is running maintainer scripts. Other than that, it is just a matter of running this NMU through the usual tests (piuparts, install/remove/upgrade packages with initscripts, and a boot, reboot and shutdown test using VMs). I assume you already did that testing? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Anyone here working on a new sysvinit upload?
On Tue, May 12, 2015, at 04:29, Petter Reinholdtsen wrote: > I suspect there are no active maintainer of sysvinit at the moment, but > thought it was best to ask here on the list before concluding. Do any > of you see yourself as the active maintainer of sysvinit? > > I've retired from sysvinit, and do not plan to step up again, but > thought it best to try to document the state for everyone to know. I am currently unable to be more than a backup maintainer, and that situation is not likely to change in the next couple months :( -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#705254: Bug#705254: Provide "is-enabled" command for update-rc.d
On Mon, Apr 27, 2015, at 13:19, Borut Mrak wrote: > I'm working on update-rc.d to add this feature (got bitten by this using saltstack service states on Jessie w/ systemd). > > I simplified Michael's idea a little bit (I think). > > Instead of checking if links correspond to Default-Start + Default-Stop, i'm just checking if there are all the Default-Start links available. > > For is-disabled I'm only checking that there are no S links present in Default-Start runlevels. > > IMO, no links == disabled (I know they get recreated on upgrades, but that is out of scope for this feature). > This is a problem. The sysv-rc model requires you to actually look at the symlinks to know whether a service is enabled/disabled, the LSB headers are more like the metadata which stores "default/upstream recommended/initially-configured state", as well as dependency information. I.e. the LSB headers do NOT matter at all for sysv-rc (the thing that actually runs the initscripts): they are not in any way related to how the system will behave. They're ancillary metadata which is used by update-rc.d (plus startpar for dependency handling) when setting up the symlink farm. Admins are expected, and *do* interact with sysv-rc through the symlink farm without editing the LSB headers. Can you change this to actually look for the presence of S/K symlinks? Beware the way S/K symlinks are used on runlevels 0 and 6, as it could cause some confusion (I hope there is no need for special casing, but this needs to be carefully considered). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#780364: Bug#780364: The problem disappeared, when I removed /etc/adjtime file and rebooted
On Thu, 12 Mar 2015, wzabo...@elektron.elka.pw.edu.pl wrote: > I have deleted the /etc/adjtime in the affected machine and rebooted it. > After that it boots correctly, without a delay caused by the "future > superblock write time". > However I don't understand what was the real cause of the problem... /etc/adjtime has two relevant fields. One tells whether the RTC is in UTC or local time, and the other has its systematic drift. Both can, if wrong, result in some system tools changing the system time backwards if they're called during boot. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#775912: Bug#775912: update-rc.d is slow due to useless fadvise call
On Wed, 21 Jan 2015, Bolesław Tokarski wrote:
> When update-rc.d is invoked (be it as part of some service installation or
> manually), on some machines it takes much more time than anticipated. Example:
>
> # time update-rc.d apache2 defaults
> ...
> real5m23.611s
> user0m0.092s
> sys 0m0.088s
>
> Running an strace -f on the update-rc.d process showed that the biggest
> slowdowns are during fadvise64 WILLNEED system call. This system call is
> supposed to be asynchronous, should let the system know that it can prefetch
> the scripts, and return immediately.
>
> Unfortunately, this is not the case:
> https://groups.google.com/forum/#!topic/fa.linux.kernel/6jyLWFKQqQ8
With which kernel and arch have you run your tests?
And how did a small read-ahead request ended up taking five *minutes* on
your system? Is it that badly IO-starved?
> Below is the patch that solves the issue. On machines with 5min+ prior run,
> it
> now takes 0.1s. Other machines did not incur any change in time this
> execution
> took. I have tested and confirmed this on both Squeeze and Wheezy. I have a
Because it was never supposed to take 5 minutes in the first place...
> --- insserv-1.14.0.orig/insserv.c
> +++ insserv-1.14.0/insserv.c
> @@ -1823,7 +1823,7 @@ static void scan_script_locations(const
> continue;
> }
>
> - lsb = scan_script_defaults(dfd, d->d_name, override_path, &name,
> true, ignore);
> + lsb = scan_script_defaults(dfd, d->d_name, override_path, &name,
> false, ignore);
> if (!name) {
> warn("warning: script is corrupt or invalid: %s/%s%s\n",
> path,
> rcd, d->d_name);
> continue;
> @@ -2627,7 +2627,7 @@ int main (int argc, char *argv[])
> const char *const name = argv[c];
> service_t * first = (service_t*)0;
> char * provides, * begin, * token;
> - const uchar lsb = scan_script_defaults(dfd, name, override_path,
> (char**)0, true, ignore);
> + const uchar lsb = scan_script_defaults(dfd, name, override_path,
> (char**)0, false, ignore);
>
> if ((lsb & FOUND_LSB_HEADER) == 0) {
> if ((lsb & (FOUND_LSB_DEFAULT|FOUND_LSB_OVERRIDE)) == 0)
I don't mind the patch, but it would be nice to understand the problem
better, first. Maybe we can disable the fadvise selectively...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#763869: Bug#763869: sysvinit-utils: sulogin segfault after `cannot open password database!`
On Sun, 04 Jan 2015, Paul Menzel wrote: > > Not sure if it will make it into Jessie. It do not seem important > > enough to try to push it past the freeze. > > Under certain circumstances it does not allow to get into the > maintenance shell, which is a real problem for systems still using SysV > instead of systemd I believe. systemd just tries to continue with > booting where SysV just hangs, doesn’t it? Yes. The bug is important enough that a fix warrants a freeze exception *request*, and if that doesn't get approved (because it reflects on the installer), a stable update as soon as pratical. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#763869: Bug#763869: Bug#763869: sysvinit-utils: sulogin segfault after `cannot open password database!`
On Fri, 26 Dec 2014, Petter Reinholdtsen wrote: > Great. The patch need to be moved to debian/patches/, but otherwise > look good. I hope someone with access to collab-maint can push a fix. > Not sure if it will make it into Jessie. It do not seem important > enough to try to push it past the freeze. We can simply push it through stable-proposed-updates once jessie is released. All that is required is heavy testing. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2
On Mon, 15 Dec 2014, Tollef Fog Heen wrote: > ]] Henrique de Moraes Holschuh > > On Thu, 11 Dec 2014, Gerrit Pape wrote: > > > On Tue, Dec 09, 2014 at 11:24:11AM +, Gerrit Pape wrote: > > > > On Mon, Nov 24, 2014 at 10:08:49PM +, Simon McVittie wrote: > > > > > On 24/11/14 21:41, Gerrit Pape wrote: > > > > > > Better than (2) would be to make the existence of /etc/inittab still > > > > > > essential for jessie, by moving the corresponding code from > > > > > > sysvinit-core into the essential init package. What do you think? > > > > > > > > > > If you go this route, I think initscripts might be a better home for > > > > > > > > As I wrote above, I actually don't have the time to go any road at all. > > > > > > > > The packages worked just fine until I learnt that support for the > > > > inittab interface is dropped in jessie. I fixed the packages. Now I > > > > learnt that the existence of /etc/inittab is no longer essential, next > > > > thing breaking my packages - when switching jessie to sysvinit. > > > > > > > > Please advise whether I should reassign this release critically to the > > > > init and sysvinit packages, or upload the ugly workaround to copy > > > > sysvinit maintainer script code for generating /etc/inittab into the two > > > > affected packages. > > > > > > Hi init and sysvinit maintainers, it looks like I don't get reasonable > > > advise on debian-devel. > > > > > > What is your stand on this? > > > > You *are* allowed to create /etc/inittab when it is missing. > > .. but only if it wasn't removed by the sysadmin. Admin changes must be > preserved, including removal. /etc/inittab is untracked, which is a shame but fixing it *at this point in the release schedule* is not going to be fun. I suppose the package could offer to create it instead of just doing it, and that might be a convenient middle-ground right now, though. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#763869: Bug#763869: sysvinit-utils: sulogin segfault after `cannot open password database!`
On Tue, 16 Dec 2014, Paul Menzel wrote: > Note: The sleep of two seconds is also questionable. Unfortunately there > is no comment explaining what the reason for it is. IMHO, we should never mess with sleep(some seconds) in this kind of utility. IME, they're almost always security devices: Either they ensure the message can be seen, or throttle down what would become a runaway process otherwise in some failure modes, or throttle down repeated attempts at breaking the password... But yes, a comment would have been really nice... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2
On Thu, 11 Dec 2014, Gerrit Pape wrote: > On Tue, Dec 09, 2014 at 11:24:11AM +, Gerrit Pape wrote: > > On Mon, Nov 24, 2014 at 10:08:49PM +, Simon McVittie wrote: > > > On 24/11/14 21:41, Gerrit Pape wrote: > > > > Better than (2) would be to make the existence of /etc/inittab still > > > > essential for jessie, by moving the corresponding code from > > > > sysvinit-core into the essential init package. What do you think? > > > > > > If you go this route, I think initscripts might be a better home for > > > > As I wrote above, I actually don't have the time to go any road at all. > > > > The packages worked just fine until I learnt that support for the > > inittab interface is dropped in jessie. I fixed the packages. Now I > > learnt that the existence of /etc/inittab is no longer essential, next > > thing breaking my packages - when switching jessie to sysvinit. > > > > Please advise whether I should reassign this release critically to the > > init and sysvinit packages, or upload the ugly workaround to copy > > sysvinit maintainer script code for generating /etc/inittab into the two > > affected packages. > > Hi init and sysvinit maintainers, it looks like I don't get reasonable > advise on debian-devel. > > What is your stand on this? You *are* allowed to create /etc/inittab when it is missing. Especially if you're creating it exactly like sysvinit would do it, which means the system will not become unusable if the user attempts to switch to something that needs /etc/inittab to run initscripts or to start getty-like terminal handling. If *that* is the only thing getting in the way, I don't see any problems. We should fix it better later, though, it is not a good idea to have code to generate /etc/inittab in several packages in the long run: they will eventually diverge. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#601757: Bug#601757: Bug#601757: Please mount cgroup automatically
On Tue, 11 Nov 2014, Raphael Hertzog wrote: > On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote: > > 1. Is it *safe* and *undeniably always correct* to mount the cgroupfs in > >that mountpoint, with the mount options used in the patch? > > > >This answer needs only to take jessie into account. But it does > >need to consider jessie's cgmanager and systemd at the very least, > >not just lxc. > > > > 2. How does it play with jessie's systemd and cgmanager (I hope the answer > >is: it doesn't cause any issues). > > I don't know the answers to those questions and the bug is now much less > relevant to me given that something else (likely systemd) does mount it > automatically for me, so I'm not going to spend time investigating your > questions. That's perfectly understandable. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#601757: Bug#601757: Bug#601757: Please mount cgroup automatically
On Wed, 03 Aug 2011, Raphael Hertzog wrote: > On Fri, 29 Oct 2010, Daniel Baumann wrote: > > On 10/29/2010 07:43 PM, Henrique de Moraes Holschuh wrote: > > > I like it. Is this mountpoint "blessed" by someone, since it is inside > > > /sys? Are other distros also using this path? > > > > it's the upstream location to mount it, see comments in > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595964 > > for more information. > > Ping? > > It looks like straightforward to fix, is there a reason why it has not yet > been done? I don't know why it fell through the cracks in the first place, but when I look at the bug report *now*, two things come to mind: 1. Is it *safe* and *undeniably always correct* to mount the cgroupfs in that mountpoint, with the mount options used in the patch? This answer needs only to take jessie into account. But it does need to consider jessie's cgmanager and systemd at the very least, not just lxc. 2. How does it play with jessie's systemd and cgmanager (I hope the answer is: it doesn't cause any issues). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Why is wheezy chroots switching to systemd on upgrades?
On Thu, 30 Oct 2014, Petter Reinholdtsen wrote: > It look like someone who have discussed the topic on a mailing list a > rarely read (debian-devel@) concluded that upgrades should switch to > systemd. I am not conviced that is a good way to conclude in this > matter, and wonder if we should consult the technical committee to > check if this is what they intended. Should the GR show that we can depend on sysvinit remaining a supported [by the rest of the project] init system after jessie, there is no reason to switch existing users automatically. OTOH, if it shows that it is useless to put much effort on sysvinit for jessie+1 because we will get no support from the rest of Debian, it is best that we switch the vast majority of the users to systemd now: Debian will need the test coverage to flush out the hard issues while there is still sysvinit support in Debian during jessie. Also relevant: there's an open bug and some initial work done about adding a choice in the installer to select which init system. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] What should we do about sysvinit in unstable?
On Sat, 25 Oct 2014, Petter Reinholdtsen wrote: > I added the latests NMUs to git and uploaded the current set of > changes to experimental after confirming that it could boot at least > one machine. When I started uploading to experimental in April, I > expected to have time to get the changes tested and ready for unstable > fairly soon, and get all the changes into unstable before Jessie > froze. That obviously did not happen, and I now wonder how we should > move forward. > > The package in unstable (2.88dsf-53.4) is the last of a series of > NMUs, and similar NMUs were done in experimental. The package in > experimental (2.88dsf-56) now contain the changes from all the NMUs > done so far, after my upload today. But I suspect we should not > upload the experimental package to unstable this late in the release > cycle. There are not many changes, but I suspect the release managers > might be a bit reluctant to accept these changes. ... > What do the rest of you think is the best way forward? Can't we just ask the release managers? They will ask "what is important in that release?", so if we have a good answer to that question... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#761878: Bug#761878: sysv-rc: policy-rc.d should live under /etc
severity 761878 wishlist tag 761878 wontfix thanks On Tue, 16 Sep 2014, Ansgar Burchardt wrote: > policy-rc.d is supposed to be configured (and thus edited) by the > local admin. It should thus not live in /usr/sbin. It is supposed to be supplied under the Debian alternatives subsystem or something equivalent, which will install a symlink there. In fact, it will install a symlink to /etc/alternatives/policy-rc.d, which will be another symlink there to the active "alternative". The /usr/sbin/policy-rc.d symlink would be created and managed by the packages providing policy-rc.d, through /usr/sbin/update-alternatives. The local admin can do the same if he wants. Or he can just add a real file in /usr/sbin/policy-rc.d, and update-alternatives should leave it alone. Nobody ever found a reason to package a general-use policy-rc.d, although the feature is directly used by some tools that create private chroots, such as pbuilder. > Please support using a policy-rc.d located under /etc (and leave > /usr/sbin/policy-rc.d as a legacy location). AFAIK, there is no strong technical reason to change the policy-rc.d ABI at this time, so I will downgrade this to wishlist and tag it wontfix. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#761880: Bug#761880: sysv-rc: support init scripts in /lib/init.d (or similar)
tag 761880 wontfix severity 761880 wishlist thanks On Tue, 16 Sep 2014, Ansgar Burchardt wrote: > Please support init scripts in /lib/init.d (or a similar > location). Init scripts are not configuration and as such should not > be installed into /etc (though I doubt we can drop support for that). No. We would have to support a "shadow" system, where anything in /etc/init.d would override the same named script in /lib/init.d, for no gain over what we currently have. And we are not breaking a 30-year old ABI _and_ adding undue complexity to sysv-rc without very strong reasons. Also, system initscripts *are* system configuration items, and are seldom modified by the local sysadmin. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Bug#757650: override: sysvinit:admin/optional sysvinit-core:admin/extra
On Mon, 11 Aug 2014, Cyril Brulebois wrote: > Michael Biebl (2014-08-11): > > That is > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754987 > > https://lists.debian.org/debian-user/2014/07/msg01509.html > > > > I know a workaround, but haven't figured out the underlying cause yet. > > FWIW I spent some time on #debian-systemd and idly noticed some mentions > of a boot-time timeout; when Ben mentioned net.agent I finally connected > the dots and we stopped spending more time on it. FWIW, make sure CONFIG_FW_LOADER_USER_HELPER is *NOT* set in the kernel config. I didn't check the reports above, so it is possible that this has already been checked. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#757083: Bug#757083: initscripts: please treat /usr (if separate) the same as /
(Copied also Debian bug #697002). On Fri, 08 Aug 2014, Simon McVittie wrote: > Vaguely relatedly, I see you're a sysvinit/initscripts maintainer. On > #697002 I suggested that maybe initscripts' checkfs.sh should use fsck > -M (ignore mounted filesystems), like systemd-fsck does, instead of fsck > -R (ignore root) as it currently does. That would make it unnecessary to > modify util-linux for the "provide /usr early" feature, which could be > done entirely via changes to initramfs-tools and initscripts. Any > opinion on that? Other than /etc separate from / being really fragile, I have no opinion on that. But I do agree with the others that it would make more sense to do the more important /usr work first, and tackle /etc later. IMO, separate /usr correctly handled in initramfs is important for jessie, it shouldn't be delayed by attempts to support a separate /etc. I also agree that we are not able to support properly the MU-- case anymore. While this makes me sad, it is how things are. If you want a separate /usr, you will need an initramfs for Debian jessie. As for using -M in the checkfs initscript, it looks like it can be done as long as the initramfs will make sure to fsck anything it will mount. With that in mind, I will second this change in checkfs. Note that someone else will have to do the work and testing, and come up with a tested patch, and attach it to #757083. Also, redundant fsck is not supposed to be a problem: it should skip the clean filesystem. It is a non-problem when compared with mounting a dirty filesystem (even if it would happen only on rare use cases), which causes data loss. If this adds some boot latency, so be it. REALLY. Anyway, if we switch checkfs to fsck -M, there would be no need to change the fsck wrapper -R behaviour, would there be? So maybe #697002 can be dismissed? BTW: whether the kernel uses modules or not is orthogonal to whether it has an initramfs or not. It took me some time to notice you meant "no initramfs" when you wrote about monolithic (module-less) kernels in #757083 and #697002. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#757083: Bug#757083: initscripts: please treat /usr (if separate) the same as /
On Tue, 05 Aug 2014, Simon McVittie wrote: > Also, the initramfs-tools patchset includes closing #708000 by fsck'ing > / and /usr before mounting them. So I'm not sure why initscripts would > ever need to fsck the root or /usr filesystems any more? We do support booting without an initramfs under controlled conditions, so the need to fsck / outside of the initramfs is real. /usr as a separate partition *and* no initramfs to mount it early is [unfortunately] a really bad idea on jessie/sid, we don't have to add support for that outside of the initramfs (but warning the user of the problem is likely to be a good idea). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] systemd invoke-rc.d stop unsafe if socket is activated
On Sun, 27 Jul 2014, Michael Biebl wrote: > Am 26.07.2014 23:59, schrieb Henrique de Moraes Holschuh: > > On Sat, 26 Jul 2014, Michael Biebl wrote: > >> If invoke-rc.d by default stops both .socket and .service, the package > >> maintainer no longer has this option. > > > > This is incorrect. > > > > You can extend "invoke-rc.d stop" with a --option that "quiesces the service > > and terminates its running instances, but allows a (possibly immediate) > > on-demand restart of the service by triggers such as socket activation" > > As maintainer of sysv-rc, do you have any suggestions how this interface > should look like? And where and how it should be documented? Adding the sysvinit ML to Cc. Summary and previous context here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736258#46 Short summary for sysvinit-devel: 1. Right now, invoke-rc.d stop does not block socket activation in systemd. 2. This causes problems in packages that do not expect it. 3. There's a desire in the systemd camp to have this functionality available, so it is not just a matter of fixing invoke-rc.d. I proposed that invoke-rc.d be extended with a new interface that implements the desired behaviour, and that the current interface (invoke-rc.d stop) must be changed so that it blocks socket activation under systemd. Extending invoke-rc.d: Looks like documentation should be added to the package providing invoke-rc.d, which is currently sysv-rc. There is a README.invoke-rc.d in sysv-rc that needs to be updated. The invoke-rc.d(8) manpage also has to be updated. We might want to clarify things in debian-policy after we finish and deploy the fixed invoke-rc.d implementation for systemd. Here's a not very creative suggestion for the new invoke-rc.d extension: invoke-rc.d --allow-on-demand-activation stop Bikeshedding over that naming is welcome. and for the manpage: INIT SCRIPT ACTIONS ... Note: the stop action will stop the service and also disable any automatic on-demand activation triggers for the stopped service, such as socket activation in systemd. The on-demand triggers will be re-enabled when the service is started again. OPTIONS ... --allow-on-demand-activation By default, when invoke-rc.d stops a service, any further activation of the service will be blocked until the service is explicitly started again. To keep the on-demand triggers enabled (for example: socket activation), use the --allow-on-demand-activation when issuing the stop action. This option is currently only defined for the stop action, and will be ignored on the other actions. For forward compatibility reasons, scripts must not specify this option for any other actions than stop. WARNING: maintainer scripts must be very careful when using this option, as the service might be activated while dpkg is replacing files during a package upgrade, or service configuration is being updated, etc. Services that start multiple executable modules or that have dynamic linked modules should never use this option. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#756114: Bug#756114: invoke-rc.d gets stuck when run from postinst for gnukhata-core-engine
severity 756114 important thanks On Sat, 26 Jul 2014, Praveen Arimbrathodiyil wrote: > package: sysv-rc > version: 2.88dsf-41+deb7u1 > severity: critical Downgraded to important, as it doesn't break anything but gnukhata. If this turns out to be false and the problem is generalized, feel free to upgrade the severity to "grave". You are a DD and expected to know better. Do not abuse the critical severity level. > Installation never completes when 'invoke-rc.d gnukhata-core-engine > start' is run from the terminal. It works fine on sid with systemd. If the initscript hangs, this is most likely a bug on the gnukhata-core-engine initscript or in the daemon, and not on sysvinit itself. sysv initscripts MUST NEVER HANG. They cannot block for too long either. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#748245: Bug#748245: Bug#748245: Do not pass LANG and LC_* to init script
On Thu, 15 May 2014, Vincent Bernat wrote: > ❦ 15 mai 2014 16:17 +0200, Petter Reinholdtsen : > > Personally, I believe the init.d script should fix the locale settings > > (for example using LC_ALL=C) if the service change behaviour based on > > locale settings. > > It is something difficult to know before hand. > > > Is it possible to come up with a setup that pleases everyone? Or are > > the truly conflicting needs here? > > Let's see if we can get input from people needing to keep LANG and LC_*. You must either pass neither, or pass them all. The requirements are in conflict. "service" is an user-level interface, it is supposed to be subject to i18n and l10n. OTOH, any initscript that requires, e.g. LC_COLLATE=C or LC_ALL=C ought to set it. Really. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Maintain insserv as part of the pkg-sysvinit group?
On Sat, 08 Feb 2014, Petter Reinholdtsen wrote: > > However, if something else also uses insserv (I belive upstart > > can/does for its sysv-compatibility layer), it is probably best if > > it is kept in a separate git repository. Is that what you meant > > with "next to the sysvinit repository" ? > > file-rc got a patch to use it. Not sure if it is applied or not. I > ment a separate git repository next to the sysvinit repository, yes. Sounds good to me. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Where do /lib/init/init-d-script belong?
On Sat, 08 Feb 2014, Petter Reinholdtsen wrote: > [Henrique de Moraes Holschuh] > > Since regular packages using the helper will require either a > > versioned depends or even pre-depends on the package that hosts it, > > we REALLY don't want to have to move it from a package to a > > different package later. > > > > IMHO, for that reason, sysvinit-utils is a much safer place for the > > init-d helper. > > Yeah. One idea that occured to me yesterday, as I refreshed my > memory, was that the metainit package and the #651004 but report > discussed just this issue a few years ago. What about putting it > there instead? The advantage is that it will end up in a package that > seem quite fit for the purpose. The disadvantage is that it will be a > new dependency for initscripts if we decide to use this feature in > those scripts, which I belive is a key to make this feature known and > ensure package maintainers that this is a safe thing to depend on. Well, metainit is fine, as long as we're going to be use metainit itself. Otherwise, not so much... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Maintain insserv as part of the pkg-sysvinit group?
On Fri, 07 Feb 2014, Petter Reinholdtsen wrote: > I need help maintaining the insserv package. I believe the best option > is to maintain it as part of the pkg-sysvinit group, and move it to git > next to the sysvinit repository. What do you think? > > At the moment it is maintained by Kel and me, and the source is in > subversion in the initscripts-ng alioth project. insserv is certainly welcome here, as far as I am concerned. However, if something else also uses insserv (I belive upstart can/does for its sysv-compatibility layer), it is probably best if it is kept in a separate git repository. Is that what you meant with "next to the sysvinit repository" ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Where do /lib/init/init-d-script belong?
On Wed, 05 Feb 2014, Petter Reinholdtsen wrote: > > IMHO, they goes into initscripts. That avoids an extra dependence > > (initscripts -> sysvinit-utils). > > This definitely make some sense, but most of initscripts are parts > that I suspect upstart and systemd will want to replace, as their ... > While sysvinit-utils contain tools useful for any boot system > (fstab-decode, killall5, last, lastb, mesg, pidof, service, startpar > and sulogin), and the init-d-script code is more a tool for packages > writing init.d scripts than it is a integrated part of the boot > framework. Since regular packages using the helper will require either a versioned depends or even pre-depends on the package that hosts it, we REALLY don't want to have to move it from a package to a different package later. IMHO, for that reason, sysvinit-utils is a much safer place for the init-d helper. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Make init.d/skeleton a very simple init.d script?
On Mon, 03 Feb 2014, Petter Reinholdtsen wrote:
> > We could also avoid the need to override start/stop when no pidfile
> > support is available, by doing the right thing when PIDFILE is not
> > set, something like this:
> >
> > start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} --exec
> > $DAEMON --test >/dev/null
>
> Not really, as PIDFILE always is set, and can't be overriden at the
> moment. I am open to suggestions on how to override it with the
> current structure of the code.
IMO, we must allow everything to be overriden:
NAME=${NAME:=$(basename $DAEMON)}
(or the usual if [ -z "$NAME" ] ; then NAME=$(basename $DAEMON) ; fi)
However, we cannot use this:
PIDFILE=${PIDFILE:=/var/run/$NAME.pid}
because that leaves no way for the skeleton to request no PIDFILE, unless
we special-case some value of PIDFILE that, when found, unsets PIDFILE (e.g.
PIDFILE=/dev/null).
It is probably best if we leave PIDFILE to be set by the skeleton, since it
is something that needs to be also passed to the daemon as well (or, when it
is not configurable, it has to be changed to match what the daemon wants).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Make init.d/skeleton a very simple init.d script?
On Mon, 03 Feb 2014, Petter Reinholdtsen wrote:
> root@minerva:~# /etc/init.d/acpi-fakekey restart
> [ ok ] Restarting acpi_fakekey daemon...done.
> root@minerva:~# ./acpi-fakekey-new restart
> [ ok ] Stopping acpi_fakekey daemon: acpi_fakekeyd.
> [ ok ] Preparing to start acpi_fakekey daemon...done.
> [ ok ] Starting acpi_fakekey daemon: acpi_fakekeyd.
> root@minerva:~#
>
> Would such change be acceptable? Here is the script in question
> reduced from 69 to 40 lines:
It is acceptable, however it is not optimal. Some daemons, such as apache,
can be told to restart. It is best if we implement restart as restart, not
as start-stop...
OTOH, we already support a restart override, so it really isn't a big deal.
> do_start_cmd_override() {
> if [ -d /sys/devices/virtual/misc/uinput ]; then
> start-stop-daemon --start --quiet --oknodo --exec
> /usr/sbin/acpi_fakekeyd
> else
> return 0
> fi
> }
I really hate hackjobs of daemons that can't even support pidfiles properly.
Bleh.
> I guess the changed behaviour could be slightly changed by rewriting
> do_restart to use do_stop_cmd and do_start_cmd instead of do_stop and
> do_start, but am not sure it is a good idea.
We could also avoid the need to override start/stop when no pidfile support
is available, by doing the right thing when PIDFILE is not set, something
like this:
start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} --exec
$DAEMON --test >/dev/null
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Make init.d/skeleton a very simple init.d script?
On Mon, 03 Feb 2014, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> > I think it would be best to have a way to override the actual
> > commands used to start/stop/restart/force-reload.
>
> Yeah, I suspect so too, and spliting the functions in two is probably
> the way to go then. Perhaps use do_start() and do_start_cmd() and
> similar?
That would do it, yes.
> > Also, we need to document how people should override things,
> > redefining the functions is not obvious _and_ a shell might decide
> > to spew out warnings, so I favor the "{$foo_override:=foo}" way of
> > calling these functions... if it looks like "dh", it is more likely
> > people will use it correcty :-)
>
> Can you rewrite the code to be the way you propose, to give me a
> better idea how you vision it? Btw, when can shell spew warnings when
I have mostly email-only access while at work, ssh is not working well here.
One possible way to do it would be:
do_stop()
{
if "command -v do_stop_override"; then do_stop_override "$@" ; else
our reference implementation of do_stop
fi
}
This is both easy, and obvious.
An alternative still obvious to the eventual reader (and more powerful,
since one won't be as constrained on the override) would be:
do_stop_cmd()
{
killall...
}
do_stop_default()
{
#reference implementation of do_stop, override using the
#do_stop_override variable or do_stop_cmd_override if you
#just want to change the killall to something else.
...
${do_stop_cmd_override:=do_stop_cmd}
...
}
do_stop()
{
# call the shell function named in the do_stop_override variable,
# if any. Otherwise, call do_stop_default.
${do_stop_override:=do_stop} "$@"
}
> redefining functions? Never seen that myself. I fear we "polute" the
> environment name space too much by adding variables for every function
> we can call, but perhaps we should not care about that much.
It is not much of a pollution problem, since none of these variables are
exported. I don't think we have to fear a dozen local variables. That
said, we have to consider namespace issues when we name them.
> I agree that we need documentation explaining how to use it. Should
> we write a init-d-script manual page, or just a README? I suspect a
> manual page is the best option.
I'd say manpage plus comments throughout the code and the skeleton.
> We can discuss more in #pkg-sysvinit on irc.debian.org, if you
> like. :)
e-mail is better while at work, because there is no risk I will just
"disappear" because of a meeting or because my ssh tunnel decided to
collapse and not come back up again for a while :)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Make init.d/skeleton a very simple init.d script?
On Mon, 03 Feb 2014, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> > Either "command -V", "command -v", or the "type" builtins should do, I
> > suppose. Both dash and bash support them.
> >
> > Note that it is non-trivial to know that the name really is a function due
> > to aliases, etc. There is a bashism for this, but dash doesn't support it.
> > I don't think this detail matters for our intended use, though.
>
> Ah, great. Thank you for the tip. I've implemented a second draft
> with reload support detection, pushed to the simpler-init-scripts
> branch. Check it out. Still need some cleanup in the actual daemon
> startup and lsb style reporting, I believe (should we split do_start
> in two, one doing the lsb style reporting and another doing the
> startup?), but the general structure should be ok.
I think it would be best to have a way to override the actual commands used
to start/stop/restart/force-reload.
Also, we need to document how people should override things, redefining the
functions is not obvious _and_ a shell might decide to spew out warnings, so
I favor the "{$foo_override:=foo}" way of calling these functions... if it
looks like "dh", it is more likely people will use it correcty :-)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Make init.d/skeleton a very simple init.d script?
On Sun, 02 Feb 2014, Petter Reinholdtsen wrote:
> I've also considered using functions that could be overriden in the
> init.d scripts. The init-d-script could contain
>
> do_restart() {
> ...
> }
>
> and the init.d script could contain a different implementation:
>
> do_restart() {
> ... something else ...
> }
>
> The last definition would be used. :) But it would be hard to know if
> do_reload() exist and will do something sensible, so variables are
> perhaps a better approach. Is there some way to figure out if a
> function exist, without calling it?
Either "command -V", "command -v", or the "type" builtins should do, I
suppose. Both dash and bash support them.
Note that it is non-trivial to know that the name really is a function due
to aliases, etc. There is a bashism for this, but dash doesn't support it.
I don't think this detail matters for our intended use, though.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Make init.d/skeleton a very simple init.d script?
On Sun, 02 Feb 2014, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> >> Do you believe we should move forward with this idea? It would reduce
> >
> > I like it, a lot.
>
> Thank you. Please help polish it to get it releasable. The
> problematic parts is 'reload/restart/forced-reload', as their
> behaviour differ quite a bit between daemons. Some got 'reload'
> support, others need a complete restart. I'm not quite sure how to
> best parameterise it. :)
Well, if we can leverage conditional shell parameter expansion, we could
have default behaviour and easily override it per-package in the "skeleton",
using constructs like ${variable:=default}, and ${variable:+word}.
It is available on dash and bash.
For example:
start-stop-daemon --stop --quiet \
--retry=${TERM_SIG:=TERM}/${TERM_WAIT:=30}/KILL/5 --pidfile $PIDFILE \
--name $NAME
Which will do the right thing if TERM_SIG or TERM_WAIT are unset.
And you can use it for functions, too.
${STOPFUNC:=do_stop}
will do exactly what you think: it will run either do_stop if STOPFUNC is
unset, or it will run the function/command in $STOPFUNC if it is set.
So, you can provide alternative functions (or subfunctions) to override the
default ones... as well as override any interesting parameters.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Make init.d/skeleton a very simple init.d script?
On Sun, 02 Feb 2014, Petter Reinholdtsen wrote: > A few month ago I wrote > http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html > > > documenting how at least some init.d script could be made a lot > simpler, removing the need for duplicate code in the simple case with > a forking daemon with pid file support. I did not have time to follow up on > the idea until now. > > I've just commited the draft into a new branch simpler-init-scripts in > the sysvinit repository, available from > http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=shortlog;h=refs/heads/simpler-init-scripts > >. > > Do you believe we should move forward with this idea? It would reduce I like it, a lot. > If a lot of packages start using the feature, it would also make it a > lot easier to separate the "simple" packages from the more complex > ones when migrating to a new boot system in Debian. Not to mention we can even auto-generate the whole thing via dh for these very simple situations. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Making me admin on the sysvinit project on Alioth for OpenRC
On Wed, 29 Jan 2014, Petter Reinholdtsen wrote: > Any objections to dropping Henrique de Moraes Holschuh and Kel > Modderman as uploader (and perhaps also me) and adding Thomas Goirand Well, I'm always around as a backup and emergency uploader, and believe it or not, I read everything sent to the BTS and this ML. In other words, I am still around. I just normally refrain from uploading because my test setup is nowhere as comprehensive as yours, and I am usually really conservative on all matters related to critical system infrastructure (such as initscripts, sysv-rc, insserv...). I have no objection to adding the others. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#734901: Bug#734901: initscripts: More Proper Detection of "fastboot" Kernel Parameter necessary
severity 734901 grave found 734901 sysvinit/2.88dsf-13 notfound 734901 sysvinit/2.88dsf-45 thanks On Fri, 10 Jan 2014, Sebastian.Steinhuber wrote: > during boot, Debian forces checking of hard disks/partitions, what is IMHO an > important thing to do. Since fsck during boot is not performed due to the > "i915.fastboot=1" kernel parameter, it seems adequate to set a higher > importance > to the issue, feel free to change that, but not running fsck might cause > serious > data loss. Indeed. Severity grave it is, for now. Note that this is a VERY old bug, which was exposed by new kernel conventions (well, not so new... the use of . has been around for a while, but i915.fastboot, which triggers the bug, is quite recent). I will set the BTS bug information to an arbitrarily old version of initscripts that also covers oldstable (the bug was already in place in 2009). All other uses of "grep -w" to check the kernel command line are likewise buggy, and could use some pro-active fixing. Another collision is just a matter of time... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#731477: Bug#731477: sysvinit: Hangs when booted into "-b" (emergency) mode
On Sun, 08 Dec 2013, Jeffrey Sheinberg wrote: > On Sun, Dec 08, 2013 at 07:03:02PM +, Roger Leigh wrote: > > On Thu, Dec 05, 2013 at 03:18:58PM -0500, Jeffrey Sheinberg wrote: > > > I regularly boot into "-b" (emergency) at least once a week, in order to > > > perform backups of my root partition while it is in a read-only state. > > > > > > I have never experienced any problems with using "-b" (emergency) mode > > > before encountering this problem. > > > > > > This problem has so far only happened when booting this linux kernel, > > > > > > linux-image-3.11-0.bpo.2-amd64 > > > > This is an odd problem, and it's going to be tricky to track down > > without being able to easily reproduce it. If you notice the > > keyboard lights flickering, this looks like it's possibly an > > input layer issue. If only this kernel exhibits the problem then > > sysvinit is unlikely to be involved directly. I would suggest > > looking at a newer kernel e.g. 3.12 and the options the kernel > > was compiled with. This typically happens when something in the USB + HID stacks is missing. Please try initramfs from unstable (or backports), it works around this kind of limitation of the extremely modular distro kernels. But you'll still be hosed if it can't run long enough to start udev and modprobe a lot of modules. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#728682: reassign to logrotate
reassign 728682 logrotate retitle 728682 logrotate: cronjob: please use invoke-rc.d --quiet thanks On Mon, 04 Nov 2013, Erwan David wrote: > /etc/cron.daily/logrotate: > invoke-rc.d: action rotate is unknown, but proceeding anyway. > > My /usr/bin/policy-rc.d does indeed treat the rotate action. However it is > not documeted in the man page. > > It seems there is a mismatch between logrotate and invoke-rc.d about this > action. Well, "rotate" is a custom action provided by logrotate. We cannot really teach invoke-rc.d and policy-rc.d about it in the general case. What is happening is that invoke-rc.d is warning you that it is sending a non-standard action to policy-rc.d. That warning doesn't show up otherwise. For now, it would be best for logrotate to use "--quiet" to call invoke-rc.d with custom actions. That said, I am unsure if a cron script is the proper place to use invoke-rc.d, it is certainly not its intended (and expected!) use profile. We usually control cronjobs through /etc/default/ or automatically (so as to avoid running them when the package is in removed but not purged state), and not through runlevels... Anyway, I am reassigning the bug to logrotate. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#717488: Bug#717488: Please always launch /etc/init.d/ups-monitor when halting the system
On Fri, 26 Jul 2013, Fabien C. wrote: > On 26/07/2013 03:06, Henrique de Moraes Holschuh wrote: > > It is basically not a good idea at all to cut power instead of issuing a > > hardware shutdown command. Lots of stuff on server boxes get highly pissed > > off if you just cut power. > > Hmmm, "shutdown -hH" still shuts down the disks, and halts the CPU. I think > the > *only* thing it does not is cut the power, but the system is already ready to > lose it. No, you did not tell the baseboard management controller and friends that you want to shutdown, and they will not only fail to do an ordered shutdown, but also raise alarms that power was lost and an unclean shutdown happened. And since this is x86, the only way to tell the platform that you want a shutdown in the first place is to try to issue a platform "poweroff" command. There is no platform "halt" command. > > I would have to put some effort to recall all the trouble we had in the past > > to access whether we can support this proposed change, though. > > You are probably referring to this discussion, which I read: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358696 > > Well, we could make it an option if you think it is not a good idea to have it > as default. It is impossible to have it as a default. So yes, if we do it, it would _have_ to be an option. > > What is important is that we must not break the sane scenario, where you > > have the box properly configured to always power up on power restore, and > > the UPS configured to always cycle the load once the load (i.e. us) signals > > that it is past the point of no return (i.e. that it will require a power > > cycle to restart -- in Debian, that pretty much means as soon as we switch > > to runlevel 0). > > I don't think "always power up on power restore" is a "properly configured" > box. If a box is off, that is very probably for a good reason, and I *don't* Your use case is not the most common, nor the only use case. > want it to power up based on some random event like power outage... What the > "normal" people want is to get back to the state the machines were before the > power problem occured, no more, no less. That is restore last power state. This is not possible to do sanely on an architecture that cannot differentiate from administrative shutdown and operational shutdown, or that doesn't even have a "halted-but-powered-on" state anyway. > > Also, shutdown -H must NOT issue a UPS power off command [by default], it is > > documented to not do it. > > We make the documentation, don't we? You've got to be kidding me. Who knows how many boxes and scripts out there depend on the current, documented, shutdown -H behaviour? Bugs we fix. Functionality working as designed, we don't change like that. You can request a NEW option for shutdown that does what you want, though. Or you can have an optional, non-default way to change -H to do what you want. Those are your two choices. > Also, I would add that /etc/init.d/ups-monitor does *not* cut the power off > if > the UPS is not running on battery. Then, it is broken, unless something else is issuing the proper synchronization commands to the UPS. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#717488: Bug#717488: Please always launch /etc/init.d/ups-monitor when halting the system
On Sun, 21 Jul 2013, Roger Leigh wrote: > On Sun, Jul 21, 2013 at 01:23:28PM +0200, Fabien C. wrote: > > please launch "/etc/init.d/ups-monitor poweroff" everytime /etc/init.d/halt > > is > > called, not only when INIT_HALT=POWEROFF. > > > > The current script forbids that behavior because if INIT_HALT is not equal > > to > > POWEROFF, which is "unfortunately" the case with "shutdown -Hh", then > > /etc/init.d/ups-monitor is *never* called. > > While this change sounds reasonable, I'm not personally aware of the > reason for the current logic. Is changing this going to break > anything? Why is it currently the way it is? It is basically not a good idea at all to cut power instead of issuing a hardware shutdown command. Lots of stuff on server boxes get highly pissed off if you just cut power. I would have to put some effort to recall all the trouble we had in the past to access whether we can support this proposed change, though. What is important is that we must not break the sane scenario, where you have the box properly configured to always power up on power restore, and the UPS configured to always cycle the load once the load (i.e. us) signals that it is past the point of no return (i.e. that it will require a power cycle to restart -- in Debian, that pretty much means as soon as we switch to runlevel 0). Also, shutdown -H must NOT issue a UPS power off command [by default], it is documented to not do it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#708934: Bug#708934: Bug#708934: how to avoid all mounts for LXC systems?
On Sun, 19 May 2013, Steve Langasek wrote: > I strongly recommend a more generic approach of detecting whether the > required mount is already mounted, and skipping the operation if it is. There is the non-obvious, and quite vexing issue of mount options. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] policy-rc.d doesn't work?
On Mon, 22 Apr 2013, Petter Reinholdtsen wrote: > [Bob Proulx] > > Then according to the docs no daemons should be started. But when I > > reboot all daemons are running normally. In spite of the policy-rc.d > > script the init scripts were all still run. > > policy-rc.d is invoked by update-rc.d when a package is installed and > removed, and not by the individual init.d scripts when the machine or > service is started. policy-rc.d is invoked (only, AFAIK) by invoke-rc.d, which should be used by all the maintainer scripts inside the packages to start/stop/restart services when a package is installed, removed or upgraded. It does not override the initscript subsystem itself, so if you want to change the behaviour on boot, you use "update-rc.d disable/enable". > Clear documentation, I suspect. :) Probably... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] installation-manual: Should it suggests to switch to run level 1 and back?
On Wed, 17 Apr 2013, Petter Reinholdtsen wrote: > [Regid Ichira] > > 1. AM I right that strictly speaking, there are cases where the > > `easiest way' will not work? > > Yes. Any daemon started from within rcS.d/ will be killed by > /etc/rc1.d/S01killprocs and not started again when switching to > runlevels 2-5. This is the reason why I have recommended to move all > daemon starting out of rcS.d/ and into rc[2-5].d/. There is a lot of > work left to do before this is done. Luckily there isn't that that > many daemons started from rcS.d/, so in many installations, switching > to runlevel 1 and back will work. There's networking: it may start deamons that are required for the connection to remain operational in the medium/long term (dhcp-client, wpa-supplicant, etc). These are all killed and not restarted when you switch to runlevel 1. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#693960: Bug#693960: sysvinit: Undocumented, obscure limit for "process" field in inittab entries
On Thu, 22 Nov 2012, Johannes Truschnigg wrote: > Package: sysvinit > Version: 2.88dsf-13.1+squeeze1 > Severity: minor > Tags: patch > > > I added a new entry to inittab on a busy host which did not seem to start upon > invoking `telinit q`. Syslog received the following message: > > Nov 22 10:16:29 r7 init: /etc/inittab[93]: process field too long > > This limit (127 characters) is not documented in man 5 inittab, nor anywhere > else I looked. In init's source file, there are error messages the explicitely > state length limits for other fields in inittab (which a user is much less > likely to overflow, I think), which seems kind of weird. Eh, should we also increase that limit to something larger [if it is feasible to do so] ? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] (fwd) make tar*-pkg considered dangerous
I am forwarding this as a remider that, should we ever get to the point of
moving around /lib or /usr/lib, /sbin or /usr/sbin, and /bin or /usr/sbin,
as well as any other such trunks, we really ought to consider whether we
should be using symlinks or bind mounts [where possible] for such moves.
Also, just in case, Debian users are gently reminded that there are less
unsavory methods of packing custom kernel builds for later use in Debian
boxes, including the Linux upstream "deb-pkg" make target (dpkg is a lot
smarter than "tar"), and the make-kpkg command provided by the
kernel-package Debian package (which IMHO tends to produce better kernel
.deb packages than the upstream "deb-pkg" make target.
- Forwarded message from Andi Kleen -
Date: Wed, 12 Sep 2012 05:16:46 +0200
From: Andi Kleen
To: linux-ker...@vger.kernel.org, linux-kbu...@vger.kernel.org
Subject: make tar*-pkg considered dangerous
Hi,
We've had some incidents with people destroying Fedore 17 installs
(to the point of reinstall) by installing a kernel tarball generated with
make tar*-pkg
The problem is that the tarball includes /lib/{modules,firmware},
but on FC17 /lib is a symlink. tar when it unpacks the tarball
replaces the symlink with the directory. So they end up
with a /lib which only contains the new kernel files, but nothing else,
And then the system doesn't boot anymore.
I'm not sure there is a good fix for this. I don't know of a way to
convince tar to not do that. And putting everything into /usr
would be very incompatible.
Disable these make targets or add warnings? If disabling people should
use rpms or dpkgs instead?
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
- End forwarded message -
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#686895: btrfsck complains of -f option used by /forcefsck support
reassign 686895 btrfs-tools thanks On Fri, 07 Sep 2012, Simrun Basuita wrote: > # cat /var/log/fsck/checkroot > Log of fsck -C -f -a -t btrfs /run/rootdev > Fri Sep 7 01:34:14 2012 > > fsck from util-linux 2.20.1 > fsck.btrfs: invalid option -- 'f' > usage: btrfsck dev > Btrfs Btrfs v0.19 > fsck died with exit status 1 This is a problem in fsck.btrfs. fsck.btrfs is supposed to be a compatibility layer between the generic fsck tool, and the filesystem-centric check tool (btrfsck), it has to do something sane with options that don't make sense for btrfs, or are not yet supported by btrfsck. Reassigning to btrfs-tools. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Add new members of the pkg-sysvinit team ?
On Sat, 25 Aug 2012, Petter Reinholdtsen wrote: > [Henrique de Moraes Holschuh] > > Accept, I suppose. > > Done. > > > IMHO, deny until he has proved himself. I told him to start working > > first, ask for commit access later, and we haven't heard from him for > > a while... > > I rejected it for now, but am happy to reconsider after he show up to > contribute. :) > > Still would like an answer to this question: > > > I guess someone more active than me should become project admin, to > > avoid these requests to linger for months. Any volunteers? I'm not a good choice for that right now, I'm afraid. We should have several project admins, actually, but it doesn't help any if they're not going to be actively doing something about it :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Add new members of the pkg-sysvinit team ?
On Wed, 22 Aug 2012, Petter Reinholdtsen wrote: > Via Alioth, two people have requetsted membership in the sysvinit team > with the following comments: > > Thomas Goirand (2012-08-22) > > We'd like to use this Alioth group for OpenRC, please add me! Accept, I suppose. > Vangelis Mouhtsis (2012-01-07) > > Hi folks, > I'm new and i'm trying to learn packaging to help debian community. > I'm debian user for quiet some time not as a simple user but > looking for everything relevant for each package/depends/. > So, i please you to accept me in your group even to test me. > Please contact me. IMHO, deny until he has proved himself. I told him to start working first, ask for commit access later, and we haven't heard from him for a while... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#455230: Bug#455230: /etc/init.d/urandom: please consider doign dmesg > /dev/random at startup
tag 455230 fixed-upstream thanks where "upstream" here is the kernel itself. Fixed in Linux kernel 3.2.26, 3.0.41, 3.4.9, 3.5.2, 3.6. The fix will eventually flow down to the 3.2-based Wheezy kernel and to unstable. On Wed, 12 Dec 2007, Marc Haber wrote: > > On Sun, 09 Dec 2007, Marc Haber wrote: > > > during a discussion on the LKML, it was suggested to do "dmesg > > > > dev/random" in the startups scrips of a distribution. Please > > > consider doing this in Debian. It does a lot of the above, now. It is _not_ the same as doing dmesg | gzip > /dev/random, though, so we might want to do it anyway. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#681639: Bug#681639: [nyk: Re: Bug#681639: initscripts: no longer updates /var/log/dmesg]
On Wed, 18 Jul 2012, Michael Biebl wrote: > On 17.07.2012 23:52, Roger Leigh wrote: > > We removed the bootlogs script because it was believed to be made > > redundant by modern logging daemons. However, this was not taking > > into account the fact that even though the information is logged, > > it is eventually rotated and lost. > > > > I've assigned it to rsyslog as the default logging daemon, and > > because Nicholas said that it was already doing this in Ubuntu. > > We can certainly re-add the bootlogs script in initscripts if > > this is still needed, and is the best place for it. Otherwise, > > I can file additional bugs against the other loggers. > > I count 7 packages providing system-log-daemon. And that's at least one too much. sysklogd needs to die. > It seems kinda odd to me, that we should duplicate that functionality in > 7 packages. Don't you agree? Yes. > As this particular log file is about the actual boot process only, I > kinda feel it doesn't belong into rsyslog but naturally fits into > sysvinit/initscripts. Agreed. /var/log/dmesg (*with rotation*) is _extremely_ useful, I use it at nearly every reboot due to a kernel upgrade (diff -u /var/log/dmesg.0 /var/log/dmesg)... Roger, I do think we should add it back in either initscripts or sysvinit. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Saving of /dev/urandom seed at Debian bootup
On Fri, 13 Jul 2012, Petter Reinholdtsen wrote: > [Mikko Hänninen] > > While investigating randomness and /dev/urandom on Debian Linux, > > I came across this comment (by you, I think): > > > > # Hm, why is the saved pool re-created at boot? [pere 2009-09-03] > > > > in /etc/init.d/urandom, part of initscripts in Debian Squeeze. > > > > Hopefully I've inferred correctly who to contact about it. I know the > > question is nearly three years old, but in case nobody has provided > > the answer to you yet, and you're still curious, then here's my guess: > > The pkg-sysvinit-devel@lists.alioth.debian.org list is a better contact > point. I send your email there. > > Thank you for the input. I did get some feedback about this question > earlier, and guess the comment should be replaced with an explaination > now. :) > > See > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2010-July/004533.html > > > for the old thread. Also, the /dev/random driver in the kernel finally has a maintainer with more time to enhance it. I am keeping a close eye on it, and will request backports to the Debian stable kernel on the grounds that it is very important for security, but that's at least six months away (you HAVE to give these things some time to mature). Some of the changes being proposed give it more a bit more unpredictability at cold start. But nothing nearly as good as[1] the seeding done by the operating system using the saved state at shutdown/reboot. [1] assuming no reuse of the seed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#677712: Bug#677712: sysvinit-utils: startpar not allow to start cryptdisks
On Sat, 16 Jun 2012, Roger Leigh wrote: > On Sat, Jun 16, 2012 at 03:00:55PM +0400, Alexander V. Kudrevatykh wrote: > > Package: sysvinit-utils > > Version: 2.88dsf-27 > > Severity: important > > > > after upgrading to 2.88dsf-27 boot stops on "cleaning temprorary > > files... /tmp" and not ask > > password for cryptdisks > > disabling cryptdisks or switch to legacy boot order fixes problem > > Any idea about what is causing the breakage here? Does cryptdisks > have incorrect LSB dependencies? Does cryptdisks declare its initscript as interactive? My guess is that it needs to have its stdin connected to the controlling terminal to ask for passwords... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#630615: Bug#630615: Defaults of tmpfs on /tmp redux
On Thu, 24 May 2012, Jeremy Bicha wrote: > 64 MiB seems a ridiculously low threshold. How about 512MiB instead? > I'd find it difficult to use a desktop machine with less than 1GB of > RAM and think that reserving 20% of that limited RAM for /tmp is not tmpfs reserves nothing of the sort. It can use UP TO that ammount of _virtual_ memory, which is very different from "reserving". That said, 128 or 256MiB would probably be a better threshold. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#672838: Bug#672838: sysv-rc: invoke-rc.d postfix start fails to start
On Sun, 13 May 2012, Neil Watson wrote: > Expected results > invoke-rc.d postfix start > Should start the postfix service. Please give us the results of: dpkg -s postfix /usr/sbin/invoke-rc.d --query postfix start ; echo $? head -n 30 /etc/init.d/postfix If you call /etc/init.d/postfix start, does it work? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#670106: Bug#670106: initscripts: please ignore noauto sysfs entries in fstab
On Wed, 25 Apr 2012, Carsten Hey wrote: > * Roger Leigh [2012-04-24 16:31 +0100]: > > On Tue, Apr 24, 2012 at 02:55:55PM +0200, Michael Prokop wrote: > > > * Carsten Hey [Mon Apr 23, 2012 at 01:07:17 +0200]: > > > > > > > Please ignore noauto sysfs entries in fstab. Not mounting sysfs to /sys > > > > if such a line is present in fstab leads to udev not starting. > > > > > > > If this bug is not fixed, this problems will show up after upgrading to > > > > Wheezy on some systems. > > > [...] > > > > > > FTR: According to my tests, bootstrapping wheezy with > > > grml-debootstrap 0.49 fails WRT /sys mounting and bootstrapping > > > whezzy with grml-debootstrap 0.50 (just released and uploaded, it > > > does not add a noauto sysfs line any longer) succeeds. > > > > So does this problem still need addressing in initscripts? > > The problem is that installing Squeeze via grml-debootstrap perfectly > works and after upgrading to Wheezy udev will not start. A wrongly > generated /etc/fstab can't be fixed for existing systems by releasing > a fixed version of a tool that is only run once during installation. The correct thing to do would be to fix the broken /etc/fstab, then... > initscripts is currently respecting what you obviously *think* are the > wishes of the admin. Since /sys is nowadays mounted on most or all Which means we're following the principle of least surprise... And you can mount /sys more than once, in weird places for whatever reasons. Those could conceivably be "noauto", so we'd have to ignore noauto only on lines that attempt to mount the special filesystems where we'd expect them to be mounted in the first place. > In my opinion, the underlying problem is that there is no clear and > distribution independent semantic of noauto when used in a fstab entry > for those standard virtual file systems. If there would be such a clear The other distros ignore "noauto"? Or do them ignore /etc/fstab entirely for the special filesystems? I suspect it is the later. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#669949: Bug#669949: sysvinit: Break X11: no more mouse and keyboard
On Mon, 23 Apr 2012, Henrique de Moraes Holschuh wrote: > On Sun, 22 Apr 2012, Roger Leigh wrote: > > I'm not sure that this is definitely a sysvinit issue. The mouse > > and keyboard are entirely functional right up until X11 starts up. > > This may well be a red herring, but you're all using the latest 3.2 > kernel, aren't you? A Debian user went straight to LKML with an udev > issue related to the later 3.2 kernels (which was a _lot_ worse than > just input devices disappearing, I think. I will have to hunt down that > message). Hmm, found it and it is a very different issue, related to udevadm settle and event filtering. It is unlikely to be related to this problem. > It is not impossible that an interaction of the latest sysvinit with the > later 3.2 kernels is causing problems if we changed _anything_ that has > direct interaction with the kernel (such as an ioctl, signal masks...) > in the latest sysvinit that could trigger a kernel issue. > > Did we? That's still a question worth considering. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#669949: Bug#669949: sysvinit: Break X11: no more mouse and keyboard
On Sun, 22 Apr 2012, Roger Leigh wrote: > I'm not sure that this is definitely a sysvinit issue. The mouse > and keyboard are entirely functional right up until X11 starts up. This may well be a red herring, but you're all using the latest 3.2 kernel, aren't you? A Debian user went straight to LKML with an udev issue related to the later 3.2 kernels (which was a _lot_ worse than just input devices disappearing, I think. I will have to hunt down that message). It is not impossible that an interaction of the latest sysvinit with the later 3.2 kernels is causing problems if we changed _anything_ that has direct interaction with the kernel (such as an ioctl, signal masks...) in the latest sysvinit that could trigger a kernel issue. Did we? Can anyone that is reproducing this bug try an older kernel (preferably not the latest 3.0, as all longterm kernels are somewhat sync'd and if something caused a regression in 3.2-stable, changes are high it is already in 3.0-stable too). > I've tested this in single user mode, running the init scripts by > hand. It's all working perfectly up until kdm/gdm starts, and it > can be triggered by hand with xinit. > > All of the tmpfses, including /dev, are mounted and functional. X.org makes use of several input-layer features/ioctls/etc that very few/no other programs would during boot. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#669949: Bug#669949: sysvinit: Break X11: no more mouse and keyboard
On Sun, 22 Apr 2012, Roger Leigh wrote: > On Sun, Apr 22, 2012 at 11:15:29AM +0200, valette wrote: > > After upgrade, X11 does not report any keybord or mouse on my laptop. If I > > plug a USB mouse its detected. > > If the USB mouse is plugged before X starts its not detected either. > > Probably related to hal/udev but... > > I'm not sure. I'm seeing the same thing; but it's fine until the > start of X. However, in my case the mouse and keyboard are plugged > into a USB hub on my monitor, and unplugging and reconnecting the > hub to the main system results in them working again. > > > NB: I modified the /etc/defalt/tmpfs to get /tmp as a normal fs. > > Does this alter the behaviour at all? > > > I can't see what has changed here that could affect this, so a bit > more information would be appreciated if possible. I'm not sure > how USB device availability is related to /tmp, but hopefully some > more investigation will help here. It is related to /dev, which is a tmpfs. If anything messes with /dev, the device node will be lost (and X won't find it), but a hotplug will recreate it. So, is /dev alright? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
On Fri, 20 Jan 2012, Goswin von Brederlow wrote: > Henrique de Moraes Holschuh writes: > > The kernel has to return all entries that are visible to the current > > namespace, otherwise you pretty much cannot know about the existence of > > shadowed entries in the first place, and that has all sort of nasty > > implications for security and troubleshooting. > > > > The kernel should NOT include entries that are out of reach due to > > namespaces or chrooting, but I don't think this is quite correct right now. ... > But isn't the rootfs out of reach because the initramfs "chroots" to the > real root and starts /sbin/init? Back when pivot_root was used that > was combined with an actual call to chroot. Before run-init combined the > two. That's what I meant with "I don't think this is quite correct right now". > I'm not realy disagreeing with you but argue that the duplicate rootfs > entry is not visible to the namespace. I am not sure how /proc/mounts and friends should play with chroot(). I suppose it depends on whether one can actually reach that path somehow. If it is forever unacessible, IMO it is effectively outside the namespace and I believe it should not be visible. But that's where I reach the limits of my knowledge, and I can't really argue about it. > What it should show is only the last entry, the tmpfs the chroot is > on. All other entries are not visible to the processes inside the > chroot. I think you're correct in this. > Note that in a chroot any mountpoints inside the chroot have their > prefix removed (/home/mrvn/chroot becomes /) while others are left as > is. That is wrong too IMHO. The filesystem the chroots / is on should > become / even if the chroot is a directory instead of a mountpoint and > entries outside the chroot should not be listed at all. I also think you're correct here, but as I said, chroot() is tricky, and I am wary of arguing too much about it without strong knowledge about the nuances, which I don't have. Maybe this thread really ought to move to linux-fsdevel or LKML? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#653073: Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
On Fri, 20 Jan 2012, Goswin von Brederlow wrote: > Henrique de Moraes Holschuh writes: > > On Thu, 19 Jan 2012, Paul Eggert wrote: > >> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: > >> > Note: there is no reason why the kernel could not return the mount > >> > information with shadowed paths removed in a separate procfs node, as > >> > that would cause no security/troubleshooting problems. > >> > >> That's what I was thinking of, and it'd be a much better fix, > >> as it would fix things for all applications. > >> > >> The current approach expects all app developers to modify > >> their applications in order to deal with a feature that app > >> developers typically don't know about and don't understand; > >> this isn't a good way to introduce a new feature. > > > > On the app side, I will tell you what you're likely to get back from the > > crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't > > have to reinvent the wheel, and fix it in userspace. It gets worse: such > > library interface already exists, in the form of getmntent, setmntent, > > addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix > > it in glibc. > > How do you decide which of two conflicting entries is real? Since mount > --move does not change the order of entries you can not just pick the > last one. > > For example which entry is the right one with an output like this: > > tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0 > tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0 > > I don't think this can be fixed in userspace alone. At a minimum the > kernel has to keep entries in order of visibility, i.e. the later > entries always shadow earlier entries. Which means that on mount --move > the kernel has to move the entry in /proc/mounts up or down as needed. Yes, it would have to order in that way. > PS: I think you can also mount something below an already shadowed entry > (if you have a shell with cwd in the shadowed one) and it would show up > in the wrong spot in /proc/mounts. I believe that's correct, and should be fixed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#653073: Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
On Thu, 19 Jan 2012, Paul Eggert wrote: > On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: > > Note: there is no reason why the kernel could not return the mount > > information with shadowed paths removed in a separate procfs node, as > > that would cause no security/troubleshooting problems. > > That's what I was thinking of, and it'd be a much better fix, > as it would fix things for all applications. > > The current approach expects all app developers to modify > their applications in order to deal with a feature that app > developers typically don't know about and don't understand; > this isn't a good way to introduce a new feature. On the app side, I will tell you what you're likely to get back from the crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't have to reinvent the wheel, and fix it in userspace. It gets worse: such library interface already exists, in the form of getmntent, setmntent, addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix it in glibc. AFAIK, the kernel is not in any better position to remove shadowed paths than userspace, both are perfectly capable of doing it. Now, removing paths that are outside of the current process scope (due to namespaces or chroot or whatever), THAT is something only the kernel can do correctly... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#653073: Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
On Thu, 19 Jan 2012, Henrique de Moraes Holschuh wrote: > On Thu, 19 Jan 2012, Goswin von Brederlow wrote: > > Paul Eggert writes: > > > On 01/18/12 06:25, Goswin von Brederlow wrote: > > >> What df should do is automatically skip the entries that are obscured or > > >> generally inaccessible. > > > > > > Isn't this missing some of the larger context? df is just doing what > > > lots of other programs do: finding out what file systems one has, > > > and reporting statistics on them. It sounds suboptimal to require > > > the maintainers of all these programs (coreutils, nautilus, etc.) > > > to rewrite their apps to deal with obscured entries. Surely it would > > > be better to have the kernel ordinarily return just the ordinary entries, > > > and to return obscured entries only when they are specially requested. > > > That way, this issue would be isolated to the few bits of code that really > > > want to see obscured entries. > > > > +1. Kernel knows best anyway. > > The kernel has to return all entries that are visible to the current > namespace, otherwise you pretty much cannot know about the existence of > shadowed entries in the first place, and that has all sort of nasty > implications for security and troubleshooting. > > The kernel should NOT include entries that are out of reach due to > namespaces or chrooting, but I don't think this is quite correct right now. > > If you don't want to show to the user shadowed entries, fix it in the > UI, maybe write a nice LGPL lib and get the various GNU utils to use it > to avoid duplicated effort... or fix it in glibc, if applicable. But > /proc/mounts really has to return complete information. Note: there is no reason why the kernel could not return the mount information with shadowed paths removed in a separate procfs node, as that would cause no security/troubleshooting problems. I do think kernel people will tell you to fix that in userspace, though. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
On Thu, 19 Jan 2012, Goswin von Brederlow wrote: > Paul Eggert writes: > > On 01/18/12 06:25, Goswin von Brederlow wrote: > >> What df should do is automatically skip the entries that are obscured or > >> generally inaccessible. > > > > Isn't this missing some of the larger context? df is just doing what > > lots of other programs do: finding out what file systems one has, > > and reporting statistics on them. It sounds suboptimal to require > > the maintainers of all these programs (coreutils, nautilus, etc.) > > to rewrite their apps to deal with obscured entries. Surely it would > > be better to have the kernel ordinarily return just the ordinary entries, > > and to return obscured entries only when they are specially requested. > > That way, this issue would be isolated to the few bits of code that really > > want to see obscured entries. > > +1. Kernel knows best anyway. The kernel has to return all entries that are visible to the current namespace, otherwise you pretty much cannot know about the existence of shadowed entries in the first place, and that has all sort of nasty implications for security and troubleshooting. The kernel should NOT include entries that are out of reach due to namespaces or chrooting, but I don't think this is quite correct right now. If you don't want to show to the user shadowed entries, fix it in the UI, maybe write a nice LGPL lib and get the various GNU utils to use it to avoid duplicated effort... or fix it in glibc, if applicable. But /proc/mounts really has to return complete information. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#656081: Bug#656081: /usr/sbin/service: disrespects policy-rc.d
On Mon, 16 Jan 2012, Andreas Beckmann wrote: > The problem with 'service' is that it actually tried to start apache > while piuparts had created a policy-rc.d that prevents any service from > being started in the chroot. (Apache could not be started in the chroot > because :80 was already in use by the host). > > I don't think 'service' should deviate from 'invoke-rc.d' in that case. 'service' is for use by the local admin, not packages, thus it has no business trying to second guess anything, so yes, it IS supposed to ignore policy-rc.d and builtin invoke-rc.d policies. If the local admin told 'service' to start a service, it should do just that, even inside chroots. Any package not using invoke-rc.d in the maintainer scripts to start/stop a sysv initscript service is severly broken and has to be fixed, use of 'service' by a package's maintainer script OR inside the initscript is NOT allowed. > Should there be a lintian check for > maintainer-script-uses-service-instead-of-invoke-rc.d? That would be really nice... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Handling of non-conffiles
On Wed, 11 Jan 2012, Roger Leigh wrote: > One problem mentioned in a few bugreports is the handling of > updates to /etc/default/rcS. Because it's not a conffile, we > don't provide updates to it. While there are good reasons for > this approach, I was thinking of ways of improving the situation. > > While we don't want to lose any user customisation of this file, > would it make sense to update the file to the latest version if > it hasn't been modified? We can do this quite simply: take the Better check ucf, no reason to reinvent the wheel... > BTW, I started going through some of the open bugs and closing > those fixed in current releases. Would there be any objection > to reviewing and closing bugs which are no longer reproducible > and/or which are no longer relevant on current systems? None from me. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#637087: Bug#637087: Sensible default for all systems
On Sat, 17 Dec 2011, Josh Triplett wrote: > I don't see any possible scenario where FSCKFIX=no makes sense as a > default. We don't debug broken filesystems with disk editors anymore; When using md or device mapper in any way shape or form where the kernel might decide to mount the component device instead of the lv or md device. There are other failure modes as well where the system is actually going to further corrupt data if you let fsck run. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#644572: Bug#644572: sysvinit: Spins disk up briefly from standby during poweroff
On Fri, 07 Oct 2011, Touko Korpela wrote: > I suspect that "-h" option that "halt" gets during poweroff is buggy and > shouldn't spin disks up that are already at sleep. Nowadays we're supposed to trust the kernel to do it right, and your disk should spin up only if it has crap firmware (unlikely). Unless you're using the deprecated "old ide" drivers (/dev/hd*), in which case all bets are off. Please edit /etc/init.d/halt and make it not add "-h" to the halt invocation (but make sure to add "sync ; sleep 5" before the halt command just in case). Does that fix the issue? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#644099: Bug#644099: init: Id "co" respawning too fast: disabled for 5 minutes
On Sun, 02 Oct 2011, Ralf Jung wrote: > On both of the machines I installed a recent Debian on (testing on my laptop, > sid on my tower), I am getting the following error regularly in the syslog, > and > on tty1: > > init: Id "co" respawning too fast: disabled for 5 minutes > > > > Googling for that message showed that many others have it, too, and that it > could be silenced by uncommenting the following line from /etc/inittab > > co:2345:respawn:/sbin/getty hvc0 9600 linux *Un*commenting means enabling it. Did you _disable_ it by _commenting_ it? Looks like fallout from #636846... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] system hangs during shutdown...
On Sun, 24 Jul 2011, Bruce Sass wrote: > On July 23, 2011 06:56:44 AM Henrique de Moraes Holschuh wrote: > > On Thu, 21 Jul 2011, Bruce Sass wrote: > > > > This is not a bug. NFS clients are supposed to keep on trying to reach > > > > the server, by default. You should have unmounted the directory from > > > > the NFS client(s) before shutting down the server. > > > > > > > > Ben. > > > > > > Sounds like a desirable behaviour when the system is coming up, but > > > having the client hang when *going down* because a server disappeared > > > doesn't seem right. > > > > Don't use NFS, then. It does NOT tolerate servers going away. Maybe > > NFSv4 is a bit better, but v3 does not let you get away with it (maybe > > it should for read-only mounts). > > It looks like NFSv4 doesn't like that happening either. > > Well, that kinda sucks,.. > > ...I'm thinking that initscripts should be smarter in that it should > recognize > hopeless cases and set a limit on how long the system will wait before > shutting down. Fully configurable, of course. The kernel will hang the umount command. Maybe a cluster filesystem would be a better fit for your needs? They tolerate that sort of thing a lot better. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] system hangs during shutdown...
On Thu, 21 Jul 2011, Bruce Sass wrote: > > This is not a bug. NFS clients are supposed to keep on trying to reach > > the server, by default. You should have unmounted the directory from > > the NFS client(s) before shutting down the server. > > > > Ben. > > Sounds like a desirable behaviour when the system is coming up, but having > the > client hang when *going down* because a server disappeared doesn't seem right. Don't use NFS, then. It does NOT tolerate servers going away. Maybe NFSv4 is a bit better, but v3 does not let you get away with it (maybe it should for read-only mounts). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] git repository for sysvinit
On Wed, 13 Jul 2011, Roger Leigh wrote: > I've been able to merge it into the master branch using > "git replace" and "git filter-branch". Because it changes > all the commit SHA1s, everything after 2.86.ds1-22 needs > retagging, but that won't be too hard. This is on the > "rewrite" branch in the repo. It's identical to the > master branch except for the addition of the missing > commits into the history. I'll retag and revalidate it > before replacing the master branch with the rewritten > version, and then it should be perfect. Ah, nice. Sorry, sent my last email before reading this one. Thank you! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] git repository for sysvinit
On Wed, 13 Jul 2011, Roger Leigh wrote: > Thinking about this some more, it should be possible to > edit the history to graft the subsequent history on the > master branch after this commit which would make the > entire history linear. It's just a matter of finding the > necessary git magic. (Not a standard rebase, since we > don't want any of the trees to change, just the parent > of one commit.) Once that's done, it's just a simple > matter of retagging. If you do that, please rewrite the full history (git filter-branch) so that the graft becomes a real connection, and can be removed. We're not using that repo yet, there is no reason to have a graft there as anything more than a temporary measure. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] git repository for sysvinit
On Tue, 12 Jul 2011, Roger Leigh wrote: > Dodgy tags: > 2.86.ds1-12 > 2.86.ds1-13 > 2.86.ds1-22[.new[@936]] > 2.86.ds1-31 > 2.86.ds1-34 > These all appear in git as incomplete merges. They exist as tags > but are not attached to any branch (i.e. unlike all other tags > are not in the history for master). "git svn" gave incorrect > history for these. "svn2git" correctly reproduces the tree, but > it's not part of the history for any specific branch. You can > easily create such a branch with "git checkout -b $tag". > I guess these were a result of making a commit to the tag after > branching from master, since in svn a tag is just a directory. Hmm, can we track whomever did those commits and check with them if they were not "lost" changes, or stuff we ended up shipping as a stable/security update? > Anyway, hope this is useful. If you don't want to use the repo It is. Thank you. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] /etc/init.d/urandom
On Fri, 01 Jul 2011, Thorsten Glaser wrote: > 49 # Hm, why is the saved pool re-created at boot? [pere > 2009-09-03] > > After talking to pere in IRC he suggested I mail the answer here: We've had a thread about this sometime ago, and I did some asking on LKML about it. It is in the ML archives and the BTS. I don't have a link handy, though. > 39 set -- $(LC_ALL=C ls -l "$SAVEDFILE") > 40 SAVEDSIZE="$5" > 41 if [ "$SAVEDSIZE" -gt "$POOLSIZE" ] > 42 then > 43 [ -w /proc/sys/kernel/random/poolsize ] && > echo $POOLSIZE > /proc/sys/kernel/random/poolsize > 44 POOLSIZE=$SAVEDSIZE > 45 fi > > Is there any place POOLSIZE can be configured, other than > these two? We can just drop poolsize entirely. None of the kernels we support allow changing the poolsize in the first place, not even at compile time AFAIK. As long as we store at least 512 bytes, it is good enough. More wouldn't hurt. And Linux doesn't care much for the size, it credits NO entropy to write operations (you need an ioctl to credit entropy), so you can toss any junk you want in there, at any size, and it will shuffle the pool but not add any entropy credit. I very much doubt freebsd will do anything usafe, but someone that knows their kernel guys better could ask and report back. > I’d be willing to clean up the init script a bit (also, add > reading the seedfile at shutdown before writing it, in case > someone wrote stuff there during the system runtime), if you > want. My qualification is that I worked on the random subsy- > stem in MirBSD (which contains of a kernel device by tytso, > similar to Linux’, plus start/shutdown scripts, plus an aRC4 > based additional pool, plus (in MirBSD) another pool where > non-root processes can contribute entropy) for a few years > and have read quite a bit on the topic. Well, the devil is in the details: failure modes, read-only /, and tricks to help idiotic setups with near-zero entropy and _zero_ variation among several boxes. Any help is appreciated. But do try to locate that thread and read it first. If I manage to find it in my archives, I will post a link to the archives as a reply. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#626725: Bug#626725: Bug#626720: SELinux refpolicy, initscripts and /run
On Thu, 09 Jun 2011, Roger Leigh wrote: > +Breaks: selinux-policy-default (<< 2:0.2.20100524-9) ... > + * initscripts Breaks all selinux-policy-default versions up to and > +including 2:0.2.20100524-9, which do not support /run. "<<" means STRICTLY LESS THAN for dpkg. If you need to ALSO break 2:0.2.20100524-9, as you wrote in the changelog, you should have used "<=". -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#577146: Bug#577146: Is halt the correct action?
On Thu, 19 May 2011, Elliott Mitchell wrote: > I'm not suggesting you don't want to get the system down, I'm wondering > whether "halt" versus "reboot" is the right target to have everything > setup for. I really don't understand what you want with all this. Please write a proper chart of events of the situation you're worried about, with an exact proposal of what you want changed. Once you are past the point of no return, the system *WILL* shutdown (or, if we wanted to cause data loss and changed that to a reboot, it WOULD reboot). There is no switching to something else just because power was restored, or the battery decided to malfunction, while the system was in the process of shutting down (or rebooting). And the point of no return is the exact moment you send INIT a signal to switch to initiate a change to the halt or reboot runlevels. > Two scenarios come to mind to ponder: > Power fails, everything is on UPS power. UPS power gets down to a > critical value, so the shutdown process starts. Moments later power You are past the point of no return. The system WILL shutdown, and that's it. > returns, but the shutdown process is already in progress. In this case, > you're only going to be down for moments (just long enough for the UPS to > charge some), and you've got something more akin to a reboot than a > "halt". No. The system is going to be stuck in the shutdown sequence for a while (let's hope a _small_ while), then it will be powered down UNTIL something powers the system back up. > Second case. Power fails, everything is on UPS power, but for the moment > UPS power is holding. Just now though, a scheduled reboot occurs due to > security patches or other condition. Moments after the reboot process has Do not initiate such actions during emergency power, then. > started, UPS power hits critical; suddenly you're set to be restarting, > but by the time the UPS monitor is up and running there may no longer be > enough battery to bring the system back down. Meanwhile, the scheduled > shutdown might have been a good opportunity to shutdown the UPS anyway. Either don't do that, or have enough time left in the UPS to last a lengthy reboot + fsck + whatever + shutdown. > I'm just pondering the situation, and ending up concluding runlevel 6 is > the right one to use for this, not runlevel 0. I guess my mental model > of "halt" is the system is going down for maintainance and won't be back > up until a *human* turns power back on. Whereas my mental model of > "reboot" is the system is going down "briefly" and will be back up as > fast as hardware (length of time for firmware memory checks, or battery > charge level) allows it to be. There is absolutely nothing I can answer to this that will not be either harsh. This insanity ends here. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#577146: Bug#577146: Is halt the correct action?
On Wed, 18 May 2011, Elliott Mitchell wrote: > When looking at bug #577146, the thought comes to mind; is halt the > correct action to do in case of power failure? You will be without power soon, but you have no idea how soon. And you don't have any idea for how long. Yes, halt (with poweroff) is about the only thing you can do that is even remotely safe. Fastpath shutdown would be safer, but we don't have it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#626725: Bug#626725: initscripts: Needs to set SELinux labels for /run
On Sat, 14 May 2011, Martin Orr wrote: > Directories and symlinks created as part of the /run transition are not > labelled for SELinux. The effect is that most services fail to start on > boot after transitioning to /run. > > You need to run restorecon after creating a directory or symbolic link > in an init script or maintainer script. Attached patch does this. > > /run with SELinux also requires the refpolicy patch I have submitted in > #626720. Once that is fixed, initscripts should probably have > Breaks: selinux-policy-default (<< $FIXEDVERSION) Don't we also need tmpfs with support for security attributes, for it to work (i.e. for labels to work inside /run)? Does squeeze 2.6.32 support such labelling? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#625820: Please let the user know when fsck'ing while booting -> machine looks dead
On Fri, 06 May 2011, Tomas Pospisek wrote: > >I suspect this bug really is in the kernel, and only affect some video > >cards. Which video card are you using? > > 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 >Integrated Graphics Controller (rev 0c) > > My machine is a HP Compaq 6710b (which is eeriely close to Petter's > intuition). Google tells me the Compaq 6910p has the same video > controller... > > Hats off Petter! Mmm, ok. So what do we do with this bug? Reassign to the kernel? Leave it around marked as wontfix? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#625820: Bug#625820: Please let the user know when fsck'ing while booting -> machine looks dead
On Fri, 06 May 2011, Tomas Pospisek wrote: > Synopsis: > = > when the machine does an fsck while booting, there's no way to know. > The user should be informed of the fact otherwise she has no way to > know whether the machine is dead or not. Hmm? It is, fsck outputs everything to all active consoles. > Lately, while rebooting, my machine just stayed black. Nothing was > happening except for the disk drive LED being on. Didn't it show the BIOS screen? I have no idea of what's happening to your box, but it is something more basic and insiduous than a quiet fsck. We do not DO quiet fsck in the first place, AFAIK. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#499796: Bug#499796: initscripts: rootfs over nfs hangs at reboot
On Thu, 14 Apr 2011, Bastian Blywis wrote: > When /etc/init.d/reboot is run and "reboot -d -f -i" called, in about > 2-4% of the cases, the system will deadlock because the network > interfaces are shut down but the kernel still wants to read/write > something on the nfs export. The message "nfs server not responding" is > shown. > > Solutions: > 1) remove the "-i" from the init script > 2) move the parameters to /etc/default/reboot Which can change wake-over-lan behaviour on various NICs, so it is not something we can do lightly. Although documenting this is a damn good idea. Really, all disk activity is supposed to be quiesced at this point, and everything is to be re-mounted read-only, so NFS should not need to do anything it cannot just give up on doing. Maybe that's where the real bug lies? Can you track down what is still mounted read-write at this point on your root-over-NFS boxes? Use /proc/mounts for this. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] Bug#599430: Announce of the upcoming NMU for the sysvinit package
On Tue, 05 Apr 2011, Christian PERRIER wrote: > I have actually been surprised of not getting any answer to this "NMU > intent". I don't really intend to NMU sysvinitat least not until I > get a quite clear ACK from its maintainers. We're not talking about a > random package here..:-) It was implicit approval, I think :-) > So, I assume that my mails indeed felt under you guys' attention..:-) I for one did read it, and I had nothing against your NMU so I didn't speak up. All we ask is for a clean chroot to be used in the build, just in case, and that you do some minimal testing of the package before you upload (assuming you really need to touch only po/translation files). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#613618: Bug#613618: sysvinit: init emits warning when we don't have getty in /etc/inittab
reassign 613618 ngetty thanks On Wed, 16 Feb 2011, NIIBE Yutaka wrote: > I am using ngetty (1.1-2) which doesn't use /etc/inittab > but invoked by /etc/init.d/ngetty. I suggest you invoke the master ngetty from init, instead. > Since ngetty works differently than traditional getty, we don't need > entries in /etc/inittab; single ngetty process watches all ttys > and login processes simultaneously, and it runs forever. And nothing ressurects if should it die or get killed by mistake/OOM killer/memory corruption. That is not resilient. > Perhaps, init assumes that it needs to watch some processes (such as > getty) to be respawned. But using ngetty, I don't have any such > processes. I think it is on the sysv init design, yes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#612594: Bug#612594: Bug#612594: On boot thw wait have no job to wait for, and fail into reboot.
On Wed, 09 Feb 2011, Henrique de Moraes Holschuh wrote: > Erez, could we impose on you to remove the usplash package (not purge, just > remove) and check if the problem disappears (please revert your workaround > first)? Erez replied over private email that yes, just removing usplash is enough to avoid the problem. So, I'd say we should conflict with usplash and upload something to squeeze-proposed-updates. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#612594: Bug#612594: On boot thw wait have no job to wait for, and fail into reboot.
On Wed, 09 Feb 2011, Erez Geva wrote: > Do not have any output since it occurs during boot proccess. > The /lib/init/usplash-fsck-functions.sh rechechs line 169: > However the wait have no job to wait for though fail into fake maintainance > login. > When finnish the maintainance, and exit a reboot is preformed. > But after rebood I get the same fake maintainance login. "fake"? > The follow patch is bypass to the problem. The correct fix is to purge usplash and all other such broken hacks from hell from the system. I don't know what to do about this bug, I have this hunch we need to add something to the initscripts or sysv-rc package in the next stable release to make sure usplash is _gone_, but since you actually have to purge usplash to make sure it can do no damage (so as to get rid of the conffiles), it might not be enough. This might require testing. Erez, could we impose on you to remove the usplash package (not purge, just remove) and check if the problem disappears (please revert your workaround first)? It is also probably a good idea for you to use aptitude to locate all "local packages", i.e. those which are not in the Squeeze package lists, and try to get rid of any cruft there that is not of vital importance to you. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#582442: Bug#582442:
On Wed, 15 Dec 2010, Tommy van Leeuwen wrote: > Is there any workaround available for this bug? We really need to be > able to interrupt the boot process. Yes, disable concurrent boot. It is what I have done on all my boxes and set as policy for all servers at work. Right now, it is more trouble than it is worth when things go wrong, even on my laptop :( -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#607269: Bug#607269: initscripts: upgrade from lenny to squeeze left system unbootable as checkfs.sh failed to execute
On Thu, 16 Dec 2010, Andreas Wohlfeld wrote: > I don't know where I've picked up the missing bits (system was migrated > from Debian 1.3 over the years), but they are not getting corrected when > installing new package versions, which caused the problems here. > > Maybe they should be checked as clearly /etc/init.d/rc has changed behavior. Removing the x bit is a documented way to get the initscript not to execute (frowned upon unless you use dpkg-statoverride, though, since it can break on upgrades). I suppose we could add some testing and warn users if we detect missing x bits, but unless etch or lenny installs are affected, it may be more trouble than it is worth. I have several systems that have been constantly upgraded from sarge, and none of them had any x missing bits. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#526398: Bug#526398: ping
On Thu, 02 Dec 2010, auto19412...@hushmail.com wrote: > Is this bug being kept in Debian Stable (lenny) for a particular > reason? Nobody got around to backporting the fix to stable. NMU patch welcome. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#601756: Bug#601756: Please remove noisy runlevel time measuring
On Fri, 29 Oct 2010, Daniel Baumann wrote: > please remove the noisy runlevel time measuring. patch will be sent as > soon as the bug number is assigned. FWIW, I also think that measurement is not very useful, and it does the wrong thing too easily, since we are not using something that calls clock_gettime(CLOCK_MONOTONIC,...). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] Bug#601757: Bug#601757: Please mount cgroup automatically
On Fri, 29 Oct 2010, Daniel Baumann wrote: > attached is the patch. [...] > + domount cgroup "" /sys/fs/cgroup cgroup -onodev,noexec,nosuid I like it. Is this mountpoint "blessed" by someone, since it is inside /sys? Are other distros also using this path? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] fundamental properties of entropy
On Wed, 15 Sep 2010, John Denker wrote: > a) Suppose I shuffle a deck of cards, and ask you to figure > out the order of the cards. The entropy in this situation > is the logarithm of 52 factorial, which is just under 226 > bits. You can figure out the order by asking 226 yes/no > questions. > > b) Suppose I prepare two decks of cards by shuffling one > and then stacking the other into the exact same configuration. > If we throw away deck #1, the entropy of deck #2 is 226 bits. > If we throw away deck #2, the entropy of deck #1 is 226 bits. > The situation is symmetrical with respect to which deck is > which. Last but not least, if we keep both decks, the entropy > of both of them together is 226 bits. Does the 226 bits of entropy on scenario (b), when we keep both decks, depend on our knowledge that both decks are in exact the same configuration? I'd say that no, it doesn't. It is always going to be just 226 bits of entropy, because the correlation between the decks will always exist even in a scenario where such correlation cannot be known because information about one deck is not going to reach observers of the other deck. > This proves that entropy is not an extensive quantity. It is > context-dependent. We can, at some time, find a correlation between two RNGs, and that knowledge will force us to re-evaluate the real entropy available from that set of (now known to be correlated) RNGs. The question which will make a lot of people uneasy is: did we had the wrong idea about the real entropy available from the set until we found out about the correlation? Suppose that no observer knew of that correlation, either. > Some people find this confusing or even disturbing, but it is > a well-established fact of nature. For details on all this, > see > http://www.av8n.com/physics/thermo/entropy.html#sec-card-game I'll read that text, I am very sure I will learn something from it :) > There is a fundamental principle in the cryptography / security > business says that you cannot make something secure by throwing > together a whole bunch of insecure elements. You can make it > complicated, but you cannot make it secure. This has been > discussed and documented, in connection with RNGs and otherwise, > in various places including Knuth _TAoCP_ Yes. However it is not impossible to increase the required effort by an attacker through a bunch of insecure elements. In that case, you did not make the system secure, but you did raise the bar. If it is unknown how much you raise the bar, it is going to be considered of dubious value security-wise, and caution would speak against including such insecure elements in that case. One example is using a clock to shuffle an entropy pool. By itself, it is never going to make that entropy pool secure. Even if there are no external observers of that clock, there will be external observers of its indirect effects on the output of the RNGs driven by the pool. The information leak is there, so it is not secure. But it made the attacker's life a bit more difficult if his attack was based on a known initial state of the pool, he now needs also something about the state of the clock, and he will spend resources trying to determine it. I suppose (my math is NOT good enough for this) that there are some attacks that are NOT going to be made any more difficult by an input that has no entropy. But if it makes a set of cheap attacks harder, it did have some value. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
Re: [Pkg-sysvinit-devel] fundamental properties of entropy
On Wed, 15 Sep 2010, John Denker wrote: > > Part 1: enough stored entropy to use as "seed material" (4Kib for Linux) > > that is unknown to the attacker. > > > > Part 2: something that is unique to this specific device among all others. > > > > Part 3: something that is provably different each time this specific device > > is rebooted, i.e. each time there has been an irreversible loss of state. > > There are two possibilities: > > a) If the stored material in Part 1 is unique on a per-machine > basis, Part 2 is pointless. However, that thread was not a theory, but an engineering thread. Part 1 is assumed to have malfunctioned (we have more failure modes that can cause it than I would care to list), or we would have no need for anything else, indeed. BTW, part 1 IS what we currently have. Only, it happens somewhat later in the boot process than I'd like. > b) If the stored material in Part 1 is cloned from machine to > machine, this doesn't make sense, because it is not entropy. But that's what happens when people copy live-CDs/DVDs or VM images around, etc. Part 1 is either missing, or non-unique (and known) at least on the first boot, or invariant... > Calling it "stored entropy" does not make it so. It is not > entropy and it is not secure. Adding Part 2 and/or Part 3 > cannot make it secure. Which was addressed in the thread. Part 2/3 are NOT about security, they're about keeping some variance on the data retrieved from the random-numbers kernel subsystem across reboots of the same real-entropy-starved device, and also on syncronized boots of several nearly-identical real-entropy-starved devices. > There is a fundamental principle in the cryptography / security > business says that you cannot make something secure by throwing > together a whole bunch of insecure elements. You can make it I am well acquinted with that... > I started a new thread because I am happy to have a wide-ranging > discussion of fundamental principles of security, cryptology, > and physics ... but I don't want it to be mistaken for a review > of the recently-submitted patches. Ok, so other replies better stick to just the beggining of your post (which I didn't reply to, as this subthread should not continue). > I reckon that understanding the fundamental properties of > entropy may be a prerequisite for reviewing the patches, but > it is not the same thing. In that we agree fully... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
