[systemd-devel] systemd-run returns with 'Failed to start transient scope unit: Unit run-13034.scope already exists.'

[Petr Horacek]

Hello,

recently we encountered strange systemd problem on automated tests of
networking
part of oVirt VDSM project.

Sometimes this happens:
$ /usr/sbin/ifdown enp1s0f1
$ /usr/bin/systemd-run --scope --slice=vdsm-dhclient /usr/sbin/ifup enp1s0f1
Failed to start transient scope unit: Unit run-13034.scope already exists.

systemd-run should create a new scope every time it's called, should not
it? Could it be
a racefull bug in systemd?

I found recently added issue [1] which describes similar problem, but with
--unit instead
of --slice. Note that our machine which reproduced it has systemd older
than v220.

Is it possible, that this is the same case as described in [1] and
therefore it should be
fixed in systemd 220?

Is it possible to backport [1]'s fix to EL7?

Thanks a lot,
Petr
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Setting the shell to the system locale

[Colin Guthrie]

Hi,

David Adam wrote on 15/10/15 07:18:
> Hi,
> 
> I work on fish shell, which is a non-POSIX command-line shell. I'm
> trying to work out whether we should ship something in our source that 
> tries to set the locale for our users. Alternatively, it might be 
> something that needs to be left to distributions as it seems to be handled 
> very differently.
> 
> Is /etc/locale.conf appropriate for consumption by clients other than 
> systemd - such as shells? That is, is the format stable? If not, is there 
> a way of querying the default system locale if there is no `LANG` (etc.) 
> set in the environment - through `localectl` or otherwise?
> 
> A broader question is: which process should be responsible for setting the 
> locale? Are the comments in the log message for 1640944a84 still 
> appropriate?
> 
>> Eventually we probably want to drop this again since the system locale
>> should be read and set at one place, and not at multiple, and that one 
>> place should be PID 1.
> 
> I am not sure there is a good answer to this question, but I would be 
> interested in hearing about the rationale for the different approaches. 
> For example, Debian sets up PAM to source /etc/default/locale for all 
> sessions, while Fedora drops a script in /etc/profile.d for command-line 
> shells. Most graphical shells seem to use their own defaults.

I think, if you can, you should ask localed via dbus for the locale
information (rather than parsing /etc/locale.conf directly). This way
the details of how it's set can be changed and you just use that API
directly.

