Bug#806797: Bug#796588: adjtimex: Has init script in runlevel S but no matching service file

On Thu, Dec 3, 2015 at 8:25 AM, Felipe Sateler wrote: > Too late ;), I had a moment to upload, and I decided to do it anyway. > On the next upload you can do it with the fixed changelog. Understand. Thank you for your sponsorship! I'll fix around and make a release by this

Bug#806797: Bug#796588: adjtimex: Has init script in runlevel S but no matching service file

Dear Felipe, Thanks for your favor! > - uscan tells me that there is no 1.29 version in the upstream page. > And indeed there is only 1.28. What happened? > - It would be great if you forward your patches upstream. I actually created the pkg repo by "gbp import-dscs --debsnap adjtimex", so now

Bug#806797: Bug#796588: adjtimex: Has init script in runlevel S but no matching service file

(moving discussion to RFS bug, please keep me in CC) On 1 December 2015 at 11:15, Roger Shimizu wrote: > Dear Felipe, > > Considering now we have consensus on the service file except the > description part, which is quite minor, I made a release build of > adjtimex

Bug#806797: Bug#796588: adjtimex: Has init script in runlevel S but no matching service file

On 2 December 2015 at 13:33, Roger Shimizu wrote: > Dear Felipe, > > Thanks for your favor! > >> - uscan tells me that there is no 1.29 version in the upstream page. >> And indeed there is only 1.28. What happened? >> - It would be great if you forward your patches

Bug#806797: Bug#796588: adjtimex: Has init script in runlevel S but no matching service file

On Thu, Dec 3, 2015 at 2:59 AM, Felipe Sateler wrote: > On 2 December 2015 at 13:33, Roger Shimizu wrote: >> I guess he just released 1.29 and forgot to put it in upstream's website. >> I didn't contact him and confirm this yet, but he seems to be MIA

Bug#806797: Bug#796588: adjtimex: Has init script in runlevel S but no matching service file

On 2 December 2015 at 20:22, Roger Shimizu wrote: > On Thu, Dec 3, 2015 at 2:59 AM, Felipe Sateler wrote: >> On 2 December 2015 at 13:33, Roger Shimizu wrote: >>> I guess he just released 1.29 and forgot to put it in

Re: init script cannot stop pid process

On 12.02.2015 07:57, Chow Loong Jin wrote: On Wed, Feb 11, 2015 at 10:25:38PM +0100, Mateusz Łukasik wrote: Hello, I make darkhttpd package and have a small issue. I prepare init script: https://github.com/mati75/darkhttpd/blob/master/debian/init and for run script with start parameter

Re: init script cannot stop pid process

Mateusz Łukasik mat...@linuxmint.pl writes: On 12.02.2015 07:57, Chow Loong Jin wrote: On Wed, Feb 11, 2015 at 10:25:38PM +0100, Mateusz Łukasik wrote: Hello, I make darkhttpd package and have a small issue. I prepare init script: https://github.com/mati75/darkhttpd/blob/master/debian

Re: init script cannot stop pid process

On Wed, Feb 11, 2015 at 10:25:38PM +0100, Mateusz Łukasik wrote: error: can't create pidfile /var/run/darkhttpd.pid: Permission denied Typically, (/var)/run is only writable by root (checked on kfreebsd and linux jessie systems). Does darkhttpd write its pid file *before* changing to the

Re: init script cannot stop pid process

On Wed, Feb 11, 2015 at 1:25 PM, Mateusz Łukasik mat...@linuxmint.pl wrote: Hello, I make darkhttpd package and have a small issue. I prepare init script: https://github.com/mati75/darkhttpd/blob/master/debian/init and for run script with start parameter is working fine: www-data 4615

init script cannot stop pid process

Hello, I make darkhttpd package and have a small issue. I prepare init script: https://github.com/mati75/darkhttpd/blob/master/debian/init and for run script with start parameter is working fine: www-data 4615 4615 0.01 0.1 12456 1548 ?Ss 22:13 0:00 /usr/bin/darkhttpd

Re: init script cannot stop pid process

On Wed, Feb 11, 2015 at 10:25:38PM +0100, Mateusz Łukasik wrote: Hello, I make darkhttpd package and have a small issue. I prepare init script: https://github.com/mati75/darkhttpd/blob/master/debian/init and for run script with start parameter is working fine: This is just a shot

