Re: [systemd-devel] [ANNOUNCE] systemd v230

On Fri, May 27, 2016 at 7:49 AM, Michael Biebl wrote: > 2016-05-27 6:36 GMT+02:00 Mantas Mikulėnas : > > That doesn't look ok to me, if this is straight out of > > /usr/share/polkit-1/actions – the <_tags> are supposed to be processed by > > intltool at build

Re: [systemd-devel] How do I hook into ACPI events?

On Fri, May 27, 2016 at 12:12 AM, Mason Loring Bliss wrote: > Traditionally I could edit scripts in /etc/acpi to accomplish things, but > on > EL7 I'm seeing that some combination of upower and systemd/logind appear to > be the way to control responses to ACPI events. > > I

Re: [systemd-devel] [ANNOUNCE] systemd v230

2016-05-27 6:36 GMT+02:00 Mantas Mikulėnas : > That doesn't look ok to me, if this is straight out of > /usr/share/polkit-1/actions – the <_tags> are supposed to be processed by > intltool at build time into translated , aren't they? the installed file obviously has the

[systemd-devel] OT: Which tool to use to restart service if check-script fails

OK, I understand that I need different tool to restart a service if a check-script fails. In my case the check script will be custom code. But the restart stuff is very general and reusable: Step1: Call check-script Step2: If exit 0 (meaning service is working), then wait N seconds, got to

Re: [systemd-devel] [ANNOUNCE] systemd v230

On Fri, May 27, 2016 at 3:45 AM, Michael Biebl wrote: > 2016-05-27 2:03 GMT+02:00 Zbigniew Jędrzejewski-Szmek : > > On Fri, May 27, 2016 at 01:52:41AM +0200, Michael Biebl wrote: > >> $ loginctl enable-linger > >> Could not enable linger: Access denied > >

Re: [systemd-devel] [ANNOUNCE] systemd v230

2016-05-27 4:22 GMT+02:00 Zbigniew Jędrzejewski-Szmek : > Yeah, looks OK. It tested systemd git on Fedora rawhide, and it works > just fine. But if fails on up-to-date Fedora 24. Damn. > I have the same polkit version on both: polkit-0.113-5.fc24.x86_64. Ok, thanks for the

Re: [systemd-devel] [ANNOUNCE] systemd v230

On Fri, May 27, 2016 at 02:45:51AM +0200, Michael Biebl wrote: > 2016-05-27 2:03 GMT+02:00 Zbigniew Jędrzejewski-Szmek : > > On Fri, May 27, 2016 at 01:52:41AM +0200, Michael Biebl wrote: > >> $ loginctl enable-linger > >> Could not enable linger: Access denied > > Works here ;)

Re: [systemd-devel] [ANNOUNCE] systemd v230

2016-05-27 2:03 GMT+02:00 Zbigniew Jędrzejewski-Szmek : > On Fri, May 27, 2016 at 01:52:41AM +0200, Michael Biebl wrote: >> $ loginctl enable-linger >> Could not enable linger: Access denied > Works here ;) > > Did you check that the polkit file got installed properly? > Check

Re: [systemd-devel] [ANNOUNCE] systemd v230

On Fri, May 27, 2016 at 01:52:41AM +0200, Michael Biebl wrote: > 2016-05-27 1:50 GMT+02:00 Michael Biebl : > >> After the user logs out of all sessions, user@.service will be > >> terminated too, by default, unless the user has "lingering" > >> enabled. > >>

Re: [systemd-devel] [ANNOUNCE] systemd v230

2016-05-22 0:51 GMT+02:00 Zbigniew Jędrzejewski-Szmek : > * systemd-logind will now by default terminate user processes that are > part of the user session scope unit (session-XX.scope) when the user > logs out. This behavior is controlled by the

Re: [systemd-devel] [ANNOUNCE] systemd v230

2016-05-27 1:50 GMT+02:00 Michael Biebl : >> After the user logs out of all sessions, user@.service will be >> terminated too, by default, unless the user has "lingering" >> enabled. >> To effectively allow users to run long-term tasks even if they

[systemd-devel] How do I hook into ACPI events?

Traditionally I could edit scripts in /etc/acpi to accomplish things, but on EL7 I'm seeing that some combination of upower and systemd/logind appear to be the way to control responses to ACPI events. I want to have custom things happen on lid close, and I'm not seeing how to accomplish it as

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

Am 26.05.2016 um 20:28 schrieb Chris Friesen: So I've been playing with this a bit, but I've run into another snag. It seems that on initial boot even with "net.ifnames=0" the ethernet interface ordering isn't consistent. This means that two systems with identical hardware can end up mapping

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

On 05/26/2016 01:59 PM, Greg KH wrote: On Thu, May 26, 2016 at 01:49:07PM -0600, Chris Friesen wrote: The thing that makes this all confusing/annoying is that when I was using a homebrew distro with a 3.10 kernel and sysV init the interface ordering was completely repeatable on identical

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

On Thu, May 26, 2016 at 01:49:07PM -0600, Chris Friesen wrote: > On 05/26/2016 12:41 PM, Martin Pitt wrote: > > Chris Friesen [2016-05-26 12:28 -0600]: > > > So I've been playing with this a bit, but I've run into another snag. It > > > seems that on initial boot even with "net.ifnames=0" the

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

On 05/26/2016 12:41 PM, Martin Pitt wrote: Chris Friesen [2016-05-26 12:28 -0600]: So I've been playing with this a bit, but I've run into another snag. It seems that on initial boot even with "net.ifnames=0" the ethernet interface ordering isn't consistent. "even with" → "because of" :-)

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

Chris Friesen [2016-05-26 12:28 -0600]: > So I've been playing with this a bit, but I've run into another snag. It > seems that on initial boot even with "net.ifnames=0" the ethernet interface > ordering isn't consistent. "even with" → "because of" :-) However, the ordering isn't really

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

On 05/13/2016 08:54 AM, Chris Friesen wrote: On 05/13/2016 01:23 AM, Lennart Poettering wrote: On Thu, 12.05.16 12:34, Chris Friesen (cbf...@mail.usask.ca) wrote: I booted the kernel with "net.ifnames=0", which worked to turn off the location-based naming. I then created a set of files, one

[systemd-devel] shutdown delayed by failure to start a service

Did this ever get fixed? IOW, sometimes a service will fail to start when a system is started, or later, after a session of updating, a previously operating service fails to restart, or a newly installed service fails to start, or a service is removed. Then at shutdown/reboot time, systemd

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On 05/26/2016 02:38 PM, Lennart Poettering wrote: >On 05/26/2016 09:36 AM, Lennart Poettering wrote: > > >/usr is for the OS vendor really. > >Given that it's generally expected and wanted that application developers >follow the os vendors packaging guideline and rules as possible in

Re: [systemd-devel] check to see if service is still alive

Am 26.05.2016 um 15:15 schrieb Lennart Poettering: On Thu, 26.05.16 14:39, Thomas Güttler (guettl...@thomas-guettler.de) wrote: Am 26.05.2016 um 14:35 schrieb Andrei Borzenkov: On Thu, May 26, 2016 at 3:18 PM, Thomas Güttler wrote: I want to know if the

Re: [systemd-devel] sysv-generator weirdness for shutdown runlevels

On Thu, 26.05.16 08:13, Francis Moreau (francis.m...@gmail.com) wrote: > On Wed, May 25, 2016 at 11:10 PM, Michael Biebl wrote: > > And if a service does not have an explicit stop on shutdown/reboot, > > the processes are killed in a final killing spree where there are not > >

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On Thu, 26.05.16 13:46, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > On 05/26/2016 09:36 AM, Lennart Poettering wrote: > > >/usr is for the OS vendor really. > > Given that it's generally expected and wanted that application developers > follow the os vendors packaging guideline and

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

Am 26.05.2016 um 16:38 schrieb Lennart Poettering: On Thu, 26.05.16 13:46, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 05/26/2016 09:36 AM, Lennart Poettering wrote: /usr is for the OS vendor really. Given that it's generally expected and wanted that application developers

Re: [systemd-devel] check to see if service is still alive