I think a while back, David Herrmann hinted towards localed in the user
session (i.e. there would be a system instance for system-wide locale
and a per-user one for user preferences. Not sure if this ended up
happening or not tho'. It may be worth looking at the console stuff in
systemd to see how it sets locales?

Not much info from me but hopefully helps a bit!

Col




-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-run returns with 'Failed to start transient scope unit: Unit run-13034.scope already exists.'

[Lennart Poettering]

On Thu, 15.10.15 13:25, Petr Horacek (phora...@redhat.com) wrote:

> Hello,
> 
> recently we encountered strange systemd problem on automated tests of
> networking
> part of oVirt VDSM project.
> 
> Sometimes this happens:
> $ /usr/sbin/ifdown enp1s0f1
> $ /usr/bin/systemd-run --scope --slice=vdsm-dhclient /usr/sbin/ifup enp1s0f1
> Failed to start transient scope unit: Unit run-13034.scope already exists.
> 
> systemd-run should create a new scope every time it's called, should not
> it? Could it be
> a racefull bug in systemd?

The code for this is actually really naive... the number is just the
PID of the caller, and there's no check at all to ensure it is
unique. PIDs overrun easily, hence this is not nice at all...

What's even worse: when you use -H or -M to invoke things remotely we
still pick the client side PID for the name

I figure we should rework this to pick some sufficiently large random
token instead, so that this is unlikely to conflict without actually
having to check for conflicts.

In the meantime, you should be able to fix this by explicitly picking
a randomized name for the scope using --unit=. For example, consider
just adding --unit=`uuidgen` to your command line, and the clashes
should not happen anymore.

> I found recently added issue [1] which describes similar problem,
> but with --unit instead of --slice. Note that our machine which
> reproduced it has systemd older than v220.
> 
> Is it possible, that this is the same case as described in [1] and
> therefore it should be
> fixed in systemd 220?
> 
> Is it possible to backport [1]'s fix to EL7?

Well, there are still cases where we unable to clean up scope units
properly, because we don't get any notifications for them when they
run empty. But yeah the current upstream versions should be better
than older versions.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Setting the shell to the system locale

[Lennart Poettering]

On Thu, 15.10.15 14:18, David Adam (zanc...@ucc.gu.uwa.edu.au) wrote:

> Hi,
> 
> I work on fish shell, which is a non-POSIX command-line shell. I'm
> trying to work out whether we should ship something in our source that 
> tries to set the locale for our users. Alternatively, it might be 
> something that needs to be left to distributions as it seems to be handled 
> very differently.
> 
> Is /etc/locale.conf appropriate for consumption by clients other than 
> systemd - such as shells? That is, is the format stable? If not, is there 
> a way of querying the default system locale if there is no `LANG` (etc.) 
> set in the environment - through `localectl` or otherwise?

Yes, the format is stable, and it's supposed to be a subset of
shell. See its man page.

> A broader question is: which process should be responsible for setting the 
> locale? Are the comments in the log message for 1640944a84 still 
> appropriate?

Well, currently we simply inherit the system locale stored in
/etc/locale.conf into everything, but whatever runs in the user
session may reset and override this at free will, and in many cases
this is done.

There's no established clear concept of where per-user locale is
configured. Many shells do that in their profile scripts, and distros
differ widely.

I figure the right place to store the locale is actually not the home
directory, but the user database. This is necessary as display
managers should be able to access the data (in order to switch locale
as soon as a user is picked), but should not have to touch the home
directory for it (which might well be prohibited to root, and might
involve triggering autofs and so on). Now, because when it comes to
user management we are still in the 1970s, and there's not sane or
established way to extend the user database like this. Hence things
are chaotic. accounts-daemon for example stores this data in a
separate database, that is not network transparent.

Yup, it's not pretty.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How does systemd discover template instances?

[Erik Haller]

  
  
You can also create a /lib/systemd/systemd/my_main_script.service
and use "ln -s /lib/systemd/system/my_main_script.service
/etc/systemd/system/uniq1.service". Then use "mkdir
/etc/systemd/system/uniq1.service.d" and create a
/etc/systemd/system/uniq1.service.d/blah.conf that has systemd.unit
things that override the main my_main_script.service.

On 10/14/15 9:01 PM, Stuart Longland
  wrote:


  On 15/10/15 13:23, Andrei Borzenkov wrote:

  
15.10.2015 00:30, Stuart Longland пишет:


  Assuming I have a few files distributed in the base package:
/lib/systemd/system/comms-drivers.service
/lib/systemd/system/comms-drivers@.service

Ordinarily, one would tell systemd about template instances by creating
symbolic links.

Suppose however I wanted to not do this, but instead, provide some
automatic discovery mechanism for systemd, so it could run a script that
would tell it what instances exist.

Is there a mechanism for doing this in systemd?





I'm not sure if I actually understand the question, but - templates are
instantiated on the fly. If template foo@.service exists and it is
attempted to start foo@bar.service, systemd will create it internally.
It is full fledged unit that is visible in status, can be stopped, is
part of dependency resolution etc.

  
  
Okay, that's useful to know.  So in order to start foo@bar.service, I
don't need to create any files.

Question is, how does systemd find out about the existence of
foo@bar.service without a file being present?

The idea being that the service foo.service acts as a means of
starting/stopping/querying all instances.  I would guess that
stopping/restarting/querying, systemd is smart enough to look at what's
presently running, however what about starting?

  
  
  
  ___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel



  

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] failed to change interface name (systemd-networkd)

[Martin Pitt]

Lennart Poettering [2015-10-14 18:15 +0200]:
> My educated guess is that DEbian's ifupdown scripts are responsible for
> this... IIRC they install a unit file that is pulled in on hotplug,
> and might keep the device busy...

Yes, /lib/udev/net.agent. It calls ifup or ifdown if the interface is
configured in /etc/network/interfaces, i. e. with ifupdown. But if it
does not appear in "ifquery -l" the script doesn't touch the
interface.

To be 100% sure you can temporarily move away /lib/udev/net.agent and
see if it still happens?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How does systemd discover template instances?

[Michael Chapman]

On Thu, 15 Oct 2015, Stuart Longland wrote:

Assuming I have a few files distributed in the base package:
/lib/systemd/system/comms-drivers.service
/lib/systemd/system/comms-drivers@.service

Ordinarily, one would tell systemd about template instances by creating
symbolic links.

Suppose however I wanted to not do this, but instead, provide some
automatic discovery mechanism for systemd, so it could run a script that
would tell it what instances exist.

Is there a mechanism for doing this in systemd?


Hi Stuart,

One approach you might want to consider is using a systemd generator [1] 
to create the instance symlinks automatically at boot, e.g.:


  ARGV[1]/comms-driver@some-instance.service
 -> /lib/systemd/system/comms-drivers@.service

The ARGV[1] argument passed to your generator is likely to be 
"/run/systemd/generator".


Your generator can use any mechanism it likes to decide which instances 
should be created. Note, however, the generator is run very early on in 
boot (and whenever systemd's configuration is reloaded), so it should be 
lightweight and not need any other system services to be operational.


If you have particular instances you want started at boot, you can link 
them in to the appropriate target's .wants directory, e.g.:


  ARGV[1]/multi-user.target.wants/comms-driver@some-instance.service
 -> /lib/systemd/system/comms-drivers@.service

Hope this is of assistance.

Regards,
Michael


[1] http://www.freedesktop.org/software/systemd/man/systemd.generator.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Setting the shell to the system locale

[David Adam]

Hi,

I work on fish shell, which is a non-POSIX command-line shell. I'm
trying to work out whether we should ship something in our source that 
tries to set the locale for our users. Alternatively, it might be 
something that needs to be left to distributions as it seems to be handled 
very differently.

Is /etc/locale.conf appropriate for consumption by clients other than 
systemd - such as shells? That is, is the format stable? If not, is there 
a way of querying the default system locale if there is no `LANG` (etc.) 
set in the environment - through `localectl` or otherwise?

A broader question is: which process should be responsible for setting the 
locale? Are the comments in the log message for 1640944a84 still 
appropriate?

> Eventually we probably want to drop this again since the system locale
> should be read and set at one place, and not at multiple, and that one 
> place should be PID 1.

I am not sure there is a good answer to this question, but I would be 
interested in hearing about the rationale for the different approaches. 
For example, Debian sets up PAM to source /etc/default/locale for all 
sessions, while Fedora drops a script in /etc/profile.d for command-line 
shells. Most graphical shells seem to use their own defaults.

Thanks

David Adam
zanc...@ucc.gu.uwa.edu.au
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-run returns with 'Failed to start transient scope unit: Unit run-13034.scope already exists.'

[Petr Horacek]

Sorry, I was referring to this issue:
[1] https://github.com/systemd/systemd/issues/1351
Which refers to: https://bugs.freedesktop.org/show_bug.cgi?id=86520
(Bug 86520 - Race condition on systemd-run --scope)

We run systemd-219-18.el7.x86_64 on the failing test server.

Regards,
Petr

2015-10-15 15:39 GMT+02:00 Petr Horacek :

> That's the link, yes.
>
> We run systemd-219-18.el7.x86_64 on the test server.
>
> Petr
>
> 2015-10-15 15:09 GMT+02:00 Dan Kenigsberg :
>
>> On Thu, Oct 15, 2015 at 01:25:55PM +0200, Petr Horacek wrote:
>> > Hello,
>> >
>> > recently we encountered strange systemd problem on automated tests of
>> > networking
>> > part of oVirt VDSM project.
>> >
>> > Sometimes this happens:
>> > $ /usr/sbin/ifdown enp1s0f1
>> > $ /usr/bin/systemd-run --scope --slice=vdsm-dhclient /usr/sbin/ifup
>> enp1s0f1
>> > Failed to start transient scope unit: Unit run-13034.scope already
>> exists.
>> >
>> > systemd-run should create a new scope every time it's called, should not
>> > it? Could it be
>> > a racefull bug in systemd?
>> >
>> > I found recently added issue [1] which describes similar problem, but
>> with
>> > --unit instead
>> > of --slice. Note that our machine which reproduced it has systemd older
>> > than v220.
>> >
>> > Is it possible, that this is the same case as described in [1] and
>> > therefore it should be
>> > fixed in systemd 220?
>> >
>> > Is it possible to backport [1]'s fix to EL7?
>>
>> I think Petr refers to
>>
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=86520
>> Bug 86520 - Race condition on systemd-run --scope
>>
>> Petr, can you provide the precise systemd build with which we see
>> our Bug 1259468 - Setupnetworks fails from time to time with error
>> 'Failed to bring interface up'
>> https://bugzilla.redhat.com/show_bug.cgi?id=1259468
>>
>> Regards,
>> Dan.
>>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Block device shutdown "hook"

[Ian Pilcher]

Does systemd provide any sort of "hook" mechanism to call a script
program when a block device is unmounted (or otherwise no longer being
used) on shutdown?

I'm toying with the idea of creating an alternative way of managing
dm-cache devices -- something that will operate a bit more like bcache,
rather than LVM cache.  It seems to be pretty straightforward, except
for the need to properly shutdown the dm-cache once any filesystems,
VGs, etc., on it are no longer in use.

Is there a way to tell systemd how to "shut down" a block device?

Thanks!
--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fix for - udev/ata_id failing on SATA drives behind JMicron USB bridge

[Harendra Kumar]

In fact I tried to find that information on github before sending this
email. The 'Blame' tab on github showed only a refactoring change touching
these lines of code. Also, the file seems to have been imported from
elsewhere in github and it seems github does not seem to know the history
before the import. I am not a git expert - maybe I could use some git
commands in my cloned repository to find that info - will have to dig more
on that unless someone here can give me a pointer on how to find it.

-harendra

On Wed, Oct 14, 2015 at 9:32 PM, Lennart Poettering 
wrote:

> On Wed, 30.09.15 20:40, Harendra Kumar (harendra.ku...@gmail.com) wrote:
>
> > I have a few drives in an enclosure (mediasonic pro box) connected via
> USB
> > using a Jmicron USB bridge (ID 152d:0567 JMicron Technology Corp.). I am
> > not able to create the desired names ("ata--") for these
> > devices in /dev/disk/by-id because ata_id is unable to retrieve the ATA
> > device identity information for these drives.
> >
> > I did some root causing and found where the problem lies. The ATA Pass
> > Through command (
> >
> https://github.com/systemd/systemd/blob/master/src/udev/ata_id/ata_id.c#L130
> )
> > sets the check condition flag (CK_COND=1). In the response it expects and
> > checks for sense data -
> >
> https://github.com/systemd/systemd/blob/master/src/udev/ata_id/ata_id.c#L178
> > .
> >
> > It seems the JMicron USB bridge successfully responds to the ATA IDENTIFY
> > DEVICE command but it does not return any sense data along with it and
> > therefore the disk_identify_command() function returns EIO even though
> the
> > command was successful and we got all that we needed. I checked by
> removing
> > this condition and the ata_id output was found to be accurate.
> >
> > The behavior implemented by ata_id seems to be correct strictly speaking
> as
> > per the SAT draft. It seems the Jmicron USB hardware does not comply with
> > the standard. Here is an excerpt from page 123 of the SAT draft I found
> by
> > googling (
> >
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.394.3605=rep1=pdf
> > ).
> >
> > -snip-
> > The CK_COND (Check Condition) bit may be used to request the SATL to
> return
> > a copy of ATA register information in the sense data upon command
> > completion. If the CK_COND bit is set to one the SATL shall return a
> status
> > of CHECK CONDITION when the ATA command completes, even if the command
> > completes successfully, and return the ATA Normal Output fields (see
> > ATA8-ACS) in the sense data using the ATA Return descriptor (see 12.2.6).
> > If the CK_COND bit is set to zero, then the SATL shall terminate the
> > command with CHECK CONDITION status only if an error occurs in processing
> > the command. See clause 11 for a description of ATA error conditions.
> > -snip-
> >
> > Can anyone suggest what the right fix for this would be? One way I can
> > think of is to not set the CK_COND flag in the command and check for
> sense
> > error only if check condition status/sense data was returned by the
> device.
> > This seems to be the way smartctl works for SAT devices and that's why it
> > works for my JMicron as well. Will this cause any problems? Why was the
> > code written this way in the first place? Is there a better fix for this?
>
> I figure you should put the folks who wrote that code specifically in
> CC, as they might not be on this ML. You may find that information in
> the git history data.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fix for - udev/ata_id failing on SATA drives behind JMicron USB bridge

[Mantas Mikulėnas]

On Fri, Oct 16, 2015 at 5:44 AM, Harendra Kumar 
wrote:

> In fact I tried to find that information on github before sending this
> email. The 'Blame' tab on github showed only a refactoring change touching
> these lines of code. Also, the file seems to have been imported from
> elsewhere in github and it seems github does not seem to know the history
> before the import. I am not a git expert - maybe I could use some git
> commands in my cloned repository to find that info - will have to dig more
> on that unless someone here can give me a pointer on how to find it.
>

Try `tig blame src/udev/ata_id/ata_id.c`, it follows renames and you can
jump to an older commit using , and back using <

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel