On 2025-03-05 04:19, Mark Hindley wrote:
Control: tags -1 upstream
Jessie,
I know this has been dormant for a long time, for which, apologies.
On Sat, Jul 13, 2019 at 08:29:26AM +, Dmitry Bogatov wrote:
I thing we already have everything needed. Essentially, insserv
impements topological
On Wed, 5 Mar 2025 08:10:55 + Mark Hindley wrote:
> Control: tags -1 upstream
>
> Jesse,
>
> I have just tried this with insserv 1.26.0 and the self-referential
virtual
> facility appears to be silently ignored. Is that the intended
behaviour? If so,
> is it documented anywhere (I can't imm
On 2025-02-25 06:21, Mark Hindley wrote:
Control: tags -1 upstream
Frédéric,
Thanks for this and apologies for the excessive delay.
On Mon, Sep 20, 2010 at 12:33:27AM +0200, Frédéric MASSOT wrote:
Package: sysvinit-utils
Version: 2.88dsf-12
Severity: normal
Hi,
There are messages that appe
On 2025-02-18 19:35, Bjarni Ingi Gislason wrote:
On Tue, Feb 11, 2025 at 08:53:42AM +, Mark Hindley wrote:
Control: tags -1 upstream
Jesse,
This would probably be best applied upstream, if you are willing?
Thanks
Mark
Upstream does not accept emails without subscribing, which I do n
Hello fellow init enthusiasts,
There is a new version of SysV init (version 3.14) which is now
available for your booting pleasure. The new version can be downloaded
from GitHub:
https://github.com/slicer69/sysvinit/releases/tag/3.14
There are two important fixes, one for building on Arch an
On 2025-01-13 03:31, Mark Hindley wrote:
Control: tags -1 upstream
Bjarni,
Thanks.
Jesse, this is probably better handled upstream, if you are willing?
I agree. The patch for startpar.1 has been applied upstream in the 0.66
branch. It'll be part of the next version of startpar. Thanks for
There were two issues with the Makefile (src/Makefile) in the previous
release. Both dealing with the path location where manual pages would be
installed. These have been fixed.
The latest release is available on GitHub:
https://github.com/slicer69/sysvinit/releases/tag/3.13
- Jesse
Hello init fans,
I'm pleased to announce the new release of SysV init 3.12 and a minor
update to insserv 1.26.0.
There were a number of fixes and improvements in this release. We
patched a few bugs, cleaned up the documentation, re-introduced a patch
that was helpful for GoboLinux, and made
I have applied the patch for pidof.8 upstream.
Following up on Mark's comment, I'll be happy to accept any of these
manual page fixes upstream directly. Just to streamline the process.
Jesse
On 2024-11-15 13:14, Mark Hindley wrote:
Control: tags -1 upstream
Jesse,
Perhaps you would merge
On 2024-11-12 09:41, Mark Hindley wrote:
On Tue, Nov 12, 2024 at 09:30:53AM -0400, Jesse Smith wrote:
The insserv patch doesn't merge cleanly as-is, I think because it's
working on Debian's final output insserv.8 file rather than the
upstream insserv.8.in file? I'
On 2024-11-12 09:18, Mark Hindley wrote:
On Tue, Nov 12, 2024 at 07:55:32AM -0400, Jesse Smith wrote:
I have applied the patch for the init.8 manual page upstream. It'll be
included in the 3.12 release.
Thanks. There is also #1087352 for insserv.8.
The insserv patch doesn't merge
On 2024-11-12 05:29, Mark Hindley wrote:
Control: tags -1 upstream
Bjarni,
Thanks.
Jesse,
Can you apply these upstream?
Thanks
Mark
I have applied the patch for the init.8 manual page upstream. It'll be
included in the 3.12 release.
- Jesse
Hello fellow init fans.
I've just uploaded the new SysV init 3.11 release to GitHub. The main
attraction in this version is the ability to chain together shell
commands in the inittab file. This allows administrators to run "A && B"
or "A || B" style commands from the inittab.
There were als
A new update for insserv, the dependency checker for SysV init scripts,
has been released. The new version, 1.25.0, includes a new check for
OpenRC scripts and an update to the manual page.
The new version can be downloaded from its GitHub page:
https://github.com/slicer69/insserv/releases/tag
We're releasing a new version of SysV init. This new release, 3.10,
provides one new feature and one bug fix, along with some clean-up to
documentation.
When the user executes "machinectl stop", systemd sends SIGRTMIN+4 to
PID 1 in the container, and expects that to initiate a graceful shutdow
Thank you for testing, Sven. I'll get this change committed and then
publish a new version of the SysV suite soon.
Jesse
On 2024-07-28 14:02, Sven Reschke wrote:
Sorry for being hasty.
I tested the patch recommended by Petter, with adjustments to the
current bootlogd version.
Looks like it
On 2024-07-23 17:46, Petter Reinholdtsen wrote:
Is this related to the issue reported with patch in
https://mail.gnu.org/archive/html/sysvinit-devel/2017-07/msg0.html >?
The patch seems to be almost perfect, once adjusted for some things
having been moved around since it was written. I'm
I did some debugging.
I've attached the patch I've applied to the 3.04 of sysvinit
bootlogd.c src file.
It includes your changes plus additional debug printfs.
The process is started with the following command in the init.d script:
nohup stdbuf -o0 -e0 $DAEMON -r -c -d > /tmp/bootlogd.log 2>&
On 2024-07-23 17:46, Petter Reinholdtsen wrote:
Is this related to the issue reported with patch in
https://mail.gnu.org/archive/html/sysvinit-devel/2017-07/msg0.html >?
Hi Peter,
Yes, this looks like the same bug. And with a nice fix included. I'll
take a look at this as an option and
Thank you for the patch. I've applied it upstream and it'll be included
in sysvinit-3.10.
- Jesse
On 2024-07-23 07:20, Sven Reschke wrote:
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running, which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
taking up to 95%
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented root server, where I have a yocto build running, which
utilizes sysvinit.
After logging in, the /var/log/boot file is empty and the process is
taking up to 95% of cpu usage. Also the process doesn't react on SIGINT.
After some debugging, I
Thank you for this report. I'll look into it.
I agree, we should probably have a max number of attempts in place. And
possibly a greater pause between attempts to reduce the process's load
on the system while it is retrying.
Jesse
On 2024-07-11 05:44, Sven Reschke wrote:
I have a rented ro
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 qu
I'm curious what is it specifically that you don't want
Read_Runlevel_Log to do and why? What's the expected vs actual behaviour
in this situation?
On 2024-01-26 22:48, Sam Varshavchik wrote:
So, I was wondering why rc.0 and rc.6 in Slackware 15 was going
sideways when i my alternative init
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. You
On 2023-08-18 2:44 a.m., Petter Reinholdtsen wrote:
> [Jesse Smith]
>> The big change in this release is the addition of the "halt -k"
>> command, which will trigger a kexec (kernel exec without full reboot).
> Are you talking about 'reboot -k'? I would expe
Hello init lovers! There is a new release of SysV init now available.
The new version is 3.08 which imports patches from Gentoo and touches up
some documentation.
The big change in this release is the addition of the "halt -k" command,
which will trigger a kexec (kernel exec without full reboot).
I am pleased to announce the release of SysV init 3.07. This release
focuses on a few changes to killall5 and pidof. It makes killall5 adhere
more strictly to the "omit" process list when sending signals, even
SIGSTOP signals. It also improves pidof's ability to detect running
processes which were
>
> 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 an
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)
> -rwxr
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 -l
haves as expected.
>
> 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 wrot
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 t
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 t
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 manpa
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 manpa
zmann 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
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
I am pleased to announce the release of SysV init, version 3.06. This
latest version of SysV init mostly focused on providing translations for
our manual pages. It also does some clean-up of the build process, in
particular focusing on alternative install and staging locations.
Here is a summary o
Hello fellow init enthusiasts. I've made a few changes to SysV init in
the past few months, mostly dealing with fixing translations and
dropping the sulogin program from being built on Debian. (sulogin is
provided by another package on Debian.)
Before I push out the new 3.06 release, ideally befor
I'm pleased to announce a minor update to SysV init 3.05. There isn't
any new functionality in this release, but it includes some updated
translation work and compiles on more systems. Or fixes compiling on
systems that we didn't support before or which have changed recently.
In particular, GNU Hu
On 2022-06-17 3:48 p.m., Luna Jernberg wrote:
> -- Forwarded message --
> From: Ansgar
> Date: Fri, 17 Jun 2022 19:33:39 +0200
> Subject: Re: Distrowatch
> To: steve , debian-project@lists.debian.org
>
> Hi,
>
> On Fri, 2022-06-17 at 10:37 -0400, steve wrote:
>> Distrowatch has bro
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
I've published a minor bug fix for SysV init. This release is tagged as
version 3.04 and its only change is a small fix to make sure SysV init's
bootlogd utility compiles on GNU Hurd. Everything else is functionally
the same. So on all platform apart from Hurd version 3.03 and 3.04
should be identi
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 "doa
I'm releasing a minor change following a few bug reports on SysV init 3.02.
This release includes two minor changes. One is fixing a typo in the
init manual page (init.8). this fix was offered by Mark hindley.
Mark, and a few other people, also pointed out that a fix in 3.02 for
bootlogd introduc
I'm pleased to announce the release of SysV init 3.02. This release has
a few more changes than usual, mostly minor improvements and
documentation updates.
One significant change in this release is the introduction of a
translation framework provided by Mario Blttermann. Hopefully this will
make w
Hi Paul,
These dates are in the past, was it intended for the dates to be in
Janruay, February, and March of 2023 instead of 2022?
Jesse
On 2022-03-14 5:36 p.m., Paul Gevers wrote:
> Dear all,
>
> We are currently considering the following dates as our freeze
> dates. If you are aware of major
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 chang
A new version of insserv has been published. The new release,
insserv-1.24.0, makes minor improvements to filename filtering, allowing
insserv to better ignore files it should not be using. The improves come
in the form of two changes:
1. Added ignore rule for files ending with .ucf which is used
Hi SysV init fans!
I am pleased to announce the SysV init project (and related projects
such as insserv and startpar) have migrated to a new home. The source
code for all three is now available on GitHub. The details behind the
move can be found here: https://www.patreon.com/posts/62303182
Please
> 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]
> https://github.com/m
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 translation
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
>> sys
what you think about it in general.
>
> Best regards
> Alexander Vickberg
>
> Den tors 16 dec. 2021 kl 00:06 skrev Jesse Smith
> mailto:jsm...@resonatingmedia.com>>:
>
> Alexander,
>
> Thank you for sending over the patches. I'll give them a test run
Alexander,
Thank you for sending over the patches. I'll give them a test run in the
coming days.
Jesse
On 2021-12-15 12:43 p.m., Alexander Vickberg wrote:
> Hello list,
>
> Bootlogd is eating the log data and doesn't forward it to console. The issue
> arised with commit 986bee6. The log is corr
I am pleased to announced the release of SysV init 3.01. The new version
is minor and contains just two notable changes.
The first is that pidof will now show processes in the uninterruptable
sleep (D) state by default. In the past seeing processes in the "D"
state required using the "-z" flag. Th
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 nam
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. It's
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 co
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 ok
> 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&action=diff );
> did th
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 ab
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 c
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
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 ru
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 i
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
Hello fellow init enthusiasts!
I'm pleased to report SysV init 3.00 has been uploaded to the server.
The new tarball will soon be available on the Savannah mirrors [1]
The new release, despite the bump in version number, is relatively
minor. The bootlogd utility is now more flexible about what it
Hello everyone,
I'm publishing a minor beta release which will, assuming testing goes
well, become SysV init 3.00. The new package contains just one notable
change: the bootlogd can now accept just about any device name to use as
the console. In the past we limited the console (passed in on the ke
Matthias,
As I understand it, you're hoping to make it possible to have bootlogd
work in situations where the kernel "console=" parameter can be used
even if it doesn't contain a number. And, with a little modification,
we can use any "console=" device, even if it's not a normal device name
lik
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 i
I am pleased to report there are now two new releases in the SysV init
family. The first is SysV init 2.99 which is a minor update. The new
version updates manual pages and source code with spelling fixes
provided by Helge Kreutzmann and Jens Schleusener of FOSSIES
(fossies.org). There is no funct
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 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
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
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_inf.de
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_inf.de
On 2020-12-14 3:51 a.m., Helge Kreutzmann wrote:
> Hello Jesse Smith,
> (usually only first names are used, would this be ok for you?)
I am happy to use just first names.
> I use three lines. The first shows the man page at hand (in this
> report only in respect to shutdown.8). The
. Is this correct? If I am understanding
properly, then I will update the manual pages and included these changes
in the next version of sysvinit.
Best wishes,
Jesse Smith
> Dear sysvinit maintainer,
> the manpage-l10n project maintains a large number of translations of
> man pages both fr
Hello fellow init fans,
Things have been pretty quiet on the development front this year for
SysV init and its related tools like startpar and insserv. This is
probably a good sign, it reflects the maturity of the software. Not much
needs to change and the little work that has been done is mostly
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 s
I am pleased to report the release of new versions of SysV init, along
with its helper programs insserv, and startpar. This is a fairly tame
release that mostly focuses on minor clean-ups, correcting some
documentation, and polishing the Makefiles. The changes are shown below.
Usually do a beta t
Thank you for letting us know. I looked at the manual pages and
confirmed two of the issues. These will be fixed in the next release.
The first and last issues pointed out appear to have been fixed already
as I do not see these in my source tree anymore.
If you run into any more errors in the docu
On 2020-06-19 6:59 p.m., Matias Fonzo wrote:
> El 2020-06-19 15:46, Jesse Smith escribió:
>>
>> Thanks for sending over the patch and clearly documenting it. It applies
>> cleanly here to my 2.97 branch so I'll test it and (assuming all goes
>> well) include it
Will,
Thanks for sending over the patch and clearly documenting it. It applies
cleanly here to my 2.97 branch so I'll test it and (assuming all goes
well) include it in the next release.
Cheers,
Jesse
> I've made a small modification to shutdown to allow for an extra time
> format specifier. It
> We use sysvinit to build our system. When I input "poweroff" command,
> sometimes the system has no response.
>
> I did some investigation, and found that in the function check_init_fifo() of
> init, the line:
>
> n = read(pipe_fd, &request, sizeof(request));
>
> sometimes it return -1, and t
1 - 100 of 437 matches
Mail list logo
