Re: Init systems and docker
On Fri, 11 Oct 2019 19:25:54 -0400, Jose-Luis Rivas wrote: >There's not much sense in using systemd inside a docker container, to be >honest. Generally you want to launch your service as custom as possible >and the ENTRYPOINT allows you to do just that. Docker already sends the >SIGKILL to the PID 1, which should be the service you're shipping in >that container. Generally, I concur. But there are other uses for containers than running a production service. For example; I'd love to have the possibility to just fire up a Debian that is as close to a standard installation to try "something". Docker is the natual way to do this when you already have docker to run services. Then it's only the work of creating (or using) a Debian image to instantiate the container and to get rid of it quickly after the tests have been completed. LXC might be the more natural tool to use for this, but this is a different tool that needs different knowledge, and it's tooling is way behind what we have with docker. So, +1 to be able to run a default systemd-based Debian with systemd as pid 1 in a docker container. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#942310: ITP: gnome-shell-extension-arc-menu -- shell extension designed to replace the standard menu found in GNOME
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: gnome-shell-extension-arc-menu Version : 34.2-dev Upstream Author : LinxGem33 (https://gitlab.com/LinxGem33) * URL : https://gitlab.com/LinxGem33/Arc-Menu * License : GPL-2+ Programming Lang: JavaScript Description : shell extension designed to replace the standard menu found in GNOME Arc Menu is a GNOME shell extension designed to replace the standard menu found in GNOME 3 this application menu extension has some added benefits over the standard menu found in GNOME 3, these include the long awaited search functionality as well as quick access to files on your system and also the current logged in user along with quick access to the software centre and system settings and other features which can be accessed from the settings menu. This package will be maintained as part of the shell-extensions subgroup of the GNOME team on salsa.debian.net
Re: Init systems and docker
On 10/14/19 05:49, Marc Haber wrote: > > So, +1 to be able to run a default systemd-based Debian with systemd > as pid 1 in a docker container. Hi Marc, you can do this already. As explained somewhere else in the thread, just run docker run with the --privilege flag. Cheers. -- __.https://wiki.debian.org/JoseLuisRivas ___'/___ rsa4096/D278F9C15E5461AA3C1E2FCD13EC43EEB9AC8C43
Re: Init systems and docker
On Fri, Oct 11, 2019 at 06:49:37PM -0400, Scott Kitterman wrote: > I have been told by docker users (I'm not one) that systemd as provided on > Debian can't be used in docker. I have no idea if that's true or not. I try > really hard to know as little about init systems as possible and trust our > maintainers who work on such things. Hey Scott, this can be a bit of an opinionated topic and the following may not directly apply to your issue at hand, but here's my two cents from prior experience. To keep the container small and to make sure you do only one thing and one thing well in the context of the container, what I would do is to keep the OS as lightweight as possible, and only start the process needed when the container starts up using Docker's entrypoint. It can invoke a helper script to assist with starting up the application. In order to get some supervisory capability on the process I would use use supervisord which I could trigger directly from the entrypoint as this is lot easier to manage and you don't need to use the --privilege parameter, not to mention not having to deal with init/systemd related complexity (IMHO). See this for an example: https://advancedweb.hu/2018/07/03/supervisor_docker/ Some could argue that even the use of supervisord is an anti-pattern since orchestration systems provide that capability, in which case it becomes even more simpler and you can just spin up the process directly through a helper, init-like script and let the orchestrator supervise the container through health and readiness hooks that you expose in the application. All logs go to standard out so that it can be aggregated and logged in an orchestrated environment, and so fits in with the paradigm where you don't keep the logs in the container. As mentioned by others on this trail, I would also suggest against treating the container like a traditional VM and instead use the new primitives and best practices available to compose the solution, and err on the side of simplicity and keeping things self-contained and lightweight. Hope this helps. -- Regards Anuradha
Bug#942317: ITP: euslisp -- Lisp based integrated programming system for intelligent robots
Package: wnpp Severity: wishlist Owner: Kei OKADA X-Debbugs-CC: debian-devel@lists.debian.org, debian-de...@lists.debian.or.jp * Package name: euslisp Version: 9.26 Upstream Author: Toshihiro Matsu , * URL: https://github.com/euslisp/EusLisp License: BSD Description: EusLisp is an integrated programming system for the research on intelligent robots based on Common Lisp and Object-Oriented programming
Bug#942321: ITP: fort-validator -- An RPKI Validator and RTR Server
Package: wnpp Severity: wishlist Owner: Marco d'Itri * Package name: fort-validator Version : 1.0.0 Upstream Author : NIC MX and LACNIC * URL : https://nicmx.github.io/FORT-validator/ * License : MIT Programming Lang: C Description : An RPKI Validator and RTR Server Fort is an MIT-licensed RPKI Relying Party. It is a service that performs the validation of the entire RPKI repository, and which serves the resulting ROAs for easy access by your routers. -- ciao, Marco signature.asc Description: PGP signature
Bug#942333: RFP: osc2midi -- Highly flexible and configurable OSC / JACK MIDI bridge
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: osc2midi Version: 0.2.5 Upstream Author: Spencer Jackson URL: https://github.com/ssj71/OSC2MIDI License: GPL-3 Description: OSC2MIDI is a highly configurable OSC to jack MIDI (and back) bridge. It was designed especially for use on Linux desktop and the open source Android app called "Control (OSC+MIDI)" but was deliberately written to be flexible enough to be used with any OSC controller or target. i'm working on package it! Saludos! -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar
