On 2024-02-08 14:12, Mark Hindley wrote:
What are your thoughts? Is this something you can improve or address upstream?
I agree, the suggested out from Jakob makes more sense and would be more
useful.
I will look at insserv's code and see how it handles this. I'm not sure
if this is a
Thank you, I'll add this patch upstream for the next version.
- Jesse
On 2023-08-19 4:28 p.m., Mark Hindley wrote:
> Control: tags -1 pending patch
>
> Lucas,
>
> Thanks for raising this. Fixed version is pending.
>
> Jesse,
>
> My patch for man/Makefile to fix the clean recipe is attached.
>
> I think I have found the offending commit:
> 0b695c7e0b1cac60ed77c56f224e296f023b652e uses memset *after* realpath which
> wipes
> the canonical resolved path.
>
> I suggest this fix as a starting point.
>
I'd agree. I was running into some situations where a symlink wasn't
recognized
On 2023-03-28 10:56 a.m., Markus Fischer wrote:
> I did a few more tests of my own and didn't find any other issues.
>
> - Markus
>
Thank you. I'm planning to do the same and then publish an update to
sysvinit.
On 2023-03-28 10:40 a.m., Mark Hindley wrote:
> On Thu, Mar 23, 2023 at 11:25:02AM -0300, Jesse Smith wrote:
>>> $ ls -l $(which vi)
>>> lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi ->
>>> /etc/alternatives/vi
>>> $ ls -l /etc/alternatives/vi
>&
On 2023-03-24 6:44 a.m., Markus Fischer wrote:
> I think I've figured it out. With the following patch I don't see the
> unexpected behaviour anymore:
>
> --- a/src/killall5.c
> +++ b/src/killall5.c
> @@ -662,6 +662,7 @@ int readproc()
> /* Try to stat the executable. */
>
On 2023-03-23 12:04 p.m., Markus Fischer wrote:
> I could also reproduce it with emacs. I've used emacs-gtk to avoid the
> symlink.
>
> ```shell 1
> $ emacs-gtk -nw -fn helvetica
> ```
>
> ```shell 2
> $ ./pidof emacs-gtk
> 24727
> $ ./pidof $(which emacs-gtk)
> $ ls -l $(which emacs-gtk)
>
On 2023-03-23 11:36 a.m., Markus Fischer wrote:
> Alright. Then there is still the issue with gdb, which is no symlink.
> A full example for that:
>
> ```shell 1
>
> $ type gdb
> gdb is /usr/bin/gdb
> $ gdb --core=corefile
>
> ```
>
> ```shell 2
>
> $ ./pidof gdb
> 23125
> $ ./pidof $(which gdb)
>
On 2023-03-23 11:20 a.m., Markus Fischer wrote:
> ```shell 1
>
> $ type vi
> vi is /usr/bin/vi
> $ vi
>
> ```
>
> ```shell 2
>
> $ cd ~/src/sysvinit-upstream/src/
> $ ls -l pidof
> lrwxrwxrwx 1 ivanhoe ivanhoe 8 Mar 22 14:56 pidof -> killall5
> $ ./pidof vi
> 21945
> $ ./pidof $(which vi)
> $ ls
gt; I also noticed that as with vi above, when gdb was run as root "pidof
> $(which gdb)" works as expected with both 3.06 and 3.07.
>
> - Markus
>
>
> Am 22.03.23 um 16:38 schrieb Jesse Smith:
>> On 2023-03-22 8:31 a.m., Mark Hindley wrote:
>>> Markus,
&
On 2023-03-22 8:31 a.m., Mark Hindley wrote:
> Markus,
>
> Thanks for this.
>
> On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote:
>> Package: sysvinit-utils
>> Version: 3.06-2
>> Severity: normal
>> X-Debbugs-Cc: none
>>
>> Dear Maintainer,
>>
>> Passing the full path of a binary to
On 2023-03-22 8:31 a.m., Mark Hindley wrote:
> Markus,
>
> Thanks for this.
>
> On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote:
>> Package: sysvinit-utils
>> Version: 3.06-2
>> Severity: normal
>> X-Debbugs-Cc: none
>>
>> Dear Maintainer,
>>
>> Passing the full path of a binary to
On 2023-01-05 5:40 p.m., Américo Monteiro wrote:
> A quinta-feira, 5 de janeiro de 2023 17:52:03 WET Jesse Smith escreveu:
>> On 2023-01-05 12:57 p.m., Mark Hindley wrote:
>>> Control: tags -1 upstream
>>>
>>> Américo,
>>>
>>> On Wed, Ja
On 2023-01-05 12:57 p.m., Mark Hindley wrote:
> Control: tags -1 upstream
>
> Américo,
>
> On Wed, Jan 04, 2023 at 10:16:31PM +, Américo Monteiro wrote:
>> Package: sysvinit
>> Version: 3.04-1
>> Tags: l10n, patch-
>> Severity: wishlist
>>
>> Updated Portuguese translation for sysvinit's
On 2023-01-05 12:57 p.m., Mark Hindley wrote:
> Control: tags -1 upstream
>
> Américo,
>
> On Wed, Jan 04, 2023 at 10:16:31PM +, Américo Monteiro wrote:
>> Package: sysvinit
>> Version: 3.04-1
>> Tags: l10n, patch-
>> Severity: wishlist
>>
>> Updated Portuguese translation for sysvinit's
wrote:
> Hello Jesse,
> On Fri, Dec 23, 2022 at 04:14:50PM -0400, Jesse Smith wrote:
>> Please email me the file. Every time we do a git pull request or merge
>> it breaks the man/ directory and it's a mess to try to revert. I'll
>> commit it directly instead of merging/patchi
Please email me the file. Every time we do a git pull request or merge
it breaks the man/ directory and it's a mess to try to revert. I'll
commit it directly instead of merging/patching.
- Jesse
On 2022-12-23 4:08 p.m., Helge Kreutzmann wrote:
> Hello Jesse,
> in our Debian overview I just saw
Thanks for the update.
Having a Debian package (even an unofficial one) would be nice. I can
still post install instructions for it in our README file.
Is it possible to rename the existing package or add warning to it to
let people know the "doas" package in Debian is actually OpenDoas and
not
On 2022-04-17 11:49 a.m., Scupake wrote:
> Hello,
>
> I'm very very sorry for taking an unreasonable time to reply and resolve
> this issue. I will try to be more active from now on.
>
> I'm also currently packaging slicer69/doas, though I still haven't
> decided on a name, I would like to use
This issue has been open for several months now without an update and
I'd like to encourage its resolution. The upstream doas project is still
getting issue reports [1] which are resulting from confusion in the
naming between "doas" versus "OpenDoas". Ideally this package should
have its name
> While creating the Po4a framework, I found many issues in the man
> pages worth to fix. See the attachment. As a temporary playground,
> I've forked the Savannah repo at Github [1], where you can also view
> the patch [2]
>
> [1] https://github.com/mariobl/sysvinit
> [2]
>
On 2021-12-25 3:35 p.m., Mario Blättermann wrote:
> OK, it is in my favor to both keep existing man page translations
> alive (acknowledging the work of the previous translators) and
> integrate Po4a-based translations into upstream projects, instead of
> maintaining them in an external
On 2021-12-22 1:26 p.m., Mark Hindley wrote:
> Control: tags -1 patch
>
> Helge,
>
> On Wed, Dec 22, 2021 at 05:27:34PM +0100, Helge Kreutzmann wrote:
>> clone 1001908 -1
>> reassign -1 sysvinit-core
> Thanks for this.
>
>> Yes, this is the first bug, and it is in the original man page from
>>
On 2021-11-28 10:08 a.m., Scupake wrote:
> I like the idea of giving slicer69/doas a diffrent name, I still haven't
> decided on a name yet so I'll work on renaming this package to "opendoas".
>
> Thanks a lot and sorry for the late reply.
>
Thanks for the update and for changing this package's
Thanks very much for getting back to me and being open to discussing the
labelling for this Debian package.
> I considered naming this package "opendoas" but thought that users might
> not realize that that a version of doas is packaged under that name.
I can see why you'd take that approach.
On 2021-11-01 4:23 p.m., Mark Hindley wrote:
> -- System Information:
>> Debian Release: 11.0
>> APT prefers unreleased
>> APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500,
>> 'unstable'), (100, 'experimental')
>> Architecture: x32 (x86_64)
>> Foreign Architectures: i386, amd64
Package: doas
Version: 6.8
I believe the Debian package "doas" should be renamed to "opendoas". The
upstream project Debian packages is called "OpenDoas" [1] and it is a
competing port to another project called "doas" [2] that has similar
functionality. However, the two tools are not entirely
On 2021-10-22 6:52 p.m., Svante Signell wrote:
> Hi Jesse,
>
> On Thu, 2021-10-21 at 14:51 -0300, Jesse Smith wrote:
>> Please give the attached patch a try and confirm it's working. It's
>> working here for normal and zombie processes and it seems to be okay
>>
> The RedHat bug that was the similar issue to #719273 (i.e. that
> resulted in the behaviour of pidof being changed) took a slightly
> different approach -
> https://bugzilla.redhat.com/show_bug.cgi?id=138788 (patch is
> https://bugzilla.redhat.com/attachment.cgi?id=113650=diff );
> did that
On 2021-10-21 1:40 p.m., Matthew Vernon wrote:
> Hi,
>
> On 20/10/2021 15:29, Jesse Smith wrote:
>> Is there a reason for wanting to revert this behaviour instead of using
>> the "-z" flag on the command line? If you use pidof a lot and expect to
>> see proc
On 2021-10-20 4:59 p.m., Mark Hindley wrote:
> I am unclear as to the significance of the reordering of .depends.* that
> happens on the first run. Jesse, is that expected. Does it point to something?
I suspect the initial reordering probably indicates one of two things:
1. There is something
Is there a reason for wanting to revert this behaviour instead of using
the "-z" flag on the command line? If you use pidof a lot and expect to
see processes that are in the uninterruptable sleep state then making an
alias of pidof='pidof -z' seems like a straight forward approach.
Reverting the
On 2021-09-26 8:55 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> I checked out the init.d directories provided by Thorsten. One of the
>> features of insserv allows it to test init scripts in an alternative
>> directory or chroot.
> This see
On 2021-09-26 8:55 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> I checked out the init.d directories provided by Thorsten. One of the
>> features of insserv allows it to test init scripts in an alternative
>> directory or chroot.
> This see
On 2021-09-26 3:25 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> behaviour. I've tried both the latest version of insserv (1.23.0) and
>> the version which shipped with Debian 10 (1.18.0). I did notice having
> This is Debian 11 so 1.21.0-1.1 (inc
On 2021-09-26 2:37 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> did last time. This time please run"
>>
>> # insserv -v -s
>>
>> This should set avahi-daemon to K01. Then run
> Erm, well, it doesn’t. Apparently, the presenc
On 2021-09-26 1:54 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Jesse Smith wrote:
>
>> Something that might be useful here is seeing the output from "insserv
>> -v -s -n". This will show in what order insserv intends to assign each
>> service in each
On 2021-09-26 1:12 p.m., Thorsten Glaser wrote:
> On Sun, 26 Sep 2021, Mark Hindley wrote:
>
>> Thorsten's original report[1] suggests it happens on every upgrade.
Not only every upgrade, but if I'm reading the report correctly it looks
like insserv is toggling between K01 and K02 with every time
On 2021-09-26 7:10 a.m., Mark Hindley wrote:
> Jesse,
>
> On Mon, May 31, 2021 at 04:40:17AM +0200, Thorsten Glaser wrote:
>> Package: insserv
>> Version: 1.21.0-1.1
>> Severity: normal
>> X-Debbugs-Cc: t...@mirbsd.de
>>
>> I believe this is insserv; if not, feel free to reassign.
>>
>> With every
I was a little confused by the subject of this bug since this has
nothing to do with systemd. Neither the script nor the init call has any
connection to systemd.
The issue here is that the init script (/etc/init.d/single) is trying to
call SysV init with the "-t1" flag, which is not valid. There
On 2021-02-19 4:38 a.m., Matthew Vernon wrote:
> On 15/12/2020 21:34, Jesse Smith wrote:
>> On 2020-12-15 5:04 p.m., Trek wrote:
>>> On Tue, 15 Dec 2020 12:45:40 -0400
>>> Jesse Smith wrote:
>>>
>>>> I gave the patch a test run and, while I l
On 2020-12-15 5:04 p.m., Trek wrote:
> On Tue, 15 Dec 2020 12:45:40 -0400
> Jesse Smith wrote:
>
>> I gave the patch a test run and, while I like what it does in theory,
>> in practise I'm running into trouble with it. When I use the attached
>> patch and then run
On 2020-12-15 11:31 a.m., Trek wrote:
> @Jesse Smith: I attached a possible fix, but it slightly changes the
> behavior, as now it prints the overlapping warning when loading all the
> init.d scripts and not only for the ones in the commandline
>
> this because if script_in
The behaviour described, pidof not seeing processes in the "D" state, is
expected, correct, and documented in the pidof manual page. As it says
in the manual page, if yo uwant to see processes which are
uninterruptable or zombies then it is required to pass the "-z" command
line flag.
- Jesse
I'm the upstream maintainer for Sopwith. I'd like to point out that
while Sopwith _can_ use GTK2 for its graphical interface, the preferred
method as been SDL for several years. We had too many problems with GTK2
and deprecated it as a front-end. Sopwith does not have a hard
dependency on GTK and
David,
I appreciate you doing some clean-up on the code and addressing the
zombie/sleeping process issue.
When I was applying the patch the part addressing the missing zombie
process did not apply and when I looked closer at the code it appears
that you are fixing is something that was already
On 10/22/19 11:07 PM, Hoyer, David wrote:
> We have also been experiencing this problem since moving to Buster. We
> never saw this with Jessie. I believe it comes down to the following code
> in readproc:
>
> if ( (strchr(process_status, 'D') != NULL) ||
>
> Jesse,
>any ideas how it could be possible for process to be discovered by
>ps(1), but not pidof(1)?
>
I can think of a few possibilities, though they seem unlikely. One is
that the process could be crashing and restarting, making it a zombie
for brief periods of time. Testing pidof
On 10/13/19 4:33 PM, Michael Biebl wrote:
> Control: tags -1 + moreinfo
>
> On Sat, 28 Sep 2019 15:21:17 -0300 Jesse Smith
> wrote:
>> This has been addressed upstream in insserv by allowing the program to
>> accept changes like this silently. All we need now is for upda
This has been addressed upstream in insserv by allowing the program to
accept changes like this silently. All we need now is for update-rc.d to
be updated to use the new behaviour (enabled with the -q flag) and this
issue can be closed.
- Jesse
I have tried to duplicate this issue with Debian 9 and have been unable
to duplicate the tty issue. Seems this was fixed in a release since the
report. Unless someone can duplicate this issue with a current version
of Debian/init, I suggest this report can be closed.
- Jesse
When I applied the patch provided above it causes insserv to segfault
when running the testsuite (make check). Looks like the program is
crashing using one of the LSB header checks. I haven't looked into it in
any detail yet, but it seems moving that check to a sooner point causes
a memory issue.
On Sun, 25 Aug 2019 16:07:30 + Dmitry Bogatov wrote:
> > > Each line a process sends:
> > > * should be prefixed by the name of the process that sent it.
> > > * should end with a newline.
> >
> > And (#398269) each line should be either from a process or the kernel,
> > distinguishable
>> @Jesse Is is possible to specify dependencies between two scripts
>> that both depends on $all?
What we might consider is adding new expandable dependency variables to
insserv.conf. We already have things like $all, $time and $network.
Maybe we need another variable like $rc-local to better
On 8/23/19 8:22 AM, Dmitry Bogatov wrote:
>
> control: tags -1 +confirmed
> control: reassign -1 initscripts
> control: severity -1 normal
>
> [2019-08-21 15:22] Thorsten Glaser
>> Package: insserv
>> Version: 1.20.0-2
>> Severity: minor
>>
>> Unsure which package, but:
>>
>> [???]
>> Starting
I looked at the documentation and the examples provided here and they
are working as documented. I don't think there is a bug here.
Now, in theory, it might be nice to have a flag which prevents old .orig
files from being overwritten. I can see how that would be beneficial.
But the examples
control: tags -1 +fixed-upstream
This issue has been fixed upstream and will be resolved in startpar-0.64.
- Jesse
On 8/17/19 3:29 PM, Ian Jackson wrote:
> Jesse Smith writes ("Bug#934945: startpar: insserv attemps to write to
> /etc/.boot.* even with -p option"):
>> The change has been made upstream so this should be fixed when the next
>> version comes out, probably around the
On 8/17/19 2:14 PM, Ian Jackson wrote:
> Jesse Smith writes ("Bug#934945: startpar: insserv attemps to write to
> /etc/.boot.* even with -p option"):
>> On a related note, in the startpar build log it shows the version of
>> startpar being tested is located at /lib
> Folks, we have serious regression. Not sure, whether it is bug in
> startpar test suite, which invokes `insserv' with `-p', but without
> `-i', or it is regression in `insserv'.
It's sort of a fore-gression. The Startpar testsuite was set up to work
with older versions of insserv, like
On 8/13/19 2:06 PM, Dmitry Bogatov wrote:
> [2019-08-12 17:45] Jesse Smith
>> Certainly. Attached is a file with the last 20 lines of the
>> /var/boot/log file on a test machine. When I view the log with "less"
>> the output looks normal. When I run the file t
On 8/12/19 4:30 PM, Dmitry Bogatov wrote:
> [2019-08-11 18:08] Jesse Smith
>>> No. When you output raw escape sequences on terminal, they will be
>>> interpreted by terminal, so `head', `tail' and `grep' output will be
>> readable and colored. Pager `less' with -R o
On 8/12/19 4:20 AM, Vincent Lefevre wrote:
> On 2019-08-11 17:57:18 -0300, Jesse Smith wrote:
>> For situations like this where you already have a log with escape
>> characters in it, you can fix the output by using the readbootlog
>> program, which is part of the sysvinit
On Sun, 11 Aug 2019 17:47:17 + Dmitry Bogatov wrote:
> > I'd like to point out though that with such an option enabled, it is
> > going to result in some weird output. If all escape sequences are
> > printed to the file, tools like "less" can handle it, but other (more
> > raw) text
> Please, don't. Issue with '\r' can be resolved by removal of '\r' in
> `bin:lsb-base'.
Okay, I'll do an option for completely unfiltered and other tools and be
adjusted to match.
> With filtering as implemented now `/var/boot/log' looks bad both in editor
> and terminal. Example:
>
> Fri
On Thu, 08 Aug 2019 20:21:50 + Dmitry Bogatov wrote:
>
> control: tags -1 +upstream
>
> [2019-08-07 05:13] Adam Borowski
> > [...]
> > > a /var/log/boot.log file is
> > > generated where nothing is filtered out, so that the file is readable
> > > with "cat" or "less" (and text is colored).
> >
I'm not entirely sure, but based on the information provided here it
looks like there may have been an override file in place which later got
removed.
If this bug is still occurring and/or reproducible then I'll happily
look into it. However, if it is not longer happening then I suspect this
was
I have looked into this and, as Dmitry pointed out, there were a few
things amiss with the test suite.
1. There was the way the test script was being created on the fly. I
have addressed this by creating a standalone file in the testsuite
directory.
2. Multiple tests were being run, but this was
I have added a silent mode flag for insserv. Running the program with
either "-q" or "--silent" will surpress most warning messages. insserv
will only print fatal errors, when it is about to exit, when in silent mode.
A patch for the new behaviour is attached. Maybe we can get update-rc.d
patched
This is an interesting issue. I think this is what is happening:
1. update-rc.d wants to disable the osspd service. To do this is creates
a file called /etc/init/osspd.override.
2. update-rc.d then calls insserv. insserv sees that the osspd script
normally starts in runlevels "2 3 4 & 5", but
The assumption here, that the user can run "make check
insserv=/sbin/insserv" and have it run the testsuite against the
installed binary is correct. This does work.
The problem encountered in the bug report is an older version of insserv
is installed at /sbin/insserv. The older copy does not
On Sun, 17 Apr 2011 20:09:40 +0200 Thomas Hood wrote:
> I have just reassigned this report from resolvconf to
> insserv because I believe that the insserv maintainers
> will have more insight into the problem than I have.
>
> Here is a summary of what we have found out, as
> described earlier in
The patch has been applied upstream and will appear in insserv 1.21.0.
- Jesse
I have added an initialization for the "tail" variable. I also make the
error more verbose and put in an exit() call in case we are unable to
allocate any memory. It's a bit crude, but I figure if we ever run into
a situation where we can't allocate a tiny structure, the system has
bigger issues
This issue appears to be fixed in recent versions of Debian, such as
Jessie and Stretch. Suggest it can be closed.
- Jesse
On Wed, 23 Mar 2011 09:33:46 -0700 Josh Triplett wrote:
>
> insserv generates makefile snippets in /etc/init.d/.depend.* with
> dependency information for init scripts. This doesn't represent
> configuration information, nor can the user modify it. Thus, it should
> go somewhere else on the root
As an update on this bug, since /var may not be mounted at boot time,
causing startpar to fail, this change has been reverted upstream. I am
going to suggest this bug can be closed.
- Jesse
On Thu, 23 May 2019 16:27:00 + Dmitry Bogatov wrote:
>
>
> Also, every WITH_FOO flag doubles number of configurations your program
> have. Once you have dozen of flags, you no longer can test all of
> configurations.
Why not?
>
> I am surprised, that there is so much controversy on whether
On Wed, 22 May 2019 13:28:39 +0200 (CEST) Thorsten Glaser wrote:
>
> (I’m not quite convinced the effort is worth it, but given that
> this would be changed upstream, and that there are likely other
> users of the same upstream code who’re _not_ using SELinux, this
> would be very welcomed by
On 5/22/19 11:57 AM, Thorsten Glaser wrote:
> On Wed, 22 May 2019, Jesse Smith wrote:
>
>> I don't think removing the SELinux dependency from init actually saves
>> us any RAM. Several other services link to these libraries too, so the
> Maybe, maybe not. (I’m fairly sure I’ve
On 5/21/19 8:45 PM, Dmitry Bogatov wrote:
> [2019-05-18 16:14] Jesse Smith
>> From a practical perspective, I'm curious if there is any benefit or
>> drawback. Is this patch fixing a known bug,
>> does it significantly reduce the size of PID 1 in memory?
> Not that I real
I brought this up in bug #601054 as well, but thought I'd mention it
here since this seems to be the same issue. Upstream we're experimenting
with using /var/lib/insserv/ as the location for storing boot-time
dependency data. However, I'm not sure we can rely on /var being mounted
when startpar
This has been done upstream and is now in the latest beta release [1].
Something I'm curious about is: what happens if /var is not mounted when
startpar runs? Let's say /var is on another disk, or mounted over NFS.
What then? I'm guessing some people are using a setup where /var is not
on the
I've looked over the patch and the logic seems straight forward enough.
Philosophically, I can see arguments for doing this (simplify the core
of init, remove a dependency) and against this idea (it adds a new
program to the sysvinit package and start-up process). So from a
philosophical stand
This feature has been added upstream and will be featured in
insserv-1.20.0. The manual page will provide instructions for how to
set up file extensions to be filtered automatically when insserv runs.
- Jesse
I believe this issue has been fixed. We have a test script which checks
for script dependencies with "$all" and it passes. This report can
probably be closed.
- Jesse
I'm not sure I agree that insserv should completely abort when an unmet
virtual dependency is unmet. There could be cases where one facility is
missing, but its function is provided by another service.
I do agree though that insserv should not silently fail. With this in
mind, I have patched
I went through the test suite and identified places where either the
test suite was probably out of date (or working with old documentation)
or insserv was giving improper results. Most of the test cases which
were failing can, I believe, be addressed by warnings rather than
outright failures or
On 5/1/19 7:42 AM, Dmitry Bogatov wrote:
> [2019-04-28 21:05] Jesse Smith
>> I have been looking into the issues with the insserv test scripts. There
>> are a few problems here, in brief:
>> [...]
>>
>> In other words, I think there is some difference in exp
I have been looking into the issues with the insserv test scripts. There
are a few problems here, in brief:
1. The test scripts were looking in the old area for insserv output and
missing some dependency information that way. I should have updated them
earlier. (This has been fixed.)
2. The
Thanks for the ping, I did not see this one come in for some reason.
I have added the testsuite to the Makefile's "check" target and
addressed the unset variable issue.
Going through the tests, figuring out which ones are failing and why
will take a little longer. Or, for that matter, there may
On 4/11/19 7:43 AM, Dmitry Bogatov wrote:
> [2019-01-24 19:42] Jesse Smith
>> I'm looking into this bug in insserv and want to make sure I'm
>> understanding the issue correctly. As I read it, the problem is that if
>> the user specifies the same runlevel in both the Default
>> When update-rc.d calls insserv, the rcN.d directories are rebuilt
>> without taking into consideration any adjustment that might have
>> been set up locally. That seems to be done on the assumption that
>> the dependencies coded in the LSB blocks are universally accurate.
>> Now, LSBs are a
On 4/8/19 12:38 PM, Dmitry Bogatov wrote:
> control: tags -1 +upstream
>
> [ Please keep attribution ]
>
> [2019-04-07 11:12] Jesse Smith
>>
>> That is what halt means - to stop running the system without powering
>> off.
> Maybe, but many of us are
> Halt action is to halt or drop into boot monitor on systems that
> support it." is not enough to convey, that in many cases it brings
> machine into state, when it is still on, display still showing
> letters, but no interation (except physical poweroff) is possible.
That is what halt means -
I have removed the "-f" flag for formatting (and the custom string
substitution patch). It has been replaced by the patch from KatolaZ
which allows for a custom field separator. This has been applied
upstream in the 2.95 branch.
- Jesse
On 3/19/19 7:28 PM, KatolaZ wrote:
> On Tue, Mar 19, 2019 at 05:54:56PM -0300, Jesse Smith wrote:
>> I am certainly open to replacing the "format" flag (-f) with an
>> alternative field separator flag. It has a nice Unixy feel to it and
>> requires less code.
>
I am certainly open to replacing the "format" flag (-f) with an
alternative field separator flag. It has a nice Unixy feel to it and
requires less code.
Personally, I think using -d (or --delimiter) might be the only change
I'd want to make to the patch KatolaZ provided. Partly because pidof
I have been playing around with this a little and believe I have come up
with a workable solution. The attached patch causes the passed in format
string to be dumbed down so that we only translate instances of %d into
the PID and \n into newline characters. Everything else is treated as a
literal
> Wouldn't you need to have some process which was passing untrusted data
> directly to the `-f` argument, is that likely in the real world?
It may not be likely, but anything that makes a command line tool crash
or output weird data after being fed unfiltered command line input is
not a good
1 - 100 of 214 matches
Mail list logo
