Re: [systemd-devel] What is the recommended way of announcing a TCP port?
On Tue, Jun 15, 2021 at 1:45 AM Mantas Mikulėnas wrote: > If you only care about processes on the same system – why not put the > actual socket in /run, as an AF_UNIX socket? That's mostly what /run is for. > I thought of that, but Prometheus cannot scrape AF_UNIX addresses. Thanks though, /ji > On Tue, Jun 15, 2021, 04:18 John Ioannidis wrote: > >> I have an instanced service that gets started and stopped by another >> service: *alice.service *runs the equivalent of *systemsctl start >> alice@foo.service, systemctl start alice@bar.service, systemctl stop >> alice@cat.service*, and so on. >> Each of the instanced services runs a little http service so its status >> can be monitored, metrics scraped, etc. The tcp port on which that service >> runs is just whatever the kernel allocated. I want to export that port >> number so other processes can find it and use it, for example, by doing the >> equivalent of *systemctl list-units | grep alice@ *so they find which >> instances are actually running, and then going about finding the >> corresponding ports. >> >> I can think of a number of ad hoc ways: >> >> * they can write the port number in a file like /run/alice/foo.port, >> /run/alice/bar.port, and whoever is interested can go read those files, in >> the same way that we use .pid files. >> * They can use systemd-notify to export it as "Status" >> * Using a service discovery mechanism would be an overkill, especially >> since whatever is actually talking to those ports is on the same host as >> the services themselves, but that's also a possibility. >> >> Is there a systemd-native way of accomplishing this? It would be nice if >> it were possible to have user-defined properties that could be set with >> *systemctl >> set-property*, but that is not the case. >> >> Thanks >> >> /ji >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel >> > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What is the recommended way of announcing a TCP port?
On Mon, Jun 14, 2021 at 9:29 PM Kevin P. Fleming wrote: > You might consider having systemd itself create the listening sockets > and then pass them into the service; if you did that, then systemd > would already know the port number that was allocated for the socket. > > I can't; a .socket unit gets activated, and subsequently starts its corresponding service, when the first connection is made. The primary purpose of the service is not to serve data over that socket; the socket is there for scraping metrics. Thanks though, /ji > On Mon, Jun 14, 2021 at 9:17 PM John Ioannidis > wrote: > > > > I have an instanced service that gets started and stopped by another > service: alice.service runs the equivalent of systemsctl start > alice@foo.service, systemctl start alice@bar.service, systemctl stop > alice@cat.service, and so on. > > Each of the instanced services runs a little http service so its status > can be monitored, metrics scraped, etc. The tcp port on which that service > runs is just whatever the kernel allocated. I want to export that port > number so other processes can find it and use it, for example, by doing the > equivalent of systemctl list-units | grep alice@ so they find which > instances are actually running, and then going about finding the > corresponding ports. > > > > I can think of a number of ad hoc ways: > > > > * they can write the port number in a file like /run/alice/foo.port, > /run/alice/bar.port, and whoever is interested can go read those files, in > the same way that we use .pid files. > > * They can use systemd-notify to export it as "Status" > > * Using a service discovery mechanism would be an overkill, especially > since whatever is actually talking to those ports is on the same host as > the services themselves, but that's also a possibility. > > > > Is there a systemd-native way of accomplishing this? It would be nice if > it were possible to have user-defined properties that could be set with > systemctl set-property, but that is not the case. > > > > Thanks > > > > /ji > > ___ > > systemd-devel mailing list > > systemd-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd prerelease 249-rc2
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here: https://github.com/systemd/systemd/archive/v249-rc2.tar.gz NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production systems, but please test this and report any issues you find to GitHub: https://github.com/systemd/systemd/issues/new?template=Bug_report.md Changes since the previous release: * When operating on disk images via the --image= switch of various tools (such as systemd-nspawn or systemd-dissect), and multiple suitable root or /usr/ partitions exist in the image, then a simple comparison inspired by strverscmp() is done on the GPT partition label, and the newest partition is picked. This permits a simple and generic whole-file-system A/B update logic where new operating system versions are dropped into partitions whose label is then updated with a matching version identifier. * systemd-sysusers now supports querying the passwords to set for the users it creates via the "credentials" logic introduced in v247: the passwd.hashed-password. and passwd.plaintext-password. credentials are consulted for the password to use (either in UNIX hashed form, or literally). By default these credentials are inherited down from PID1 (which in turn imports it from a container manager if there is one). This permits easy configuration of user passwords during first boot. Example: # systemd-nspawn -i foo.raw --volatile=yes --set-credential=passwd.plaintext-password.root:foo Note that systemd-sysusers operates in purely additive mode: it executes no operation if the declared users already exist, and hence doesn't set any passwords as effect of the command line above if the specified root user exists already in the image. (Note that --volatile=yes ensures it doesn't, though.) * systemd-firstboot now also supports querying various system parameters via the credential subsystems. Thus, as above this may be used to initialize important system parameters on first boot of previously unprovisioned images (i.e. images with a mostly empty /etc/). * Services gained a new ExitType= setting which can configure how to determine when a service exited: the default is "main" which defines the runtime by the service's main process lifetime (this matches the only behaviour implemented in v248 and before), but with "cgroup" the runtime is defined by the existence of any process in the service's cgroup. * The systemd-machine-id-setup tool now supports a --image= switch for provisioning a machine ID file into an OS disk image, similar to how --root= operates on an OS file tree. This matches the existing switch of the same name for systemd-tmpfiles, systemd-firstboot, and systemd-sysusers tools. * Similarly, systemd-repart gained support for the --image= switch too. In combination with the existing --size= option, this makes the tool particularly useful for easily growing disk images in a single invocation, following the declarative rules included in the image itself. * systemd-repart's partition configuration files gained support for a new switch MakeDirectories= which may be used to create arbitrary directories inside file systems that are created, before registering them in the partition table. This is useful in particular for root partitions to create mount point directories for other partitions included in the image. For example, a disk image that contains a root, /home/, and /var/ partitions, may set MakeDirectories=yes to create /home/ and /var/ as empty directories in the root file system on its creation, so that the resulting image can be mounted immediately, even in read-only mode. * systemd-repart's CopyBlocks= setting gained support for the special value "auto". If used, a suitable matching partition on the booted OS is found as source to copy blocks from. This is useful when implementing replicating installers, that are booted from one medium and then stream their own root partition onto the target medium. * systemd-repart's partition configuration files gained support for a Flags= and a ReadOnly= setting, allowing control of the GPT partition flags for the created partitions: this is useful for marking newly created partitions as read-only from the start. * The /etc/os-release file has been extended with two new (optional) variables IMAGE_VERSION= and IMAGE_ID=, carrying identity and
Re: [systemd-devel] Fast respawning jobs
On Fr, 25.06.21 11:17, Szymanski, Kai (kai.szyman...@luerssen.de) wrote: > Hi Lennart, > > > the desciption for StartLimitIntervalSec && Startlimitburst: > > "more than burst times within an interval time span are not permitted to > start any more" > > > But i need: A Job that returns after 4 Seconds with StatusCode 0 > have to be started again. Of cource i can raise the StartLimit...but > this is not a "really" solution in my eyes I don't understand what the problem is supposed to be? You want quick restarts are you don't? You configured your unit to prohibit that via the start limits you defined. If you want to allow quick, repeated starts then raise the limit. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fast respawning jobs
Hi Lennart, the desciption for StartLimitIntervalSec && Startlimitburst: "more than burst times within an interval time span are not permitted to start any more" But i need: A Job that returns after 4 Seconds with StatusCode 0 have to be started again. Of cource i can raise the StartLimit...but this is not a "really" solution in my eyes Best regards, Kai. At Lürssen, we are dedicated to protecting the world’s oceans and work hard every day to improve our impact on the environment. Please support our mission and reconsider before you print this email in order to save both energy and paper. Rechtsform: Kommanditgesellschaft Firma: Fr. Lürssen Werft GmbH & Co. KG Sitz: Bremen, Amtsgericht Bremen HRA 10066 HB Umsatzsteuer-Identifikationsnummer: DE114659458 Steuernummer: 60 100 09012 Geschäftsführer: Peter Lürßen, Dr. Klaus Borgschulte, Tim Wagner, Dirk Malgowski, Dr. Justus Reinke, Lena Ströbele, Sebastian Rheineck, York Ilgner Unsere E-Mail-Nachrichten und Korrespondenz mit der Lürssen Gruppe per E-Mail sind weder rechtsverbindliche Erklärungen noch Geschäftsbriefe. Die Veränderung des ursprünglichen Inhalts dieser E-Mail im Laufe der Datenübertragung kann nicht ausgeschlossen werden. Der Inhalt dieser E-Mail (einschließlich beigefügter Anhänge) ist vertraulich und u.U. rechtlich geschützt und nur für den beabsichtigten Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Jegliches unbefugte Vervielfältigen, Veröffentlichen oder Weitergabe des Inhaltes dieser E-Mail ist nicht gestattet. Our e-mail messages and any correspondence with the Luerssen group via e-mail are neither legally binding nor business letters. The falsification of the original content of this message in the course data transmission cannot be excluded. The contents of this e-mail (including any attachments) are confidential and may be privileged and are addressed to the intended recipient only. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. Von: Lennart Poettering Gesendet: Freitag, 25. Juni 2021 12:48:56 An: Szymanski, Kai Cc: systemd-devel@lists.freedesktop.org Betreff: Re: [systemd-devel] Fast respawning jobs On Fr, 25.06.21 09:32, Szymanski, Kai (kai.szyman...@luerssen.de) wrote: > Hi, Please always mention the systemd version you are operating with. (And distro would be good too). > i have a job that is very fast respawning if there ist nothing todo. The > Servicefile looks like this: > > > [Unit] > Description=job1 > StartLimitIntervalSec=100 > StartLimitBurst=5 With these two lines you declare that starting the unit shall fail when attempted more than 5 times in 100s. > Problem is that after several retries the job goes to failed state (but it > exits after 1 Seconds with resultcode 0). Raise the start limit? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fast respawning jobs
On Fr, 25.06.21 09:32, Szymanski, Kai (kai.szyman...@luerssen.de) wrote: > Hi, Please always mention the systemd version you are operating with. (And distro would be good too). > i have a job that is very fast respawning if there ist nothing todo. The > Servicefile looks like this: > > > [Unit] > Description=job1 > StartLimitIntervalSec=100 > StartLimitBurst=5 With these two lines you declare that starting the unit shall fail when attempted more than 5 times in 100s. > Problem is that after several retries the job goes to failed state (but it > exits after 1 Seconds with resultcode 0). Raise the start limit? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fast respawning jobs
Hi, i have a job that is very fast respawning if there ist nothing todo. The Servicefile looks like this: [Unit] Description=job1 StartLimitIntervalSec=100 StartLimitBurst=5 [Service] Type=idle User=myuser Group=mygroup WorkingDirectory=/tmp ExecStart=my_fast_respawning_job.sh Restart=always RestartSec=10 KillSignal=SIGUSR1 SuccessExitStatus=10 [Install] WantedBy=multi-user.target Problem is that after several retries the job goes to failed state (but it exits after 1 Seconds with resultcode 0). I examine the manual but can't find a solution for fast respawning jobs. Beste regards, Kai. PS: I hope this is the correct mailinglist to ask such kind of questions. At Lürssen, we are dedicated to protecting the world’s oceans and work hard every day to improve our impact on the environment. Please support our mission and reconsider before you print this email in order to save both energy and paper. Rechtsform: Kommanditgesellschaft Firma: Fr. Lürssen Werft GmbH & Co. KG Sitz: Bremen, Amtsgericht Bremen HRA 10066 HB Umsatzsteuer-Identifikationsnummer: DE114659458 Steuernummer: 60 100 09012 Geschäftsführer: Peter Lürßen, Dr. Klaus Borgschulte, Tim Wagner, Dirk Malgowski, Dr. Justus Reinke, Lena Ströbele, Sebastian Rheineck, York Ilgner Unsere E-Mail-Nachrichten und Korrespondenz mit der Lürssen Gruppe per E-Mail sind weder rechtsverbindliche Erklärungen noch Geschäftsbriefe. Die Veränderung des ursprünglichen Inhalts dieser E-Mail im Laufe der Datenübertragung kann nicht ausgeschlossen werden. Der Inhalt dieser E-Mail (einschließlich beigefügter Anhänge) ist vertraulich und u.U. rechtlich geschützt und nur für den beabsichtigten Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Jegliches unbefugte Vervielfältigen, Veröffentlichen oder Weitergabe des Inhaltes dieser E-Mail ist nicht gestattet. Our e-mail messages and any correspondence with the Luerssen group via e-mail are neither legally binding nor business letters. The falsification of the original content of this message in the course data transmission cannot be excluded. The contents of this e-mail (including any attachments) are confidential and may be privileged and are addressed to the intended recipient only. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