On 05/26/2016 01:15 PM, Lennart Poettering wrote: On Thu, 26.05.16 14:39, Thomas Güttler (guettl...@thomas-guettler.de) wrote: >Am 26.05.2016 um 14:35 schrieb Andrei Borzenkov: > >On Thu, May 26, 2016 at 3:18 PM, Thomas Güttler > > wrote: > >>I want to know if

Re: [systemd-devel] check to see if service is still alive

Am 26.05.2016 um 14:39 schrieb Thomas Güttler: Am 26.05.2016 um 14:35 schrieb Andrei Borzenkov: On Thu, May 26, 2016 at 3:18 PM, Thomas Güttler wrote: I want to know if the service is alive, Define "service is alive". the service is alive if a custom check

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On 05/26/2016 09:44 AM, Frederic Crozat wrote: I don't know how this software will be shipped, but if it is as a RPM package, it is best to be installed in /usr/lib/systemd/system. /etc/systemd/system should be for admins or 3rd parties not using packages. /etc is admin only territory and

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On 05/26/2016 09:36 AM, Lennart Poettering wrote: /usr is for the OS vendor really. Given that it's generally expected and wanted that application developers follow the os vendors packaging guideline and rules as possible in distribution and many 3rd party repositories reflect that, I have

Re: [systemd-devel] check to see if service is still alive

On Thu, 26.05.16 14:39, Thomas Güttler (guettl...@thomas-guettler.de) wrote: > Am 26.05.2016 um 14:35 schrieb Andrei Borzenkov: > >On Thu, May 26, 2016 at 3:18 PM, Thomas Güttler > > wrote: > >>I want to know if the service is alive, > > > >Define "service is alive".

Re: [systemd-devel] check to see if service is still alive

On Thu, May 26, 2016 at 3:39 PM, Thomas Güttler wrote: > Am 26.05.2016 um 14:35 schrieb Andrei Borzenkov: >> >> On Thu, May 26, 2016 at 3:18 PM, Thomas Güttler >> wrote: >>> >>> I want to know if the service is alive, >> >> >> Define

Re: [systemd-devel] check to see if service is still alive

Am 26.05.2016 um 14:35 schrieb Andrei Borzenkov: On Thu, May 26, 2016 at 3:18 PM, Thomas Güttler wrote: I want to know if the service is alive, Define "service is alive". the service is alive if a custom check method has the exit status of 0 -- Thomas

Re: [systemd-devel] check to see if service is still alive

On Thu, May 26, 2016 at 3:18 PM, Thomas Güttler wrote: > I want to know if the service is alive, Define "service is alive". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org

Re: [systemd-devel] check to see if service is still alive

Am 26.05.2016 um 10:14 schrieb Michael Biebl: 2016-05-26 9:55 GMT+02:00 Thomas Güttler : Hi, I have a service which sends "I am alive" (WATCHDOG=1) via sd_notify. Sometimes the custom service fails, but still sends the WATCHDOG=1. Why does your service

Re: [systemd-devel] Perl Net::DBus, org.freedesktop.system1 and inhibitor locks

Hi Lennart, >On Wed, 25.05.16 18:13, Michael Hirmke (m...@mike.franken.de) wrote: [...] >> Sorry, I forgot to add information regarding my environment. >> I use openSuSE Leap 42.1 with a Plasma 5 desktop. >I don't know if KDE respects these advisory locks and shows them in >the UI, or does not.

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

Le jeudi 26 mai 2016 à 11:36 +0200, Lennart Poettering a écrit : > On Thu, 26.05.16 00:52, Rashmi Ranjan Mohanty ( > rashmiranjan.moha...@microfocus.com) wrote: > > > Anyway we are changing the location of unit files to standard > > /usr/lib/systemd/system to fix the issue. Tested it and works

Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully

You need to listen to JobRemoved signals. All of them, before you start your job - trying to match on the specific job you get back from StopUnit might not complete before the job is already removed. On Thu, May 26, 2016 at 8:20 AM Adrien Besnard wrote: > I managed to

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On Thu, May 26, 2016 at 12:36 PM, Lennart Poettering wrote: > /usr is for the OS vendor really. If your package is a 3rd party > package this is probably not a good idea. You could also simply copy > them into /etc/systemd/system, which would also work. > ... > > (Which

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

Am 26.05.2016 um 11:36 schrieb Lennart Poettering: On Thu, 26.05.16 00:52, Rashmi Ranjan Mohanty (rashmiranjan.moha...@microfocus.com) wrote: Anyway we are changing the location of unit files to standard /usr/lib/systemd/system to fix the issue. Tested it and works fine after changing the

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On Thu, 26.05.16 10:20, Mantas Mikulėnas (graw...@gmail.com) wrote: > Some distros (e.g. Debian) configure systemd to use /lib instead of > /usr/lib. > > In other distros (e.g. Arch or Gentoo), it's generally been agreed that it > needs to be pre-mounted by the initramfs – since /usr often

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On Thu, 26.05.16 00:52, Rashmi Ranjan Mohanty (rashmiranjan.moha...@microfocus.com) wrote: > Anyway we are changing the location of unit files to standard > /usr/lib/systemd/system to fix the issue. Tested it and works fine > after changing the location. /usr is for the OS vendor really. If

Re: [systemd-devel] check to see if service is still alive

2016-05-26 9:55 GMT+02:00 Thomas Güttler : > Hi, > > I have a service which sends "I am alive" (WATCHDOG=1) via sd_notify. > > Sometimes the custom service fails, but still sends the WATCHDOG=1. Why does your service continue to send WATCHDOG=1 events when it failed?

[systemd-devel] check to see if service is still alive

Hi, I have a service which sends "I am alive" (WATCHDOG=1) via sd_notify. Sometimes the custom service fails, but still sends the WATCHDOG=1. Now "systemctl status" says that the service is running, but in reality it is failed. Is there a way in systemd to do a check to see if the service is

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On 05/26/2016 06:52 AM, Rashmi Ranjan Mohanty wrote: Just out of curiosity... If /usr itself is there on a separate partition, can this issue happen then or systemd can handle that scenario ? Systemd can cope with /usr being on separated partition however other core/baseOS components might

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On Thu, May 26, 2016 at 9:52 AM, Rashmi Ranjan Mohanty < rashmiranjan.moha...@microfocus.com> wrote: > > What I don't understand in your case though is why you use an explicit > > mount for /opt anyway... The nice thing about btrfs is that subvolumes > > behave pretty much like normal directories

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

> What I don't understand in your case though is why you use an explicit > mount for /opt anyway... The nice thing about btrfs is that subvolumes > behave pretty much like normal directories that just have a bit more > features. And because of that there's no need to mount them > explicitly. Just

Re: [systemd-devel] sysv-generator weirdness for shutdown runlevels

2016-05-26 8:25 GMT+02:00 Francis Moreau : > Well yes that's not usefull, so I'm wondering why systemd has code to > deal with this weid case specially since by default all stubs will > have a Conflicts/Before=shutdown.target. The generator code is generic, there is no

Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted

On 05/25/2016 05:21 PM, Lennart Poettering wrote: > On Tue, 24.05.16 22:21, Rashmi Ranjan Mohanty > (rashmiranjan.moha...@microfocus.com) wrote: > >> Hi, >> >> Our whole software is installed into /opt. So the systemd unit files >> are also there in /opt and the units are enabled to start on

Re: [systemd-devel] sysv-generator weirdness for shutdown runlevels

On Thu, May 26, 2016 at 8:15 AM, Andrei Borzenkov wrote: > On Thu, May 26, 2016 at 8:49 AM, Francis Moreau > wrote: >> >> So let's take an example. Please note that I'm really not sure what's >> the expected behavior of sysvinit itself, and finding

Re: [systemd-devel] sysv-generator weirdness for shutdown runlevels

2016-05-26 7:49 GMT+02:00 Francis Moreau : > Hello Michael, > > On Wed, May 25, 2016 at 11:08 PM, Michael Biebl wrote: >> Hm, I've already given you the answer on IRC, so I'm not sure why you >> ask them again. >> > > Indee and thank you for that. > > But

Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully

I managed to do what I wanted to do using add_timeout with the GLib's MainLoop: I poll every second the state of the unit and manually call the callback connected to DBus to fake the event when the unit is stopped. It works but this is a dirty hack. So I'm still interested by a real solution :)