On Mon, 23 Feb 2015 10:41:59 +1000 James Mills wrote:

This is where this policy breaks down.

Not only that but our current package management tools will not:

a) warn about such situations

or

b) install new dependencies

I know what you mean, something like 'prt-get depupgrade' would be nice :) 'Patches welcome', I guess. Pedja

Quoting Predrag Ivanovic <predivan@open.telekom.rs>:

"We encourage all port maintainers to use start-stop-daemon in their rc scripts. This will improve the scripts a lot without the need for complex shell scripting."

start-stop-daemon *is* complex shell scripting. What the hell is going on here? khm

On Mon, Feb 23, 2015 at 12:17:39PM +0900, Alan Mizrahi wrote:

On 2015-02-22 19:04, James Mills wrote:

...

Introducing start-stop-daemon and then changing openssh's rc script (/etc/rc.d/ssh) to use /sbin/start-stop-daemon and not listing start-stop-daemon IHMO is wrong.

But the Port guidelines say not to do this which I think in this case is a bit silly or at least ambiguous.

So all this aside... Let's discuss what we can here...

Do we need to update our Polices? I think so.

Should we list run-time dependencies that are not linked against? I definitely think so - otherwise you end up with a potentially broken system.

I think it is reasonable to assume a core set of ports are installed, but we should keep that list as small as possible. I wouldn't miss reiserfsprogs, xfsprogs, jfsutils or tcp_wrappers if they were moved to opt.

The problem here was: 1. introducing start-stop-daemon now instead of waiting for a new CRUX release

Introducing it now was intentionally, to give all maintainers time to familiarize with it. I admit that it was a bit/too? fast to change the sshd start script 3 days after adding start-stop-daemon to core.

2. not discussing it or announcing it properly (eg: mailing list instead of IRC)

it was announced to the mailing list, see https://lists.crux.nu/pipermail/crux/2015-February/004357.html

That said, the commits that introduced the changes had a [notify], perhaps it was not enough.

What else?

...

Lastly, Why are we introducing (already have) start-stop-daemon from Debian's ecosystem? What are we trying to solve with this tool that we can't otherwise solve in other ways or have issues with certain softwared fixed upstream?

Our init scripts have some problems, and while most of them can be solved with shell-scripting, for some people the KISS principle is incompatible with a reliable init script. Some of our scripts looks like this:

case $1) in start) /usr/sbin/somedaemon ;; stop) pkill somedaemon ;; restart) $0 stop sleep 2 $0 start ;; esac

Looks clean, simple and elegant.

Some observations though: 1. start: No check if /usr/sbin/somedamon was already running beforehand 2. stop: pkill is potentially dangerous 3. stop: did the daemon really stop? We have to check manually. 4. stop: did the daemon stop by the time the init script finished? Possibly not. 5. restart: "$0 stop" can finish before the daemon has, so there is a sleep. Are 2 seconds long enough? If not, the daemon will run twice concurrently (because of point 1).

Some daemons take care of these things by themselves, but not all.

If the daemon writes a pidfile, it should be easy for the script to do things correctly, but I have seen this kind of script used even when the daemon writes a pidfile.

That is why I maintain private ports for every daemon that I use, but it would be nice if the official ports were better.

My init scripts will kill the daemon, wait a prudential time for it to finish, and inform you if it didn't. Some of them also start the daemon with reduced permissions via sudo.

These things are easier to do correctly with start-stop-daemon.

So we have two options: 1. Start writing init scripts properly 2. Start using start-stop-daemon

I think start-stop-daemon would preserve the KISS principle better, but I would like to point out that Debian has moved to the dark side (aka systemd) already.

Gentoo's openrc is using a clone of start-stop-daemon as weel, so it would be possible to use this one instead.

Personally I will only start using start-stop-daemon it if I really need it, and so far I have managed without it.

Best regards,

best regards Juergen

[2015-02-23 15:43] Kurt H Maier <khm@sciops.net>

As it stands, when looking at an init script, seeing the command "start-stop-daemon" is akin to seeing the words "magic goes here, good luck debugging anything".

There are basically two questions: (1) is some kind of daemon management abstraction good, and (2) is a specific implementation (in this case start-stop-daemon) good to provide thi abstraction. Concerning the first question, your words would question the value of abstraction. I don't believe that's what you want to say. Hence, you probably think that the implementation of start-stop-daemon is so bad that using it harms more than its abstraction improves. meillo

i wrote ||Quoting Alan Mizrahi <alan+crux@mizrahi.com.ve>: ||> So we have two options: ||> 1. Start writing init scripts properly ||> 2. Start using start-stop-daemon | |I'm just an .ISO user with occasional updates, but regarding the |latter it doesn't feel sane to have a ~42 MB file tree laying |around for a tool that itself consists of 50 KB C code. |I haven't actually tried it yet, but i gave it a fivteen minute |quick shot and could compile only start-stop-daemon.c on Crux 3.1 |by applying the attached hacky diff. Doing something a little bit |more sane shouldn't cause that much worries given that both Debian |and Crux are Linux. and then of course there is the runit [1] init-system. What worries you at the moment is i guess key of concept for it. [1] http://smarden.org/runit/ I have read a lot about it a few months ago, but sorry, i forget things that are not part of my day-to-day radar pretty fast :( Anyway, VoidLinux switched over to use it back then, and it seemed to be pretty painless, for me as an occasional user it definitely was an absolutely painless transition. (Their package manager also seems to be quite a good thing, though other decisions i see differently. Anyway. That is from a user point of view.) E.g., dhcpcd [2] and ssh [3]: [2] https://github.com/voidlinux/void-packages/blob/master/srcpkgs/dhcpcd/ [3] https://github.com/voidlinux/void-packages/blob/master/srcpkgs/openssh/ dhcpcd.service: [Unit] Description=Lightweight DHCP client daemon Wants=network.target Before=network.target [Service] Type=forking PIDFile=/run/dhcpcd.pid ExecStart=/usr/sbin/dhcpcd -q -b ExecStop=/usr/sbin/dhcpcd -x [Install] WantedBy=multi-user.target dhcpcd/run: #!/bin/sh [ -r conf ] && . ./conf exec dhcpcd -B ${OPTS:=-M} sshd.service: # Note that this is the service file for running a single SSH server for all # incoming connections, suitable only for systems with a large amount of SSH # traffic. In almost all other cases it is a better idea to use sshd.socket + # sshd@.service (i.e. the on-demand spawning version for one instance per # connection). [Unit] Description=SSH Secure Shell Service Wants=sshdgenkeys.service After=sshdgenkeys.service After=network.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target sshd/run: #!/bin/sh ssh-keygen -A >/dev/null 2>&1 # [COMMENT STRIPPED] [ -r conf ] && . ./conf exec /usr/sbin/sshd -D $OPTS |Unless the plan is to use more tools from dpkg, of course... I'd also be willing to track changes on start-stop-daemon.c and "maintain" a CRUX-specific patch and Makefile for it alone. It really shouldn't cause any work at all (except of course that freely configurable kernels and programs with fixed compiled features don't fit, but this is a general problem, is it). I'm just looking into it and i wonder wether the patch i have sent isn't enough already. --steffen

Benjamin Blum <b.blum@mailbox.org> wrote: |---- Steffen Nurpmeso schrieb ---- ja, isch nütze kein IRC. But on IRC (http://irclogs.shortcircuit.net.au) the CRUX team. Nevermind. --steffen

On Tue, Feb 24, 2015 at 03:54:40PM +0100, Steffen Nurpmeso wrote:

I have read a lot about it a few months ago, but sorry, i forget things that are not part of my day-to-day radar pretty fast :( Anyway, VoidLinux switched over to use it back then, and it seemed to be pretty painless, for me as an occasional user it definitely was an absolutely painless transition. (Their package manager also seems to be quite a good thing, though other decisions i see differently. Anyway. That is from a user point of view.) E.g., dhcpcd [2] and ssh [3]:

[2] https://github.com/voidlinux/void-packages/blob/master/srcpkgs/dhcpcd/ [3] https://github.com/voidlinux/void-packages/blob/master/srcpkgs/openssh/

dhcpcd.service: [Unit] Description=Lightweight DHCP client daemon Wants=network.target Before=network.target

[Service] Type=forking PIDFile=/run/dhcpcd.pid ExecStart=/usr/sbin/dhcpcd -q -b ExecStop=/usr/sbin/dhcpcd -x

[Install] WantedBy=multi-user.target

For me this looks like systemd and definitely not something runit is using ;) Greetings Juergen

Juergen Daubert <jue@jue.li> wrote: |On Mon, Feb 23, 2015 at 07:53:54PM +0100, Steffen Nurpmeso wrote: |>|Quoting Alan Mizrahi <alan+crux@mizrahi.com.ve>: |>|> So we have two options: |>|> 1. Start writing init scripts properly |>|> 2. Start using start-stop-daemon |> I haven't actually tried it yet, but i gave it a fivteen minute |> quick shot and could compile only start-stop-daemon.c on Crux 3.1 |> by applying the attached hacky diff. Doing something a little bit |> more sane shouldn't cause that much worries given that both Debian |> and Crux are Linux. |> Unless the plan is to use more tools from dpkg, of course... | |no, nothing planned in that direction. | |Steffen, thanks for your offer to maintain something that allows us |to build start-stop-daemon without downloading the whole dpkg sources. |If you have a final patch let's talk about the best method to maintain |it. With pleasure, i like CRUX! The first version missed HAVE_GETDTABLESIZE and HAVE_IOPRIO_SET so it was not enough indeed. Find attached a compressed git(1) format-patch, the nm(1) output of the compiled result is "identical" to that of the version i got from following the dpkg recipe of yours. And i have registered at the Debian Package Tracker and subscribed to dpkg updates, which makes me hope i get notifications on release updates? Is that enough? Ciao, --steffen

James Mills <prologic@shortcircuit.net.au> wrote: |On Thu, Feb 26, 2015 at 12:00 AM, Steffen Nurpmeso <sdaoden@yandex.com> |wrote: |> The first version missed HAVE_GETDTABLESIZE and HAVE_IOPRIO_SET so |> it was not enough indeed. |> Find attached a compressed git(1) format-patch, the nm(1) output |> of the compiled result is "identical" to that of the version i got |> from following the dpkg recipe of yours. |> And i have registered at the Debian Package Tracker and subscribed |> to dpkg updates, which makes me hope i get notifications on |> release updates? Is that enough? | |This should probably go in out repo(s) somewhere |perhaps our "tools" repo? Mabe fork/branch from dpkg |and rebase on new changes (without the rest of dpkg)? It doesn't seem to be a wild guess to say that further maintenance shouldn't be a real burden... (The 1.17.24 version is identical to what was in 1.17.23, for example.) I'm fine with whatever you wanna do, but willing to help with this as necessary. --steffen

On Wed, Feb 25, 2015 at 03:00:12PM +0100, Steffen Nurpmeso wrote:

Juergen Daubert <jue@jue.li> wrote: |On Mon, Feb 23, 2015 at 07:53:54PM +0100, Steffen Nurpmeso wrote: |>|Quoting Alan Mizrahi <alan+crux@mizrahi.com.ve>: |>|> So we have two options: |>|> 1. Start writing init scripts properly |>|> 2. Start using start-stop-daemon

|> I haven't actually tried it yet, but i gave it a fivteen minute |> quick shot and could compile only start-stop-daemon.c on Crux 3.1 |> by applying the attached hacky diff. Doing something a little bit |> more sane shouldn't cause that much worries given that both Debian |> and Crux are Linux. |> Unless the plan is to use more tools from dpkg, of course... | |no, nothing planned in that direction. | |Steffen, thanks for your offer to maintain something that allows us |to build start-stop-daemon without downloading the whole dpkg sources. |If you have a final patch let's talk about the best method to maintain |it.

With pleasure, i like CRUX! The first version missed HAVE_GETDTABLESIZE and HAVE_IOPRIO_SET so it was not enough indeed. Find attached a compressed git(1) format-patch, the nm(1) output of the compiled result is "identical" to that of the version i got from following the dpkg recipe of yours. And i have registered at the Debian Package Tracker and subscribed to dpkg updates, which makes me hope i get notifications on release updates? Is that enough?

Yeah, sure, thank you very much. As we are talking about files of 88K in sum, I'd say its fine to put them directly into our ports tree without an external repository. I'll commit this later with two noticeable minor changes: - added the makefile to our source() array - changed the program and port version number to 20141020 which is the date of the last commit to start-stop-daemon.c [1] Greetings Juergen [1] https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=dpkg/dpkg.git;...

Hello, you possibly want to integrate a change that can now be found on Debian [master] with a very interesting change: start-stop-daemon: sync with Debian (CLOCK_MONOTONIC).. Using CLOCK_MONOTONIC instead of what was in use until today will ensure that running actions with configured time periods will run, and at correct times, even in the event of intermediate changes to the system clock. --steffen