Re: [systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

On Wed, 2024-05-22 at 17:42 +0200, Lennart Poettering wrote: > On Mi, 22.05.24 17:13, Nop (ctx...@gmail.com) wrote: > > > Hello folks, > > I have a question about what you guys considers to be the > > right/expect way. > > > > I read documentation a bit about INVOCATION_ID and JOURNAL_STREAM

Re: [systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

To me, just like you, it all started with me trying to detect if running as part of systemd service or not. And by that I really mean: user clicked somewhere, or typed in some command in an input box or a TE, without having to be aware that systemd is involved under the hood or not. I do get that

Re: [systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

On 23.05.2024 09:18, Nop wrote: From my terminal emulator that I start by clicking in the menu: echo "kitty: $(pidof kitty) - $INVOCATION_ID" && echo "plasmashell: $(pidof plasmashell) - $(sudo strings /proc/$(pidof plasmashell)/environ | grep INVOCATION_ID)" kitty: 4441 -

Re: [systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

>From my terminal emulator that I start by clicking in the menu: echo "kitty: $(pidof kitty) - $INVOCATION_ID" && echo "plasmashell: $(pidof plasmashell) - $(sudo strings /proc/$(pidof plasmashell)/environ | grep INVOCATION_ID)" kitty: 4441 - e3ec804609094a139948a1887c90ac7a plasmashell: 857 -

Re: [systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

On 22.05.2024 23:35, Nop wrote: Sorry, just noticed that I didn't "reply to all"... So Lennart is going to receive this twice... Le mer. 22 mai 2024 à 17:42, Lennart Poettering a écrit : On Mi, 22.05.24 17:13, Nop (ctx...@gmail.com) wrote: Hello folks, I have a question about what you guys

Re: [systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

Sorry, just noticed that I didn't "reply to all"... So Lennart is going to receive this twice... Le mer. 22 mai 2024 à 17:42, Lennart Poettering a écrit : > > On Mi, 22.05.24 17:13, Nop (ctx...@gmail.com) wrote: > > > Hello folks, > > I have a question about what you guys considers to be the

Re: [systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

On Mi, 22.05.24 17:13, Nop (ctx...@gmail.com) wrote: > Hello folks, > I have a question about what you guys considers to be the right/expect way. > > I read documentation a bit about INVOCATION_ID and JOURNAL_STREAM and, to > me, it feels like those two variables should not be propagated from >

[systemd-devel] Question about propagation of INVOCATION_ID and JOURNAL_STREAM env variables in Desktop Environments

Hello folks, I have a question about what you guys considers to be the right/expect way. I read documentation a bit about INVOCATION_ID and JOURNAL_STREAM and, to me, it feels like those two variables should not be propagated from DE. I mean, if I start KDE Plasma, for example, using systemd, it

[systemd-devel] question about systemd-tmpfiles-setup.service

Hi list, In some cases users may want to clean up the files under /tmp only during boot with the following configuration # cat /etc/tmpfiles.d/fs-tmp.conf #Type Path Mode User Group Age Argument d! /tmp 1777 root root 14d But according to the man page of tmpfiles.d ''' If the exclamation mark

Re: [systemd-devel] Question regarding configuration of SystemMaxUse and SystemKeepFree

> On 1 Sep 2023, at 22:36, PureLinux Betriebsführung wrote: > > So my question is - is there any option to set a relative value/a percentage > for that values? Per default, it seems to be possible. So why not a user > defined percentage? How are you managing journal config? If you are

Re: [systemd-devel] Question regarding configuration of SystemMaxUse and SystemKeepFree

On 02.09.2023 12:22, PureLinux Betriebsführung wrote: ... The documentation states, that there are relative values used per default, but they are capped (as you mentioned) at a specific value. So for me, it looks like journald is also supporting relative values. So i am wondering about the

Re: [systemd-devel] Question regarding configuration of SystemMaxUse and SystemKeepFree

Hi, thanks for your fast response, Andrei! It seems like i was a bit unclear with my explanation, so we misunderstood. Sorry for that. I meant the actual size of the filesystem, which differs from e.g. 100M on a small SoC up to ~8G on a bigger server system. Not a specific service, which is

Re: [systemd-devel] Question regarding configuration of SystemMaxUse and SystemKeepFree

On 02.09.2023 00:29, PureLinux Betriebsführung wrote: Hi, i am running a bunch of partly very different systems with Debian Bookworm. On this machines, i am using systemd 252 (252.12-1~deb12u1). If i am configuring journald, i am facing the problem, that /var/log is having a very different size

[systemd-devel] Question regarding configuration of SystemMaxUse and SystemKeepFree

Hi, i am running a bunch of partly very different systems with Debian Bookworm. On this machines, i am using systemd 252 (252.12-1~deb12u1). If i am configuring journald, i am facing the problem, that /var/log is having a very different size on all my machines. From 100M to 8G or something.

Re: [systemd-devel] [Question] How to make services only see only one external network interface and loopback

I think I got it. Basically what I did was to setup a veth to link the namespace and the host networking then setup IPs and some iptables rules to give it Internet access. Unfortunately that weird bug keeps happening but now I know how to do this kind of isolation. Maybe I should bond the

Re: [systemd-devel] [Question] How to make services only see only one external network interface and loopback

There's no single service option to do this, as far as I know, since it involves a bit more than just making the interface visible. After PrivateNetwork is enabled, the newly created namespaces need to be explicitly given network access through the host; the same "external" interface can't exist

[systemd-devel] [Question] How to make services only see only one external network interface and loopback

I am working on a service unit for a DHT crawler. For some reason, it doesn't work well with the default network settings because it seems to use a huge amount of traffic for a very small amount of findings. The same program works fine via docker, but I want to package it as a hardened systemd

Re: [systemd-devel] Question about timestamps in the USER_RECORD spec

On Di, 26.10.21 10:41, Arian van Putten (arian.vanput...@gmail.com) wrote: > Hey list, > > I'm reading the https://systemd.io/USER_RECORD/ spec and I have a question > > There are some fields in the USER_RECORD spec which are described as > "unsigned 64 bit integer values". Specifically the

[systemd-devel] Question about timestamps in the USER_RECORD spec

Hey list, I'm reading the https://systemd.io/USER_RECORD/ spec and I have a question There are some fields in the USER_RECORD spec which are described as "unsigned 64 bit integer values". Specifically the fields describing time. However JSON lacks integers and only has doubles [0]; which

Re: [systemd-devel] [question] is it possible with systemd-journalctl to change the location to save logs in other location?

Pe duminică, 16 august 2020, 20:00:10 EEST, Lennart Poettering a scris: On So, 16.08.20 16:35, ionut n (ionut_n2...@yahoo.com) wrote: > > Hi SystemD Team, > > One question. > > Is it possible with systemd-journalctl to change the location to save logs in > other location? > > My

Re: [systemd-devel] [question] is it possible with systemd-journalctl to change the location to save logs in other location?

I understand, but there is no option or any parameter in systemd  to not do through mount? Pe duminică, 16 august 2020, 19:48:51 EEST, Tomasz Torcz a scris: On Sun, Aug 16, 2020 at 04:35:48PM +, ionut n wrote: > > Hi SystemD Team,   It's "systemd" (all lowercase). > > One

[systemd-devel] [question] is it possible with systemd-journalctl to change the location to save logs in other location?

Hi SystemD Team, One question. Is it possible with systemd-journalctl to change the location to save logs in other location? My system is volatile (tmpfs) and I have another location available to keep certain logs. - /dev/root or / is tmpfs - /external-persistent0 is ext4 or xfs I

Re: [systemd-devel] [question] is it possible with systemd-journalctl to change the location to save logs in other location?

On So, 16.08.20 16:35, ionut n (ionut_n2...@yahoo.com) wrote: > > Hi SystemD Team, > > One question. > > Is it possible with systemd-journalctl to change the location to save logs in > other location? > > My system is volatile (tmpfs) and I have another location available to keep > certain

Re: [systemd-devel] [question] is it possible with systemd-journalctl to change the location to save logs in other location?

On Sun, Aug 16, 2020 at 04:35:48PM +, ionut n wrote: > > Hi SystemD Team, It's "systemd" (all lowercase). > > One question. > > Is it possible with systemd-journalctl to change the location to save logs in > other location? > > My system is volatile (tmpfs) and I have another location

Re: [systemd-devel] question about a poweroff issue

On Mi, 26.02.20 13:50, piliu (pi...@redhat.com) wrote: > Hi, > > I encountered a systemd bug during saving vmcore for kdump kernel. > > I got the following message: > > [ 60.283489] systemd[1]: Started Reload Configuration from the Real Root. > [ 60.290912] systemd[1]: Reached target Initrd

[systemd-devel] question about poweroff issue

failing (Andreas Kempe) -- Message: 1 Date: Wed, 26 Feb 2020 13:50:55 +0800 From: piliu To: SystemD Devel Subject: [systemd-devel] question about a poweroff issue Message-ID: Content-Type: text/plain; charset=utf

[systemd-devel] question about a poweroff issue

Hi, I encountered a systemd bug during saving vmcore for kdump kernel. I got the following message: [ 60.283489] systemd[1]: Started Reload Configuration from the Real Root. [ 60.290912] systemd[1]: Reached target Initrd File Systems. [ 60.296162] systemd[1]: Reached target Initrd Default

Re: [systemd-devel] Question on Before=

On 2/2/19 3:44 PM, Reindl Harald wrote: > > > Am 02.02.19 um 21:05 schrieb Steve Dickson: >> On 2/2/19 2:52 PM, Reindl Harald wrote: >>> Am 02.02.19 um 20:42 schrieb Steve Dickson: Hello, In a.service I have [Unit] Before=b.service [Install]

Re: [systemd-devel] Question on Before=

On 2/2/19 4:03 PM, Tomasz Torcz wrote: > On Sat, Feb 02, 2019 at 03:03:22PM -0500, Steve Dickson wrote: >> >> >> On 2/2/19 2:48 PM, Tomasz Torcz wrote: >>> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote: Hello, In a.service I have [Unit]

Re: [systemd-devel] Question on Before=

On 2/2/19 4:07 PM, Uoti Urpala wrote: > On Sat, 2019-02-02 at 15:03 -0500, Steve Dickson wrote: >>> Have you enabled a.service? >>> >> No... I did not think I had to... I figured >> when b.service was started, a.service would be >> run regardless of being enabled or disabled. >> >> Is that

Re: [systemd-devel] Question on Before=

On Sat, Feb 02, 2019 at 03:03:22PM -0500, Steve Dickson wrote: > > > On 2/2/19 2:48 PM, Tomasz Torcz wrote: > > On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote: > >> Hello, > >> > >> In a.service I have > >> > >> [Unit] > >> Before=b.service > >> > >> [Install] > >>

Re: [systemd-devel] Question on Before=

On Sat, 2019-02-02 at 15:03 -0500, Steve Dickson wrote: > > Have you enabled a.service? > > > No... I did not think I had to... I figured > when b.service was started, a.service would be > run regardless of being enabled or disabled. > > Is that not the case? So you just have the file for

Re: [systemd-devel] Question on Before=

Am 02.02.19 um 21:05 schrieb Steve Dickson: > On 2/2/19 2:52 PM, Reindl Harald wrote: >> Am 02.02.19 um 20:42 schrieb Steve Dickson: >>> Hello, >>> >>> In a.service I have >>> >>> [Unit] >>> Before=b.service >>> >>> [Install] >>> RequiredBy=b.service >>> >>> when I systemd start b.service

Re: [systemd-devel] Question on Before=

Am 02.02.19 um 21:03 schrieb Steve Dickson: > On 2/2/19 2:48 PM, Tomasz Torcz wrote: >> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote: >>> Hello, >>> >>> In a.service I have >>> >>> [Unit] >>> Before=b.service >>> >>> [Install] >>> RequiredBy=b.service >>> >>> when I systemd

Re: [systemd-devel] Question on Before=

On 2/2/19 2:52 PM, Reindl Harald wrote: > > > Am 02.02.19 um 20:42 schrieb Steve Dickson: >> Hello, >> >> In a.service I have >> >> [Unit] >> Before=b.service >> >> [Install] >> RequiredBy=b.service >> >> when I systemd start b.service (which happens to fail) >> but... a.service is not

Re: [systemd-devel] Question on Before=

On 2/2/19 2:48 PM, Tomasz Torcz wrote: > On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote: >> Hello, >> >> In a.service I have >> >> [Unit] >> Before=b.service >> >> [Install] >> RequiredBy=b.service >> >> when I systemd start b.service (which happens to fail) >> but...

Re: [systemd-devel] Question on Before=

On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote: > Hello, > > In a.service I have > > [Unit] > Before=b.service > > [Install] > RequiredBy=b.service > > when I systemd start b.service (which happens to fail) > but... a.service is not being run. > > So I guess my question is

Re: [systemd-devel] Question on Before=

Am 02.02.19 um 20:42 schrieb Steve Dickson: > Hello, > > In a.service I have > > [Unit] > Before=b.service > > [Install] > RequiredBy=b.service > > when I systemd start b.service (which happens to fail) > but... a.service is not being run. > > So I guess my question is what do I have to

[systemd-devel] Question on Before=

Hello, In a.service I have [Unit] Before=b.service [Install] RequiredBy=b.service when I systemd start b.service (which happens to fail) but... a.service is not being run. So I guess my question is what do I have to do to ensure a.service is *always* run before b.service? tia, steved.

Re: [systemd-devel] Question about WATCHDOG

On Fri, Jan 11, 2019 at 08:03:45AM +, Sietse van Zanen wrote: > Hi, > > > > I am writing a daemon script which uses sd_notify watchdog. This works fine, > system will kill the if the process doesn’t notify. > > > > However, I have seen in 1 occasion where, due to a programming error,

[systemd-devel] Question about WATCHDOG

Hi, I am writing a daemon script which uses sd_notify watchdog. This works fine, system will kill the if the process doesn't notify. However, I have seen in 1 occasion where, due to a programming error, the script got stuck in a read and was not killed where it should have been. So my question

Re: [systemd-devel] Question about hardware watchdog

On Mo, 05.11.18 16:21, Liu, Shuang (ADITG/ESM) (s...@de.adit-jv.com) wrote: > Hi, > > We are facing problem with hardware watchdog. > > To my understanding, the watchdog is pinged inside the manager_loop(), > which means, during e.g. systemctl daemon-reload, watchdog cannot be pinged. > >

Re: [systemd-devel] Question about the default value of NamePolicy=

Hello, On Wed, Aug 1, 2018 at 7:36 PM, Mantas Mikulėnas wrote: > > AFAIK, "onboard" and (hotplug) "slot" names are mutually exclusive, so their > relative ordering isn't that important... but if the firmware marks a device > as on-board *and* also provides a slot number, then it's more likely

Re: [systemd-devel] Question about the default value of NamePolicy=

On Wed, Aug 1, 2018 at 7:18 PM Francis Moreau wrote: > Hello, > > I have a question regarding the default value of NamePolicy= defined > in 99-default.link. > > The value is "NamePolicy=kernel database onboard slot path" > > Could someone explain me why "onbard" is preferred over "slot" which >

[systemd-devel] Question about the default value of NamePolicy=

Hello, I have a question regarding the default value of NamePolicy= defined in 99-default.link. The value is "NamePolicy=kernel database onboard slot path" Could someone explain me why "onbard" is preferred over "slot" which is preferred over "path" ? Thanks. -- Francis

Re: [systemd-devel] question about Wants and unit start-up order

On Sat, Mar 24, 2018 at 5:54 PM, Brian J. Murrell wrote: > On Sat, 2018-03-24 at 17:39 +0200, Mantas Mikulėnas wrote: > > > > Which systemd version do you run? In v232, > > systemd-219-42.el7_4.10.x86_64 > > > nss-lookup.target:Description=Host and Network Name Lookups > >

Re: [systemd-devel] question about Wants and unit start-up order

On Sat, 2018-03-24 at 17:39 +0200, Mantas Mikulėnas wrote: > > Which systemd version do you run? In v232, systemd-219-42.el7_4.10.x86_64 > nss-lookup.target:Description=Host and Network Name Lookups > nss-user-lookup.target:Description=User and Group Name Lookups Same here: # systemctl show

Re: [systemd-devel] question about Wants and unit start-up order

On Fri, Mar 23, 2018 at 9:52 PM, Brian J. Murrell wrote: > On Fri, 2018-03-23 at 21:45 +0200, Mantas Mikulėnas wrote: > > > > No, dependencies do not imply any specific ordering. (The only > > exception is > > when a .target wants/requires another unit.) > > That seems odd

Re: [systemd-devel] question about Wants and unit start-up order

On Fri, 2018-03-23 at 21:45 +0200, Mantas Mikulėnas wrote: > > No, dependencies do not imply any specific ordering. (The only > exception is > when a .target wants/requires another unit.) That seems odd but I will leave that aside for a moment... > In other words, you will need to additionally

Re: [systemd-devel] question about Wants and unit start-up order

On Fri, Mar 23, 2018 at 5:41 PM, Brian J. Murrell wrote: > If I have: > > Wants=system.slice nss-lookup.target named-setup-rndc.service > > in named-pkcs11.service, so shouldn't mean that named-pkcs11.service > will be started up before the nss-lookup.target is

[systemd-devel] question about Wants and unit start-up order

If I have: Wants=system.slice nss-lookup.target named-setup-rndc.service in named-pkcs11.service, so shouldn't mean that named-pkcs11.service will be started up before the nss-lookup.target is Reached/Started? That doesn't seem to be the case on my system: Mar 23 09:44:03

Re: [systemd-devel] Question about a random UDP port on rpcbind 0.2.3 started by systemd

if you have the mentionned file (/usr/lib/systemd/system/rpcbind.socket) then systemd will open whatever port is described in there and pass it pre-opened to rpcbind. systemd has no idea what that port is for and the file mentionned above was provided to systemd by the rpcbind package. You

[systemd-devel] Question about a random UDP port on rpcbind 0.2.3 started by systemd

Hello evryone, I would like to ask you a question regarding the new random UDP port in rpcbind 0.2.3. In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through rpcbind.service, then I do netstat udp0 0 0.0.0.0:111 0.0.0.0:* 10408/rpcbind udp0 0

Re: [systemd-devel] question about socket activation

On Fr, 29.12.17 17:19, eshark (eshar...@163.com) wrote: > Hi, All > I tried to test the socket activation by a simple foobar.socket and > foobar.service, which are as the following: > foobar.socket: >[Socket] >ListenStream=/dev/socket/foobar > > >[Install]

Re: [systemd-devel] question about socket activation

The program source codes and the foobar.service , the foobar.socket are as the attachments. Thanks for any suggestion! At 2017-12-29 16:19:35, "eshark" wrote: Hi, All I tried to test the socket activation by a simple foobar.socket and foobar.service, which are

[systemd-devel] question about socket activation

Hi, All I tried to test the socket activation by a simple foobar.socket and foobar.service, which are as the following: foobar.socket: [Socket] ListenStream=/dev/socket/foobar [Install] WantedBy=sockets.target foobar.service: [Service]

Re: [systemd-devel] [QUESTION] AIX 7.1 nodes area not reporting

On Thu, Nov 30, 2017 at 7:19 AM, Vengatesh R wrote: > Hi Team, > > > > AIX 7.1 nodes area not reporting to puppet master. Please find the below > details. > > > > Puppet master : Red hat Linux 7.3 x86_64 > Hi, this is not the Puppet mailing list, not the AIX mailing

Re: [systemd-devel] Question about service dependency handling in systemd-228

Hi all, Thank you very much for your support. I will try to fix the cycle. Brs, On Mon, Nov 27, 2017 at 4:11 PM, Reindl Harald wrote: > > > Am 27.11.2017 um 05:23 schrieb Bao Nguyen: > >> Thanks all for your comments. I will try to use option FreeBind. However >>

[systemd-devel] [QUESTION] AIX 7.1 nodes area not reporting

Hi Team, AIX 7.1 nodes area not reporting to puppet master. Please find the below details. Puppet master : Red hat Linux 7.3 x86_64 The information in this e-mail and any attachments is confidential and may be legally privileged. It is intended solely for the addressee or addressees. Any use

Re: [systemd-devel] [Question]: About systemctl and its related commands

Thank you. I know have a deeper understanding of the this topic :) Regards. Chiba 2017年11月28日(火) 23:32 Lennart Poettering : > f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (chib...@klab.com) wrote: > > > We have a few questions about systemctl and -H option. > > > > It looks

Re: [systemd-devel] [Question]: About systemctl and its related commands

f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (chib...@klab.com) wrote: > We have a few questions about systemctl and -H option. > > It looks like systemctl is communicating with /run/systemd/private in order > to interact with systemd. > > However, after you log in the connected computer via ssh, it

Re: [systemd-devel] [Question]: About systemctl and its related commands

Hi, i asked similar question a few weeks ago, and you probably will get a oficial answer soon :P, but in a nutshell would be: /run/systemd/private is a private socket and its meant for systemd tools to communicate with systemd even if dbus daemon is down. this is specially true during boot and

[systemd-devel] [Question]: About systemctl and its related commands

We have a few questions about systemctl and -H option. It looks like systemctl is communicating with /run/systemd/private in order to interact with systemd. However, after you log in the connected computer via ssh, it looks like it's trying to control systemd by going through

Re: [systemd-devel] Question

On Sa, 25.11.17 15:24, Peter Diks (peterd...@gmail.com) wrote: > Hello Systemd-devel@lists.freedesktop.org, > > There is something i do not understand at this point and would like to > solve it. > A brand new Tumbleweed Kubic, has enable repositories and zypper runs fine, > untill it has to

Re: [systemd-devel] Question about service dependency handling in systemd-228

Am 27.11.2017 um 05:23 schrieb Bao Nguyen: Thanks all for your comments. I will try to use option FreeBind. However could anyone explain for me that I did not use FreeBind option in systems-210 but all my services start well? I am still inclined to the different of systemd-228 and

Re: [systemd-devel] Question about service dependency handling in systemd-228

Hi, Thanks all for your comments. I will try to use option FreeBind. However could anyone explain for me that I did not use FreeBind option in systems-210 but all my services start well? I am still inclined to the different of systemd-228 and systemd-210 causes the current issue. Thanks again,

Re: [systemd-devel] Question about service dependency handling in systemd-228

On Sun, Nov 26, 2017 at 11:47 AM, Bao Nguyen wrote: > Hi Uoti, > > Thanks a lot for your answer, I have checked the cycle. It is created by > sockets.target > -> asi-My-5101.socket -> My-sshd.target -> My-syncd.service -> > My-nfs-client.service > -> My-handling.service ->

Re: [systemd-devel] Question about service dependency handling in systemd-228

Am 26.11.2017 um 10:47 schrieb Bao Nguyen: Regard to your question, "asi-My-5101.socket" depends on "My-sshd.target", I think that in my case it is expected as my socket listens on a specific address IP:port so it should start after a network service to configure and assign IP address before

Re: [systemd-devel] Question about service dependency handling in systemd-228

Hi Uoti, Thanks a lot for your answer, I have checked the cycle. It is created by sockets.target -> asi-My-5101.socket -> My-sshd.target -> My-syncd.service -> My-nfs-client.service -> My-handling.service -> basic.target -> sockets.target. I do not see the same cycle in systemd-210 so I said that

[systemd-devel] Question

Hello Systemd-devel@lists.freedesktop.org, There is something i do not understand at this point and would like to solve it. A brand new Tumbleweed Kubic, has enable repositories and zypper runs fine, untill it has to install. Error: Subprocess failed. Error: RPM failed: error: Can 't create

Re: [systemd-devel] Question

Am 25.11.2017 um 16:24 schrieb Peter Diks: Hello Systemd-devel@lists.freedesktop.org , There is something i do not understand at this point and would like to solve it. A brand new Tumbleweed Kubic, has enable repositories and zypper runs fine,

Re: [systemd-devel] Question about service dependency handling in systemd-228

On Sat, 2017-11-25 at 12:08 +0700, Bao Nguyen wrote: > [ 41.154231] systemd[1]: nss-lookup.target: Dependency > Before=nss-lookup.target dropped > [ 41.297229] systemd[1]: sockets.target: Found ordering cycle on > sockets.target/start > [ 41.297236] systemd[1]: sockets.target: Found

[systemd-devel] Question about service dependency handling in systemd-228

Hello everyone, I would like to have a question regarding to the building dependency and cycle dependency handling on systemd-228. In my system, I have some socket and service files, it has a cycle on socket target, when I run on system-228, systemd-228 throws [ 40.358582] systemd[1]: Set

Re: [systemd-devel] Question: path-based deactivation or equivalent

On Di, 26.09.17 16:15, matt...@giassa.net (matt...@giassa.net) wrote: > I have a project where I'm adding some services to a Raspberry Pi 3, > and have decided to go with systemd being (mostly) responsible for > launching all of the services. All of the server processes use a common > API to do

Re: [systemd-devel] Question: path-based deactivation or equivalent

On Di, 26.09.17 21:07, Matthew Giassa (matt...@giassa.net) wrote: > Additionally, does systemd support assigning an environment variable to an > internal variable, ie: > > Environment=MYPIDFILE=/var/run/mine.pid > PIDFILE=$MYPIDFILE systemd unit files are not supposed to be a templating

Re: [systemd-devel] Question: path-based deactivation or equivalent

systemctl.  Thank you for the feedback. Sent from my BlackBerry 10 smartphone on the Bell network.   Original Message   From: Lennart Poettering Sent: Wednesday, September 27, 2017 9:54 AM To: matt...@giassa.net Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Question: path

Re: [systemd-devel] Question: path-based deactivation or equivalent

* Matthew Giassa [2017-09-26 21:07:16 -0700]: I know there are workarounds for ExecStart for example, using /bin/bash to evaluate environment variables, but I think that special case only applies to ExecStart, ExecStartPre, and Executor, as they actually get executed

Re: [systemd-devel] Question: path-based deactivation or equivalent

Additionally, does systemd support assigning an environment variable to an internal variable, ie: Environment=MYPIDFILE=/var/run/mine.pid PIDFILE=$MYPIDFILE I know there are workarounds for ExecStart for example, using /bin/bash to evaluate environment variables, but I think that special case

[systemd-devel] Question: path-based deactivation or equivalent

I have a project where I'm adding some services to a Raspberry Pi 3, and have decided to go with systemd being (mostly) responsible for launching all of the services. All of the server processes use a common API to do some initial setup (argument parsing, init, etc), drop root permissions, and

Re: [systemd-devel] [Question] timezones in timers

Hi, I've implemented support for timezones in timers (at least I am not sure if there are some other places that need some changes). Here is a diff of what I've committed so far: https://github.com/systemd/systemd/compare/master...zerkms:TIMER_TIMEZONE In the very bottom in the tests file you

Re: [systemd-devel] [Question] timezones in timers

I'm doing it with the libc and doing it out of the process: https://github.com/zerkms/systemd/blob/d09815ef6df4705e06bd0b3a276c4cbd8630859f/src/basic/calendarspec.c#L902 I believe parsing is portable standard C with libc and time conversion will be very similar to that. On 7 September 2017 at

Re: [systemd-devel] [Question] timezones in timers

On Mi, 06.09.17 13:18, Mantas Mikulėnas (graw...@gmail.com) wrote: > On Wed, Sep 6, 2017 at 12:58 PM, Ivan Kurnosov wrote: > > > I've started working on it (as a crazy experiment for myself primarily) > > > > At the moment I added support for timezones (IANA) to the

Re: [systemd-devel] [Question] timezones in timers

On Wed, Sep 6, 2017 at 12:58 PM, Ivan Kurnosov wrote: > I've started working on it (as a crazy experiment for myself primarily) > > At the moment I added support for timezones (IANA) to the `CalendarSpec`, > the parser and the formatter. > >

Re: [systemd-devel] [Question] timezones in timers

I've started working on it (as a crazy experiment for myself primarily) At the moment I added support for timezones (IANA) to the `CalendarSpec`, the parser and the formatter. https://github.com/zerkms/systemd/commit/367325ae7a2c4df2c0513e8bb8e992 5aaf24feef On 5 September 2017 at 19:11,

Re: [systemd-devel] [Question] timezones in timers

On Di, 05.09.17 09:41, Ivan Kurnosov (zer...@zerkms.ru) wrote: > Hi, > > was it even considered initially to have proper timezones support in timers? > > Or perhaps it is somewhere in the roadmap? > > In particular, I'm speaking of `[Timer] OnCalendar` You mean as in explicitly per-unit

[systemd-devel] [Question] timezones in timers

Hi, was it even considered initially to have proper timezones support in timers? Or perhaps it is somewhere in the roadmap? In particular, I'm speaking of `[Timer] OnCalendar` -- With best regards, Ivan Kurnosov ___ systemd-devel mailing list

Re: [systemd-devel] question about system reboot and shutdown

On Mi, 09.08.17 11:28, Tilman Baumann (til...@baumann.name) wrote: > In my experience, the only place where you can hook in a non racy way is > in the kernel. I fully agree with this btw. The only safe place if the kernel does all this. Much like most other drivers UPS drivers should be in the

Re: [systemd-devel] question about system reboot and shutdown

On Mi, 09.08.17 11:02, Marek Floriańczyk (marek.florianc...@gmail.com) wrote: > The question is, will my binary be able to open RS232 port eg. /dev/ttyACM0 > when filesystem is Read-Only ? Yes, /dev is unaffected. It's an API VFS, not a real file system, and those won't be remounted r/o. > And

Re: [systemd-devel] question about system reboot and shutdown

Dnia środa, 9 sierpnia 2017 14:54:25 CEST piszesz: > 2017-08-09 14:51 GMT+02:00 Marek Floriańczyk : > > Dnia środa, 9 sierpnia 2017 11:51:07 CEST Tilman Baumann pisze: > >> On 09.08.2017 11:28, Tilman Baumann wrote: > > NUT looks like quite active based on their

Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 14:51 GMT+02:00 Marek Floriańczyk : > Dnia środa, 9 sierpnia 2017 11:51:07 CEST Tilman Baumann pisze: >> On 09.08.2017 11:28, Tilman Baumann wrote: > > NUT looks like quite active based on their website. > Microupsd daemon handles also some switches and leds

Re: [systemd-devel] question about system reboot and shutdown

Dnia środa, 9 sierpnia 2017 11:51:07 CEST Tilman Baumann pisze: > On 09.08.2017 11:28, Tilman Baumann wrote: > > DL;DR > > UPS shutdowns are tricky. Clean file-systems are not the only concern. > > But if you can make assumptions about your storage backend you might be > > able to cut corners

Re: [systemd-devel] question about system reboot and shutdown

Dnia środa, 9 sierpnia 2017 09:17:44 CEST Mantas Mikulėnas pisze: > /dev is a separate filesystem and is never read-only. right ;) > > Another approach would be to let microupsd exit normally, but then start a > separate microupsd instance (e.g. microupsd-shutdown.service) which > schedules the

Re: [systemd-devel] question about system reboot and shutdown

On 09.08.2017 11:28, Tilman Baumann wrote: > DL;DR > UPS shutdowns are tricky. Clean file-systems are not the only concern. > But if you can make assumptions about your storage backend you might be > able to cut corners safely. > > In my experience, the only place where you can hook in a non racy

Re: [systemd-devel] question about system reboot and shutdown

DL;DR UPS shutdowns are tricky. Clean file-systems are not the only concern. But if you can make assumptions about your storage backend you might be able to cut corners safely. In my experience, the only place where you can hook in a non racy way is in the kernel.

Re: [systemd-devel] question about system reboot and shutdown

/dev is a separate filesystem and is never read-only. Another approach would be to let microupsd exit normally, but then start a separate microupsd instance (e.g. microupsd-shutdown.service) which schedules the UPS poweroff. On Wed, Aug 9, 2017, 12:03 Marek Floriańczyk

Re: [systemd-devel] question about system reboot and shutdown

Dnia środa, 9 sierpnia 2017 10:29:37 CEST Lennart Poettering pisze: > On Di, 08.08.17 16:03, Marek Floriańczyk (marek.florianc...@gmail.com) wrote: > > Hi all, > > > > I have a small device MicroUPS which helps me to shutdown my system on > > embedded devices, it is controlled by script

Re: [systemd-devel] question about system reboot and shutdown

Hi I have no problem with changing some code in microupsd so it behave in certain way. It is handling SIGTERM and other signals if needed. The problem for me is that SIGTERM is send to process during system reboot and system halt - so I need to differentiate between the two. SIGTERM is sent, by

Re: [systemd-devel] question about system reboot and shutdown

Dnia wtorek, 8 sierpnia 2017 19:35:12 CEST Mantas Mikulėnas pisze: > I suggest first porting microupsd itself to a native systemd .service file > (so that it'll have process monitoring and everything). That might even fix > part of the problem. Hi I have no problem with changing some code in

Re: [systemd-devel] question about system reboot and shutdown

I suggest first porting microupsd itself to a native systemd .service file (so that it'll have process monitoring and everything). That might even fix part of the problem. Normally services are given a certain amount of time to stop after SIGTERM (or whatever KillSignal was set, or whatever

Re: [systemd-devel] question about system reboot and shutdown

Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze: > 08.08.2017 17:03, Marek Floriańczyk пишет: > > What would be the proper way to distinguish between system is going down > > for reboot and for shutdown ? > > Straightforward way is to make your service WantedBy poweroff.target

  1   2   3   4   >