Re: Preventing init script start during package install

Hi, On Sun, May 23, 2010 at 10:54:35PM +0300, Zaar Hai wrote: On Sun, May 23, 2010 at 10:12 PM, Marc Haber mh+debian-ment...@zugschlus.de wrote: If you have dh_installinit, use --noscripts and have a good reason for not starting the service automatically. Thanks! I'll try that out (looks

Re: Preventing init script start during package install

On Mon, May 24, 2010 at 11:26, Marc Haber mh+debian-ment...@zugschlus.de wrote: Hi, On Sun, May 23, 2010 at 10:54:35PM +0300, Zaar Hai wrote: On Sun, May 23, 2010 at 10:12 PM, Marc Haber mh+debian-ment...@zugschlus.de wrote: If you have dh_installinit, use --noscripts and have a good reason

Preventing init script start during package install

Hello dear mentors! I have a package that contain init script. When I install it, dpkg always brings the service up in the end (I'm using Debian Lenny). How can I prevent him to do so? Thanks. -- Zaar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject

Re: Preventing init script start during package install

On Sun, May 23, 2010 at 06:53:04PM +0300, Zaar Hai wrote: I have a package that contain init script. When I install it, dpkg always brings the service up in the end (I'm using Debian Lenny). How can I prevent him to do so? If you're the package maintainer, adapt your postinst not to start

Re: Preventing init script start during package install

On Sun, May 23, 2010 at 6:59 PM, Marc Haber mh+debian-ment...@zugschlus.de wrote: On Sun, May 23, 2010 at 06:53:04PM +0300, Zaar Hai wrote: I have a package that contain init script. When I install it, dpkg always brings the service up in the end (I'm using Debian Lenny). How can I prevent him

Re: Preventing init script start during package install

On Sun, May 23, 2010 at 10:03:51PM +0300, Zaar Hai wrote: On Sun, May 23, 2010 at 6:59 PM, Marc Haber mh+debian-ment...@zugschlus.de wrote: On Sun, May 23, 2010 at 06:53:04PM +0300, Zaar Hai wrote: I have a package that contain init script. When I install it, dpkg always brings the service

Re: Preventing init script start during package install

a package that contain init script. When I install it, dpkg always brings the service up in the end (I'm using Debian Lenny). How can I prevent him to do so? If you're the package maintainer, adapt your postinst not to start the service. If you're a user, you should have asked the question

init script versosity

describes the formats to be used for messages written to standard output by the /etc/init.d scripts. but the next lines says should and not must when describing the init script output message. so what must I do for my init scripts. VERBOSITY / no VERBOSITY ? thanks Frederic -- To UNSUBSCRIBE

Re: init script versosity

messages from init.d scripts they say : This section describes the formats to be used for messages written to standard output by the /etc/init.d scripts. but the next lines says should and not must when describing the init script output message. so what must I do for my init scripts. VERBOSITY

RE : init script versosity

thanks I will ask on debian-devel See you Frederic -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Automated testing of maintainer and init script interaction?

On 02/11/07 at 10:39 -0700, Zack Weinberg wrote: Has anyone written a utility for automatically testing the interaction between maintainer and init.d scripts? To verify that, for instance, package purge works no matter what debconf variables are set, or whether or not the daemon is running.

Automated testing of maintainer and init script interaction?

Has anyone written a utility for automatically testing the interaction between maintainer and init.d scripts? To verify that, for instance, package purge works no matter what debconf variables are set, or whether or not the daemon is running. Thanks, zw -- To UNSUBSCRIBE, email to [EMAIL

Re: init script output

Hello Yaroslav, Yaroslav Halchenko [EMAIL PROTECTED] wrote: I would, of course, prefer a solution with the lsb functions. What I want is to know when fail2ban started and when I accidentally tried to start it while the daemon was already running. BTW - it seems that /etc/init.d/skeleton does

Re: init script output

well - status has being there for quite a while invoke-rc.d fail2ban status Status of authentication failure monitor: fail2ban is running but the question is actually an attempt to disambiguate behavior/output of start/stop actions in cases when it was already started/stopped since there is no

init script output

Dear Mentors, Discussing a bug 398740 [1] I could not reach a settlement with the bug reported due to the fact that I could not find a clear statement in debian policy (although I think that I saw it somewhere and that is why init script now performs this way) or LSB about init script

Re: init script output

also sprach Yaroslav Halchenko [EMAIL PROTECTED] [2006.11.16.1717 +0100]: piper:~# /etc/init.d/apache2 start || echo failure #[345] Starting web server (apache2)... . piper:~# /etc/init.d/apache2 start || echo failure #[346] Starting web server

Re: init script output

I would, of course, prefer a solution with the lsb functions. What I want is to know when fail2ban started and when I accidentally tried to start it while the daemon was already running. BTW - it seems that /etc/init.d/skeleton does not provide any additional status (which you requested), that

Re: timeout function in cryptsetup init script

On 30/01/2006 Jan C. Nordholz wrote: Hi, indeed, it sounds exactly like what i'm searching for. but unfortunately it looks like cryptsetup does not have support for reading the password from stdin or command-line. ah, I see, it is using getpass(3) if no keyfile has been specified.

Re: timeout function in cryptsetup init script

ah, I see, it is using getpass(3) if no keyfile has been specified. Hmm, after having a glance at the source code, the easiest thing seems to patch the source to accept a new command-line option to specify a different input fd. The rest of the code (lib/setup.c:get_key(), most

timeout function in cryptsetup init script

hello, i'dd like to implement a timeout function into cryptdisks, an init script for cryptsetup. cryptsetup is run for every entry in /etc/crypttab. It unlocks a encrypted partition with either a keyfile or a passphrase. the passphrase prompt should have a timeout, as otherwise boot of headless

Re: timeout function in cryptsetup init script

hello, i'dd like to implement a timeout function into cryptdisks, an init script for cryptsetup. cryptsetup is run for every entry in /etc/crypttab. It unlocks a encrypted partition with either a keyfile or a passphrase. the passphrase prompt should have a timeout, as otherwise boot

Re: timeout function in cryptsetup init script

Hi, indeed, it sounds exactly like what i'm searching for. but unfortunately it looks like cryptsetup does not have support for reading the password from stdin or command-line. ah, I see, it is using getpass(3) if no keyfile has been specified. Hmm, after having a glance at the source code,

Re: Debian vs RedHat init script

compliant distributions violate its init script policy in various ways which can be quite hard to work around in an lsb init script, but YMMV there. As I've said, it's on my TODO list but I've not looked at it yet. So this information is appreciated - summary: it's probably not worth it for Debian

Re: Debian vs RedHat init script

compliant distributions violate its init script policy in various ways which can be quite hard to work around in an lsb init script, but YMMV there. As I've said, it's on my TODO list but I've not looked at it yet. So this information is appreciated - summary: it's probably not worth it for Debian

Debian vs RedHat init script

Hi! I'm packaging netdump for Debian. The package comes with it's own initscripts, which are RedHat specific. I had used the Debian template for initscript, in my first attempt to package netdump. Using the RedHat version of the initscript (maintained upstream), I edited Debian template, to match

Re: Debian vs RedHat init script

On Wednesday 28 July 2004 10.09, Chirag Kantharia wrote: [init scripts] Hi, You may want to have a look at the LSB spec - I bet it does say something about init scripts. I haven't looked myself, yet, but it is on my TODO list - I have written a Debian-specific init script for postgrey, but I

Re: Debian vs RedHat init script

On Wed, Jul 28, 2004 at 11:57:02AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: | Current prerelease of the LSB 2.0 spec has something on | http://www.linuxbase.org/spec/booksets/LSB-Core/LSB-Core/iniscrptfunc.html, | but I'd have to read and understand it really well, and also look at |

Re: Debian vs RedHat init script

, be able to maintain just one copy). I would not see a problem in the duplication. If the differences are really so big that a patch does not make sense, I would just ignore the old one. Whether you replace it by your init script (diff is in the diff.gz) or keep your script in debian and use debian

Re: Debian vs RedHat init script

This one time, at band camp, Chirag Kantharia said: Hi! I'm packaging netdump for Debian. The package comes with it's own initscripts, which are RedHat specific. I had used the Debian template for initscript, in my first attempt to package netdump. Using the RedHat version of the initscript

Re: Debian vs RedHat init script

initscript. I can try doing that. The initscript has Yes, that was my idea - so everybody can use the same init script. some weird function, which might be optionally used by the user, to exchange ssh keys, so that the dump is copied to the server using ssh (scp). The function has no place

Re: Debian vs RedHat init script

the same init script. To use lsb init scripts in Debian, you need to have the lsb package installed. I don't think that we want to have debian packages depending on lsb, for one thing it pulls in lots of other stuff. I've also discovered that supposedly lsb compliant distributions violate its

Debian vs RedHat init script

Hi! I'm packaging netdump for Debian. The package comes with it's own initscripts, which are RedHat specific. I had used the Debian template for initscript, in my first attempt to package netdump. Using the RedHat version of the initscript (maintained upstream), I edited Debian template, to match

Re: Debian vs RedHat init script

On Wednesday 28 July 2004 10.09, Chirag Kantharia wrote: [init scripts] Hi, You may want to have a look at the LSB spec - I bet it does say something about init scripts. I haven't looked myself, yet, but it is on my TODO list - I have written a Debian-specific init script for postgrey, but I

Re: Debian vs RedHat init script

, be able to maintain just one copy). I would not see a problem in the duplication. If the differences are really so big that a patch does not make sense, I would just ignore the old one. Whether you replace it by your init script (diff is in the diff.gz) or keep your script in debian and use debian

Re: Debian vs RedHat init script

This one time, at band camp, Chirag Kantharia said: Hi! I'm packaging netdump for Debian. The package comes with it's own initscripts, which are RedHat specific. I had used the Debian template for initscript, in my first attempt to package netdump. Using the RedHat version of the initscript

Re: Debian vs RedHat init script

initscript. I can try doing that. The initscript has Yes, that was my idea - so everybody can use the same init script. some weird function, which might be optionally used by the user, to exchange ssh keys, so that the dump is copied to the server using ssh (scp). The function has no place

Re: Debian vs RedHat init script

the same init script. To use lsb init scripts in Debian, you need to have the lsb package installed. I don't think that we want to have debian packages depending on lsb, for one thing it pulls in lots of other stuff. I've also discovered that supposedly lsb compliant distributions violate its

Re: Init Script for Arbitrary Number of Daemons

fragment. I'm still searching for a solution... Input much appreciated! Take a look at the init script for package cfengine2. It lets you boot up to three daemons and should easily be extensible to putting some daemon options in there too. As a bonus, you can see how I get Debconf to ask

Re: Init Script for Arbitrary Number of Daemons

fragment. have a look at hdparm. it has a config file (you can split this into individual ones in a .d directory...) with sections and the init script runs a command for each section with the options defined in the section. cu robert -- Robert Lemmen http

Re: Init Script for Arbitrary Number of Daemons

like: --- for DAEMON_OPTS in $DAEMON_OPTS_LIST; do echo -n $NAME start-stop-daemon --start --quiet --pidfile /var/run/$NAME.$i.pid \ --exec $DAEMON -- $DAEMON_OPTS done --- In the init script. However, I don't know how to describe something like $DAEMON_OPTS_LIST

Re: Init Script for Arbitrary Number of Daemons

This one time, at band camp, [EMAIL PROTECTED] said: My problem is really starting an arbitrary number... Perhaps I am guilty of some abuse of language; sorry. There is only one daemon, which I am trying to start an arbitrary number of copies of, with an arbitrary number of - possibly -

Re: Init Script for Arbitrary Number of Daemons

fragment. I'm still searching for a solution... Input much appreciated! Take a look at the init script for package cfengine2. It lets you boot up to three daemons and should easily be extensible to putting some daemon options in there too. As a bonus, you can see how I get Debconf to ask

Re: Init Script for Arbitrary Number of Daemons

fragment. have a look at hdparm. it has a config file (you can split this into individual ones in a .d directory...) with sections and the init script runs a command for each section with the options defined in the section. cu robert -- Robert Lemmen http

Re: Init Script for Arbitrary Number of Daemons

: --- for DAEMON_OPTS in $DAEMON_OPTS_LIST; do echo -n $NAME start-stop-daemon --start --quiet --pidfile /var/run/$NAME.$i.pid \ --exec $DAEMON -- $DAEMON_OPTS done --- In the init script. However, I don't know how to describe something like $DAEMON_OPTS_LIST

Re: Init Script for Arbitrary Number of Daemons

This one time, at band camp, [EMAIL PROTECTED] said: My problem is really starting an arbitrary number... Perhaps I am guilty of some abuse of language; sorry. There is only one daemon, which I am trying to start an arbitrary number of copies of, with an arbitrary number of - possibly -

Init Script for Arbitrary Number of Daemons

The skeleton init.d file is a great default for starting _one_ daemon, complete with the $DAEMON_OPTS variable. It's not clear, however, what this newbie package developer should do to start an arbitrary number of daemons, each with - potentially - different $DAEMON_OPTS. It's nice to be

Re: Init Script for Arbitrary Number of Daemons

This one time, at band camp, [EMAIL PROTECTED] said: The skeleton init.d file is a great default for starting _one_ daemon, complete with the $DAEMON_OPTS variable. It's not clear, however, what this newbie package developer should do to start an arbitrary number of daemons, each with -

Re: Init Script for Arbitrary Number of Daemons

This one time, at band camp, [EMAIL PROTECTED] said: The skeleton init.d file is a great default for starting _one_ daemon, complete with the $DAEMON_OPTS variable. It's not clear, however, what this newbie package developer should do to start an arbitrary number of daemons, each with -

Re: dpkg can't purge init script

On Thu, Aug 23, 2001 at 12:05:01AM +0100, Julian Gilbey wrote: On Wed, Aug 22, 2001 at 07:44:29PM +0200, Eric Van Buggenhaut wrote: I can't purge a package : curitiba_POTATO:/# dpkg --purge superviser-server (Reading database ... 9401 files and directories currently installed.)

Re: dpkg can't purge init script

On Wed, Aug 22, 2001 at 10:28:42PM +0100, Andrew Suffield wrote: On Wed, Aug 22, 2001 at 09:24:02PM +0200, Eric Van Buggenhaut wrote: Sorry for cross-posting, I posted to the wrong list first. I can't purge a package : [...] Clearly the thing that is returning 1 lies in the

Re: dpkg can't purge init script

On Thu, Aug 23, 2001 at 11:35:56AM +0200, Eric Van Buggenhaut wrote: *) echo prerm called with unknown argument \`$1' 2 exit 0 This should probably be exit 1. Well, my script is the exact copy of the skeleton found in

Re: dpkg can't purge init script

On Fri, Aug 24, 2001 at 12:35:11AM +0200, Eric Van Buggenhaut wrote: That's the only thing it could be. Your init.d script is failing and returning 1. It is bugged, fix it. Hint: --oknodo parameter to start-stop-daemon (look it up). OK, --oknodo did the trick. Thanks. I don't see the

Re: dpkg can't purge init script

On Thu, Aug 23, 2001 at 12:05:01AM +0100, Julian Gilbey wrote: On Wed, Aug 22, 2001 at 07:44:29PM +0200, Eric Van Buggenhaut wrote: I can't purge a package : curitiba_POTATO:/# dpkg --purge superviser-server (Reading database ... 9401 files and directories currently installed.)

Re: dpkg can't purge init script

On Wed, Aug 22, 2001 at 10:28:42PM +0100, Andrew Suffield wrote: On Wed, Aug 22, 2001 at 09:24:02PM +0200, Eric Van Buggenhaut wrote: Sorry for cross-posting, I posted to the wrong list first. I can't purge a package : [...] Clearly the thing that is returning 1 lies in the

Re: dpkg can't purge init script

On Thu, Aug 23, 2001 at 11:35:56AM +0200, Eric Van Buggenhaut wrote: *) echo prerm called with unknown argument \`$1' 2 exit 0 This should probably be exit 1. Well, my script is the exact copy of the skeleton found in

Re: dpkg can't purge init script

On Fri, Aug 24, 2001 at 12:35:11AM +0200, Eric Van Buggenhaut wrote: That's the only thing it could be. Your init.d script is failing and returning 1. It is bugged, fix it. Hint: --oknodo parameter to start-stop-daemon (look it up). OK, --oknodo did the trick. Thanks. I don't see the

dpkg can't purge init script

Sorry for cross-posting, I posted to the wrong list first. I can't purge a package : curitiba_POTATO:/# dpkg --purge superviser-server (Reading database ... 9401 files and directories currently installed.) Removing superviser-server ... Stopping superviser-server: dpkg: error processing

Re: dpkg can't purge init script

On Wed, Aug 22, 2001 at 09:24:02PM +0200, Eric Van Buggenhaut wrote: Sorry for cross-posting, I posted to the wrong list first. I can't purge a package : curitiba_POTATO:/# dpkg --purge superviser-server (Reading database ... 9401 files and directories currently installed.) Removing

Re: dpkg can't purge init script

On Wed, Aug 22, 2001 at 10:28:42PM +0100, Andrew Suffield wrote: curitiba_POTATO:/# dpkg --purge superviser-server ... curitiba_POTATO:/# ls -l /etc/init.d/superviser-server ... # Automatically added by dh_installinit /etc/init.d/superviser-server stop ... Yes actually, it should be

Re: dpkg can't purge init script

On Thu, Aug 23, 2001 at 10:22:51AM +1200, Michael Beattie wrote: Yes actually, it should be guarded with a -e: if [ -e /etc/init.d/superviser-ircd ]; then /etc/init.d/superviser-ircd stop fi dancer on the mind asuffield? : Yes, actually, I shamelessly pasted an example out of the

Re: dpkg can't purge init script

On Wed, Aug 22, 2001 at 10:28:42PM +0100, Andrew Suffield wrote: Yes actually, it should be guarded with a -e: if [ -e /etc/init.d/superviser-ircd ]; then /etc/init.d/superviser-ircd stop fi Should better be a -x, not -e. But that's a small point. Julian --

dpkg can't purge init script

Sorry for cross-posting, I posted to the wrong list first. I can't purge a package : curitiba_POTATO:/# dpkg --purge superviser-server (Reading database ... 9401 files and directories currently installed.) Removing superviser-server ... Stopping superviser-server: dpkg: error processing

Re: dpkg can't purge init script

On Wed, Aug 22, 2001 at 09:24:02PM +0200, Eric Van Buggenhaut wrote: Sorry for cross-posting, I posted to the wrong list first. I can't purge a package : curitiba_POTATO:/# dpkg --purge superviser-server (Reading database ... 9401 files and directories currently installed.) Removing

Re: dpkg can't purge init script

On Wed, Aug 22, 2001 at 10:28:42PM +0100, Andrew Suffield wrote: curitiba_POTATO:/# dpkg --purge superviser-server ... curitiba_POTATO:/# ls -l /etc/init.d/superviser-server ... # Automatically added by dh_installinit /etc/init.d/superviser-server stop ... Yes actually, it should be

Re: dpkg can't purge init script

On Thu, Aug 23, 2001 at 10:22:51AM +1200, Michael Beattie wrote: Yes actually, it should be guarded with a -e: if [ -e /etc/init.d/superviser-ircd ]; then /etc/init.d/superviser-ircd stop fi dancer on the mind asuffield? : Yes, actually, I shamelessly pasted an example out of the

Re: dpkg can't purge init script

On Wed, Aug 22, 2001 at 10:28:42PM +0100, Andrew Suffield wrote: Yes actually, it should be guarded with a -e: if [ -e /etc/init.d/superviser-ircd ]; then /etc/init.d/superviser-ircd stop fi Should better be a -x, not -e. But that's a small point. Julian --

Re: OK to use /etc/default for non-init script default data?

On Tue, Jun 05, 2001 at 04:40:06PM +0200, Marc Haber wrote: On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote: And if it's a wrapper script, wouldn't it be a lot better to have the wrapper in /usr/bin, with the real program called something like foo.real, and just the variable

Re: OK to use /etc/default for non-init script default data?

Marc Haber wrote: This is the way to do it for an init script. Is it OK to have a file in /etc/default that does not provider defaults for an init script but for an executeable called by users? I don't know. I don't see a lot of advantage over just putting the conffile in /etc

Re: OK to use /etc/default for non-init script default data?

-Binary in /usr/lib/foo/foo - Have a foo shell script wrapper in /usr/bin/foo - /usr/bin/foo sources /etc/default/foo so that the admin can change the default values without interfering with the wrapper itself. This is the way to do it for an init script. Is it OK to have a file in /etc

Re: OK to use /etc/default for non-init script default data?

On Tue, Jun 05, 2001 at 08:43:56AM +0200, Marc Haber wrote: On Mon, 4 Jun 2001 10:12:19 +0100, Julian Gilbey [EMAIL PROTECTED] wrote: Why not just /etc/foorc or /etc/foo.conf or something like that? Because the conffile is not a real conffile, but rather a shell script being sourced in, and

Re: OK to use /etc/default for non-init script default data?

On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote: If you want to make it clear that it's a Debian-specific thing, surely you can put a note to that effect at the top of the file? Never underestimate the user's stupidity. I don't, but how will the location and user's (sysadmin's)

Re: OK to use /etc/default for non-init script default data?

a wrapper script, or just a list of settings of the form VAR=value? Just a list of settings as it would be appropriate for init script defaults. The entire code was ripped from an init script. If you want to make it clear that it's a Debian-specific thing, surely you can put a note

Re: OK to use /etc/default for non-init script default data?

On Mon, 4 Jun 2001 10:12:19 +0100, Julian Gilbey [EMAIL PROTECTED] wrote: Why not just /etc/foorc or /etc/foo.conf or something like that? Because the conffile is not a real conffile, but rather a shell script being sourced in, and /etc/foo.conf will probably suggest that this conffile is an

Re: OK to use /etc/default for non-init script default data?

On Tue, 5 Jun 2001 10:17:01 +0100, Julian Gilbey [EMAIL PROTECTED] wrote: On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote: And if it's a wrapper script, wouldn't it be a lot better to have the wrapper in /usr/bin, with the real program called something like foo.real, and just the

Re: OK to use /etc/default for non-init script default data?

On Mon, 4 Jun 2001 10:12:19 +0100, Julian Gilbey [EMAIL PROTECTED] wrote: Why not just /etc/foorc or /etc/foo.conf or something like that? Because the conffile is not a real conffile, but rather a shell script being sourced in, and /etc/foo.conf will probably suggest that this conffile is an

Re: OK to use /etc/default for non-init script default data?

On Tue, Jun 05, 2001 at 04:40:06PM +0200, Marc Haber wrote: On Tue, Jun 05, 2001 at 11:01:22AM +0200, Marc Haber wrote: And if it's a wrapper script, wouldn't it be a lot better to have the wrapper in /usr/bin, with the real program called something like foo.real, and just the variable

Re: OK to use /etc/default for non-init script default data?

Marc Haber wrote: This is the way to do it for an init script. Is it OK to have a file in /etc/default that does not provider defaults for an init script but for an executeable called by users? I don't know. I don't see a lot of advantage over just putting the conffile in /etc

Re: OK to use /etc/default for non-init script default data?

-Binary in /usr/lib/foo/foo - Have a foo shell script wrapper in /usr/bin/foo - /usr/bin/foo sources /etc/default/foo so that the admin can change the default values without interfering with the wrapper itself. This is the way to do it for an init script. Is it OK to have a file in /etc

OK to use /etc/default for non-init script default data?

/bin/foo - /usr/bin/foo sources /etc/default/foo so that the admin can change the default values without interfering with the wrapper itself. This is the way to do it for an init script. Is it OK to have a file in /etc/default that does not provider defaults for an init script

init script params for update-rc.d

Hi! I have a single source package with several daemon being built to different packages. I would like to control the default position of these daemons in startup/shutdown. From what I can tell, dh_installinit takes parameters that tell update-rc.d what params to use to setup the init script

Re: init script params for update-rc.d

-rc.d what params to use to setup the init script. However, I want to control the two output packages seperately. Call dh_installinit twice, using the -p flag (before --, of course) to control which package gets altered in each invocation. HTH, -- Colin Watson

init script params for update-rc.d

Hi! I have a single source package with several daemon being built to different packages. I would like to control the default position of these daemons in startup/shutdown. From what I can tell, dh_installinit takes parameters that tell update-rc.d what params to use to setup the init script

Re: init script params for update-rc.d

params to use to setup the init script. However, I want to control the two output packages seperately. Call dh_installinit twice, using the -p flag (before --, of course) to control which package gets altered in each invocation. HTH, -- Colin Watson [EMAIL

init script

I'm packaging an udp logger. I would like to make it start from init, but I have some little problems. 1) The program must be started as: # udplog level where level is a number. No default is read from is config file. Is right to hardcode the level in the init script? Or the level must be read

Re: init script

# no start_from_init = yes # Level of operation. # Possible values are: # 1 : foo # 2 : bar # Warning: This setting is only used when starting udplog from init.d level = 1 Then you write a small perl/awk/sed whatever script (check xdm's init script) to parse this file. You can make a small