Re: [systemd-devel] Offtopic question.

2013-01-02 Thread Stef Bon 
No problem. Just a misunderstading or how you want to call it.

Stef


2013/1/2 Dave Reisner 

>
> On Jan 2, 2013 5:41 PM, "Stef Bon"  wrote:
> >
> > You are sure?? I mean the locks file, not the mounts file.
> > I think you haven't understood my post very good.
>
> Not a lack of understanding, just misread it. My bad.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Offtopic question.

2013-01-02 Thread Dave Reisner 
On Jan 2, 2013 5:41 PM, "Stef Bon"  wrote:
>
> You are sure?? I mean the locks file, not the mounts file.
> I think you haven't understood my post very good.

Not a lack of understanding, just misread it. My bad.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Offtopic question.

2013-01-02 Thread Stef Bon 
You are sure?? I mean the locks file, not the mounts file.
I think you haven't understood my post very good.

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

Re: [systemd-devel] Offtopic question.

2013-01-02 Thread Dave Reisner 
On Jan 2, 2013 4:59 PM, "Stef Bon"  wrote:
>
> Hi,
>
> sorry for the offtopic question here, but I do not know a better place
for it.
>
> I'm building a lockmonitor. I thought that would be just as easy as with
the /proc/self/mountinfo "file".
>
> But that is not the case. It's not pollable, like the mountinfo fle is.
> I've looked into the code of the kernel, (fs/locks.c versus
fs/proc_namespace.c) and there it's abvious. The file_operations with the
locks file misses the .poll operation.

Hmmm, regardless, the file is pollable. findmnt polls it (systemd as well?)
-- you need to watch for POLLERR events.

> Now first howto implement this? Someone a hint?
>
> The mountinfo poll function is related to changes in namespace, but for
the locks that is different I guess. That "changes" when a lock has been
set or released.
>
> And by the way, isn't this locks file not namespace specific?
>
> Stef
>
> ___
> 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

[systemd-devel] Offtopic question.

2013-01-02 Thread Stef Bon 
Hi,

sorry for the offtopic question here, but I do not know a better place for
it.

I'm building a lockmonitor. I thought that would be just as easy as with
the /proc/self/mountinfo "file".

But that is not the case. It's not pollable, like the mountinfo fle is.
I've looked into the code of the kernel, (fs/locks.c versus
fs/proc_namespace.c) and there it's abvious. The file_operations with the
locks file misses the .poll operation.

Now first howto implement this? Someone a hint?

The mountinfo poll function is related to changes in namespace, but for the
locks that is different I guess. That "changes" when a lock has been set or
released.

And by the way, isn't this locks file not namespace specific?

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

Re: [systemd-devel] systemd-fstab-generator and multiple mounts to same mount point

2013-01-02 Thread John Lane 

On 02/01/13 14:25, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jan 02, 2013 at 12:44:10PM +, John Lane wrote:

On 02/01/13 12:15, Andrey Borzenkov wrote:

В Wed, 02 Jan 2013 12:01:41 +
John Lane  пишет:


Hello,

I have a configuration where a filesystem is mounted on /images.

Then a subdirectory of that filesystem, say /images/1, is bind mounted
on top as /images.

I think the problem is how systemd names the generated mount units.
If there is a clash, could it not
use a modified name for the unit (e.g if
/run/systemd/generator/images.mount exists it would create
/run/systemd/generator/images-1.mount or something like that) ?

Hi,

it's on the TODO list ("* properly handle .mount unit state tracking
when two mount points are stacked one on top of another on the exact
same mount point.") Patches welcome :)

Zbyszek

Good to know, thanks. I'll take a look and see if I'll provide a patch 
if I can.
But I have never looked inside systemd so I may need some pointers to 
find my way around it.


@tom: good point about not including a "-" in any variant filename.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] [RFC]logind: set locale in user sessions

2013-01-02 Thread Tom Gundersen 
On Wed, Jan 2, 2013 at 12:55 PM, Andrey Borzenkov  wrote:
> В Wed,  2 Jan 2013 12:46:31 +0100
> Tom Gundersen  пишет:
>> The logic is: the kernel command-line takes precedence,
>
> Why? I would understand it if list did not include user-specific
> locale.conf; but if it does, why system wide setting should override
> user specific one? To me it looks like order should be reversed (user's
> local.conf followed by kernel setting).

We tend to let the kernel command line override everything. This is
useful in case the kernel command line is used as a temporary
work-around in case somehow a wrong locale has been set, rendering the
system unusable.

If the kernel command-line is used as a permanent mechanism for
setting up the locale, I see that this is not ideal.

I don't feel strongly either way.

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

Re: [systemd-devel] sometimes systemd takes a very long time to restart service

2013-01-02 Thread JB 

Andrey Borzenkov wrote:

В Wed, 02 Jan 2013 04:02:27 -0700
JB  пишет:

  

Andrey Borzenkov wrote:


В Wed, 02 Jan 2013 02:28:19 -0700
JB  пишет:

  
  

Here's the service file:
***
[Unit]
Description=Webrick Test Service
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/ruby /home/rtuser/test.rb

[Install]
WantedBy=multi-user.target
***

I put this in /etc/systemd/system/webrickd.service
Then ran systemctl --system daemon-reload
Then ran systemctl start webrickd.service

Running it from the command line runs as it should.  Web server starts 
and test.rb is running in the background as a daemon returning me back 
to the shell.


But as soon as I try to use systemd, it starts but as soon as the 
WEBrick::Daemon.start call is made, everything is killed.



That is because of ...
  
  

webrickd.service - Webrick Test Service
  Loaded: loaded (/etc/systemd/system/webrickd.service)
  Active: inactive (dead) since Wed, 02 Jan 2013 01:23:01 -0700; 
9min ago
 Process: 1605 ExecStart=/usr/bin/ruby /home/rtuser/test.rb 
(code=exited, status=0/SUCCESS)

Main PID: 1607 (code=exited, status=0/SUCCESS)



   ^^
  
  

  CGroup: name=systemd:/system/webrickd.service




You daemon forks too much. This would be a problem with some of
implementations of initscript as well. Even worse, it may sometimes
work due to race condition and sometimes it may fail.
  
  

As far as I know, it forks once.  You sure it forks "too much?"



The only other explanation would be that daemon simply exits
immediately. But then it hardly can be called "daemon"?  
  
Agreed, only other thing I could think of is if it is somehow 
immediately getting a SIGINT or SIGTERM somehow.
  
Not interested in shooting anyone but I am interested in the 
interpretation of "programming error."  Seems like you're assuming the 
systemd assumptions and paradigm are perfect.  Pretty sure Unix never 
dictated default forking limits, at least not until things like fork 
bombs came about and security issues were considered.  Forking more than 
once could hardly be considered a programming error.  I think systemd 
folks came up with that one all by themselves :)  My point is that 
assuming systemd's default allow one fork approach is "pure" and then 
passing the rigid inflexibility off as design flaws and programming 
errors on the part of daemon developers, IMHO goes too far.

  
  


systemd monitors service. Service is represented by process. If you
allow unlimited flexibility in how many times service can fork before
it finally starts its main process - how can systemd know which process
to monitor? When fork chain stops? I am sure if you suggest race free
way to do it that works in all cases, everyone will be happy to
integrate it in systemd.

If you do not really care whether systemd can monitor state of service
and are OK with "start it and forget about it", just add
RemainAfterExit=true. sytemd is flexible enough to support both ways.

  
So, if I proceed using "Simple" and then later as a result of one of the 
web service calls made to the server either use fork/exec or system() to 
launch another process that runs for anywhere from 30 seconds to several 
hours, then that process exits but not the one that originally started, 
will systemd have a problem with that?





It should not. That is what many services do already.

  

Thanks, I'll try that.

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

Re: [systemd-devel] systemd-fstab-generator and multiple mounts to same mount point

2013-01-02 Thread Tom Gundersen 
On Wed, Jan 2, 2013 at 1:44 PM, John Lane  wrote:
> I think the problem is how systemd names the generated mount units. If there
> is a clash, could it not
> use a modified name for the unit (e.g if /run/systemd/generator/images.mount
> exists it would create /run/systemd/generator/images-1.mount or something
> like that) ?

Note that that particular naming scheme would not work. Check out the
escaping logic in systemd.unit(5).

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

Re: [systemd-devel] systemd-fstab-generator and multiple mounts to same mount point

2013-01-02 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Jan 02, 2013 at 12:44:10PM +, John Lane wrote:
> On 02/01/13 12:15, Andrey Borzenkov wrote:
> >В Wed, 02 Jan 2013 12:01:41 +
> >John Lane  пишет:
> >
> >>Hello,
> >>
> >>I have a configuration where a filesystem is mounted on /images.
> >>
> >>Then a subdirectory of that filesystem, say /images/1, is bind mounted
> >>on top as /images.
>
> I think the problem is how systemd names the generated mount units.
> If there is a clash, could it not
> use a modified name for the unit (e.g if
> /run/systemd/generator/images.mount exists it would create
> /run/systemd/generator/images-1.mount or something like that) ?
Hi,

it's on the TODO list ("* properly handle .mount unit state tracking
when two mount points are stacked one on top of another on the exact
same mount point.") Patches welcome :)

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

Re: [systemd-devel] sometimes systemd takes a very long time to restart service

2013-01-02 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Jan 02, 2013 at 02:28:19AM -0700, JB wrote:
> Andrey Borzenkov wrote:
> >В Tue, 01 Jan 2013 23:37:56 -0700
> >JB  пишет:
> >>Andrey Borzenkov wrote:
> >>>В Tue, 01 Jan 2013 18:52:38 -0700
> >>>JB  пишет:
> Thanks!  I'll try and it may work in my case.  What's
> interesting is that in your case it sounded like rsyslog was
> hanging around while it was having problems dealing with the
> condition of having the network unavailable.  In my case,
> webrickd actually stops and shuts down almost immediately
> but for some reason systemd doesn't or can't figure that
> out.
> >>>Showing "systemctl status webrickd.service" before restarting and
> >>>during restart may give some hints.
> >>Good idea.
> >>
> >>It goes from active/running to this immediately after restart...
> >>
> >>webrickd.service - Configuration ruby webrick daemon
> >>  Loaded: loaded (/etc/systemd/system/webrickd.service)
> >>  Active: deactivating (final-sigterm) since Tue, 01 Jan
> >>2013 22:44:39 -0700; 1min 14s ago
> >> Process: 15771
> >>ExecStart=/home/rtuser/app/bin/webrickd.rb -d -p
> >>/home/rtuser/app/data/logs/webrickd.pid (code=exited,
> >>status=0/SUCCESS)
> >>
> >>Then this, anywhere from 1 to 3 minutes later...
> >>
> >>webrickd.service - Configuration ruby webrick daemon
> >>  Loaded: loaded (/etc/systemd/system/webrickd.service)
> >>  Active: active (running) since Tue, 01 Jan 2013
> >>22:47:40 -0700; 15s ago
> >> Process: 15807
> >>ExecStart=/home/rtuser/app/bin/webrickd.rb -d -p
> >>/home/rtuser/app/data/logs/webrickd.pid (code=exited,
> >>status=0/SUCCESS)
> >
> >And initial state (i.e. after it is started)?
> >
> >>Any ideas why it sits in state "deactivating (final-sigterm)"
> >>for 1 to 3 minutes
> It gets better.  I took a very stripped simple daemon to try to
> understand the interaction between systemd and the process.  Here it
> is:
Hi,
your process is forking as it should (as least on my machine).
Putting systemd in debug mode 
sudo kill -SIGRTMIN+22 1
and running
sudo systemctl start webrickd.service
gives me:
Jan 02 08:55:27 spora sudo[20648]: zbyszek : TTY=pts/0 ; 
PWD=/home/zbyszek/src/systemd ; USER=root ; COMMAND=/bin/systemctl start 
webrickd.service
Jan 02 08:55:27 spora systemd[1]: Accepted connection on private bus.
Jan 02 08:55:27 spora systemd[1]: Running GC...
Jan 02 08:55:27 spora systemd[1]: Got D-Bus request: 
org.freedesktop.systemd1.Manager.StartUnit() on /org/freedesktop/systemd1
Jan 02 08:55:27 spora systemd[1]: Trying to enqueue job 
webrickd.service/start/replace
Jan 02 08:55:27 spora systemd[1]: Installed new job webrickd.service/start as 
2851
Jan 02 08:55:27 spora systemd[1]: Enqueued job webrickd.service/start as 2851
Jan 02 08:55:27 spora systemd[1]: About to execute: /usr/bin/ruby 
/home/zbyszek/src/systemd/test.rb
Jan 02 08:55:27 spora systemd[1]: Forked /usr/bin/ruby as 20651
Jan 02 08:55:27 spora systemd[1]: webrickd.service changed failed -> start
Jan 02 08:55:27 spora systemd[1]: Got D-Bus request: 
org.freedesktop.systemd1.Manager.GetUnit() on /org/freedesktop/systemd1
Jan 02 08:55:27 spora systemd[1]: Got D-Bus request: 
org.freedesktop.DBus.Properties.Get() on 
/org/freedesktop/systemd1/unit/webrickd_2eservice
Jan 02 08:55:27 spora systemd[1]: Received SIGCHLD from PID 20651 (ruby).
Jan 02 08:55:27 spora systemd[1]: Got SIGCHLD for process 20651 (ruby)
Jan 02 08:55:27 spora systemd[1]: Child 20651 died (code=exited, 
status=0/SUCCESS)
Jan 02 08:55:27 spora systemd[1]: Child 20651 belongs to webrickd.service
Jan 02 08:55:27 spora systemd[1]: webrickd.service: control process exited, 
code=exited status=0
Jan 02 08:55:27 spora systemd[1]: webrickd.service got final SIGCHLD for state 
start
Jan 02 08:55:27 spora systemd[1]: Main PID guessed: 20653
Jan 02 08:55:27 spora systemd[1]: webrickd.service changed start -> running
Jan 02 08:55:27 spora systemd[1]: Job webrickd.service/start finished, 
result=done
Jan 02 08:55:27 spora systemd[1]: Got D-Bus request: 
org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local
Jan 02 08:55:27 spora systemd[1]: Received SIGCHLD from PID 20653 (ruby).
Jan 02 08:55:27 spora systemd[1]: Got SIGCHLD for process 20653 (ruby)
Jan 02 08:55:27 spora systemd[1]: Child 20653 died (code=exited, 
status=0/SUCCESS)
Jan 02 08:55:27 spora systemd[1]: Child 20653 belongs to webrickd.service
Jan 02 08:55:27 spora systemd[1]: webrickd.service: main process exited, 
code=exited, status=0
Jan 02 08:55:27 spora systemd[1]: webrickd.service changed running -> 
stop-sigterm
Jan 02 08:55:27 spora systemd[1]: Received SIGCHLD from PID 20656 (ruby).
Jan 02 08:55:27 spora systemd[1]: Got SIGCHLD for process 20656 (ruby)
Jan 02 08:55:27 spora systemd[1]: Child 20656 died (code=exited, 
status=1/FAILURE)
Jan 02 08:55:27 spora systemd[1]: Accepted connection on private bus.
Jan 02 08:55:27 spora systemd[1]: Got D-Bus request: 
org.freedesktop.systemd1.Agent.Released() on /or

Re: [systemd-devel] systemd-fstab-generator and multiple mounts to same mount point

2013-01-02 Thread John Lane 

On 02/01/13 12:15, Andrey Borzenkov wrote:

В Wed, 02 Jan 2013 12:01:41 +
John Lane  пишет:


Hello,

I have a configuration where a filesystem is mounted on /images.

Then a subdirectory of that filesystem, say /images/1, is bind mounted
on top as /images.

Prior to moving to systemd, this kind of thing has always worked fine
with /etc/fstab containing something like this:

# images uuid 8847d358-c4f6-4405-a65c-e0c514151f8e is on /dev/sda1
UUID=8847d358-c4f6-4405-a65c-e0c514151f8e /images ext3 defaults 0 1

# Bind mount current images on /images
#/images/1354 /images none rw,bind 0 0

With systemd, systemd-fstab-generator complains about the second use of
the /images mount point:

Jan 02 08:31:58 neon systemd-fstab-generator[79]: Failed to create unit
file /run/systemd/generator/images.mount: File exists
Jan 02 08:31:58 neon systemd[1]:
/usr/lib/systemd/system-generators/systemd-fstab-generator exited with
exit status 1.

How should this situation be handled with systemd ?


Mount first time somewhere else? Like /image_archive? And bind
mount /image_archive/1354 to /images?

I realise I can work around the problem (that's what I am doing right 
now) but I want the mounts to be done in that way (one over the other).


As such an /etc/fstab worked fine before systemd it would be good if it 
continued to work with systemd.


I think the problem is how systemd names the generated mount units. If 
there is a clash, could it not
use a modified name for the unit (e.g if 
/run/systemd/generator/images.mount exists it would create 
/run/systemd/generator/images-1.mount or something like that) ?



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

Re: [systemd-devel] systemd-fstab-generator and multiple mounts to same mount point

2013-01-02 Thread Andrey Borzenkov 
В Wed, 02 Jan 2013 12:01:41 +
John Lane  пишет:

> Hello,
> 
> I have a configuration where a filesystem is mounted on /images.
> 
> Then a subdirectory of that filesystem, say /images/1, is bind mounted 
> on top as /images.
> 
> Prior to moving to systemd, this kind of thing has always worked fine 
> with /etc/fstab containing something like this:
> 
> # images uuid 8847d358-c4f6-4405-a65c-e0c514151f8e is on /dev/sda1
> UUID=8847d358-c4f6-4405-a65c-e0c514151f8e /images ext3 defaults 0 1
> 
> # Bind mount current images on /images
> #/images/1354 /images none rw,bind 0 0
> 
> With systemd, systemd-fstab-generator complains about the second use of 
> the /images mount point:
> 
> Jan 02 08:31:58 neon systemd-fstab-generator[79]: Failed to create unit 
> file /run/systemd/generator/images.mount: File exists
> Jan 02 08:31:58 neon systemd[1]: 
> /usr/lib/systemd/system-generators/systemd-fstab-generator exited with 
> exit status 1.
> 
> How should this situation be handled with systemd ?
> 

Mount first time somewhere else? Like /image_archive? And bind
mount /image_archive/1354 to /images?

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

Re: [systemd-devel] sometimes systemd takes a very long time to restart service

2013-01-02 Thread Andrey Borzenkov 
В Wed, 02 Jan 2013 04:02:27 -0700
JB  пишет:

> Andrey Borzenkov wrote:
> > В Wed, 02 Jan 2013 02:28:19 -0700
> > JB  пишет:
> >
> >   
> >> Here's the service file:
> >> ***
> >> [Unit]
> >> Description=Webrick Test Service
> >> After=network.target
> >>
> >> [Service]
> >> Type=forking
> >> ExecStart=/usr/bin/ruby /home/rtuser/test.rb
> >>
> >> [Install]
> >> WantedBy=multi-user.target
> >> ***
> >>
> >> I put this in /etc/systemd/system/webrickd.service
> >> Then ran systemctl --system daemon-reload
> >> Then ran systemctl start webrickd.service
> >>
> >> Running it from the command line runs as it should.  Web server starts 
> >> and test.rb is running in the background as a daemon returning me back 
> >> to the shell.
> >>
> >> But as soon as I try to use systemd, it starts but as soon as the 
> >> WEBrick::Daemon.start call is made, everything is killed.
> >> 
> > That is because of ...
> >   
> >> webrickd.service - Webrick Test Service
> >>   Loaded: loaded (/etc/systemd/system/webrickd.service)
> >>   Active: inactive (dead) since Wed, 02 Jan 2013 01:23:01 -0700; 
> >> 9min ago
> >>  Process: 1605 ExecStart=/usr/bin/ruby /home/rtuser/test.rb 
> >> (code=exited, status=0/SUCCESS)
> >> Main PID: 1607 (code=exited, status=0/SUCCESS)
> >> 
> >^^
> >   
> >>   CGroup: name=systemd:/system/webrickd.service
> >>
> >> 
> >
> > You daemon forks too much. This would be a problem with some of
> > implementations of initscript as well. Even worse, it may sometimes
> > work due to race condition and sometimes it may fail.
> >   
> As far as I know, it forks once.  You sure it forks "too much?"

The only other explanation would be that daemon simply exits
immediately. But then it hardly can be called "daemon"?  

> Not interested in shooting anyone but I am interested in the 
> interpretation of "programming error."  Seems like you're assuming the 
> systemd assumptions and paradigm are perfect.  Pretty sure Unix never 
> dictated default forking limits, at least not until things like fork 
> bombs came about and security issues were considered.  Forking more than 
> once could hardly be considered a programming error.  I think systemd 
> folks came up with that one all by themselves :)  My point is that 
> assuming systemd's default allow one fork approach is "pure" and then 
> passing the rigid inflexibility off as design flaws and programming 
> errors on the part of daemon developers, IMHO goes too far.
> >   

systemd monitors service. Service is represented by process. If you
allow unlimited flexibility in how many times service can fork before
it finally starts its main process - how can systemd know which process
to monitor? When fork chain stops? I am sure if you suggest race free
way to do it that works in all cases, everyone will be happy to
integrate it in systemd.

If you do not really care whether systemd can monitor state of service
and are OK with "start it and forget about it", just add
RemainAfterExit=true. sytemd is flexible enough to support both ways.

> 
> So, if I proceed using "Simple" and then later as a result of one of the 
> web service calls made to the server either use fork/exec or system() to 
> launch another process that runs for anywhere from 30 seconds to several 
> hours, then that process exits but not the one that originally started, 
> will systemd have a problem with that?
> 

It should not. That is what many services do already.

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

[systemd-devel] systemd-fstab-generator and multiple mounts to same mount point

2013-01-02 Thread John Lane 

Hello,

I have a configuration where a filesystem is mounted on /images.

Then a subdirectory of that filesystem, say /images/1, is bind mounted 
on top as /images.


Prior to moving to systemd, this kind of thing has always worked fine 
with /etc/fstab containing something like this:


# images uuid 8847d358-c4f6-4405-a65c-e0c514151f8e is on /dev/sda1
UUID=8847d358-c4f6-4405-a65c-e0c514151f8e /images ext3 defaults 0 1

# Bind mount current images on /images
#/images/1354 /images none rw,bind 0 0

With systemd, systemd-fstab-generator complains about the second use of 
the /images mount point:


Jan 02 08:31:58 neon systemd-fstab-generator[79]: Failed to create unit 
file /run/systemd/generator/images.mount: File exists
Jan 02 08:31:58 neon systemd[1]: 
/usr/lib/systemd/system-generators/systemd-fstab-generator exited with 
exit status 1.


How should this situation be handled with systemd ?

Thanks,
John


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

Re: [systemd-devel] [PATCH] [RFC]logind: set locale in user sessions

2013-01-02 Thread Andrey Borzenkov 
В Wed,  2 Jan 2013 12:46:31 +0100
Tom Gundersen  пишет:

> Changes the pam module to now set the locale for user-sessions, similarly to
> what is done system-wide in PID1.
> 
> The logic is: the kernel command-line takes precedence,

Why? I would understand it if list did not include user-specific
locale.conf; but if it does, why system wide setting should override
user specific one? To me it looks like order should be reversed (user's
local.conf followed by kernel setting).

> then
> XDG_CONFIG_HOME/locale.conf, then /etc/locale.conf and finally any legacy
> distro-specific files that might still be supported.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] [RFC]logind: set locale in user sessions

2013-01-02 Thread Tom Gundersen 
Changes the pam module to now set the locale for user-sessions, similarly to
what is done system-wide in PID1.

The logic is: the kernel command-line takes precedence, then
XDG_CONFIG_HOME/locale.conf, then /etc/locale.conf and finally any legacy
distro-specific files that might still be supported.

The parsing of the locale settings is split out of core/ and moved to shared/.

This is an important feature for Arch, as we traditionally set the system locale
in all user sessions, so this means we can remove a work-around [0] and close 
some
related bugs (e.g., [1]).

[0]:

[1]: 
---
 Makefile.am   |   5 +-
 man/locale.conf.xml   |  17 +++-
 src/core/locale-setup.c   | 196 ++
 src/login/pam-module.c|  57 ++
 src/shared/locale-parse.c | 196 ++
 src/shared/locale-parse.h |  63 +++
 6 files changed, 341 insertions(+), 193 deletions(-)
 create mode 100644 src/shared/locale-parse.c
 create mode 100644 src/shared/locale-parse.h

diff --git a/Makefile.am b/Makefile.am
index 94ae549..f78ce99 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -847,7 +847,10 @@ libsystemd_shared_la_SOURCES = \
src/shared/time-dst.c \
src/shared/time-dst.h \
src/shared/calendarspec.c \
-   src/shared/calendarspec.h
+   src/shared/calendarspec.h \
+   src/shared/locale-parse.c \
+   src/shared/locale-parse.h
+
 
 libsystemd_shared_la_LIBADD = libsystemd-daemon.la
 
diff --git a/man/locale.conf.xml b/man/locale.conf.xml
index 06c0af0..5d8e99a 100644
--- a/man/locale.conf.xml
+++ b/man/locale.conf.xml
@@ -49,6 +49,7 @@
 
 
 /etc/locale.conf
+$XDG_CONFIG_HOME/locale.conf
 
 
 
@@ -57,7 +58,14 @@
 The /etc/locale.conf file
 configures system-wide locale settings. It is read at
 early-boot by
-
systemd1.
+
systemd1
+and at session-start by
+
pam_systemd8.
+
+The $XDG_CONFIG_HOME/locale.conf
+file configures user-specific locale settings. It is read
+at session-start by
+
pam_systemd8.
 
 The basic file format of
 locale.conf is a
@@ -87,6 +95,13 @@
 used to override the locale settings at boot.
 
 The locale settings configured in
+$XDG_CONFIG_HOME/locale.conf, are
+user-specific and are inherited by every program in the
+users session, unless overridden or unset by individual
+programs.
+
+
+The locale settings configured in
 /etc/locale.conf are system-wide
 and are inherited by every service or user, unless
 overridden or unset by individual programs or
diff --git a/src/core/locale-setup.c b/src/core/locale-setup.c
index 8821fc2..f4ecb9e 100644
--- a/src/core/locale-setup.c
+++ b/src/core/locale-setup.c
@@ -19,208 +19,22 @@
   along with systemd; If not, see .
 ***/
 
-#include 
 #include 
 #include 
 
 #include "locale-setup.h"
-#include "util.h"
+#include "locale-parse.h"
 #include "macro.h"
-#include "virt.h"
-
-enum {
-/* We don't list LC_ALL here on purpose. People should be
- * using LANG instead. */
-
-VARIABLE_LANG,
-VARIABLE_LANGUAGE,
-VARIABLE_LC_CTYPE,
-VARIABLE_LC_NUMERIC,
-VARIABLE_LC_TIME,
-VARIABLE_LC_COLLATE,
-VARIABLE_LC_MONETARY,
-VARIABLE_LC_MESSAGES,
-VARIABLE_LC_PAPER,
-VARIABLE_LC_NAME,
-VARIABLE_LC_ADDRESS,
-VARIABLE_LC_TELEPHONE,
-VARIABLE_LC_MEASUREMENT,
-VARIABLE_LC_IDENTIFICATION,
-_VARIABLE_MAX
-};
-
-static const char * const variable_names[_VARIABLE_MAX] = {
-[VARIABLE_LANG] = "LANG",
-[VARIABLE_LANGUAGE] = "LANGUAGE",
-[VARIABLE_LC_CTYPE] = "LC_CTYPE",
-[VARIABLE_LC_NUMERIC] = "LC_NUMERIC",
-[VARIABLE_LC_TIME] = "LC_TIME",
-[VARIABLE_LC_COLLATE] = "LC_COLLATE",
-[VARIABLE_LC_MONETARY] = "LC_MONETARY",
-[VARIABLE_LC_MESSAGES] = "LC_MESSAGES",
-[VARIABLE_LC_PAPER] = "LC_PAPER",
-[VARIABLE_LC_NAME] = "LC_NAME",
-[VARIABLE_LC_ADDRESS] = "LC_ADDRESS",
-[VARIABLE_LC_TELEPHONE] = "LC_TELEPHONE",
-[VARIABLE_LC_MEASUREMENT] = "LC_MEASUREMENT",
-[VARIABLE_LC_IDENTIFICATION] = "LC_IDENTIFICATION"
-};
 
 int locale_setup(void) {
 char *variables[_VARIABLE_MAX];
-int r = 0, i;
+int r, i;
 
 zero(variables);
 
-if (detect_container(NULL) <= 0) {
-r = parse_env_file(

[systemd-devel] [PATCH] Added globbing support to EnvironmentFile

2013-01-02 Thread Pekka Lundstrom 
This patch allows globbing to be used with EnvironmentFile option.
Example:
EnvironmentFile=/etc/foo.d/*.conf

t. Pekka
---
Signed-off-by: Pekka Lundstrom 

---
 man/systemd.exec.xml |2 +-
 src/core/execute.c   |   51 ++
 2 files changed, 40 insertions(+), 13 deletions(-)

diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index 6ca7405..302ac43 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -291,7 +291,7 @@
 double quotes (").
 The
 argument passed should be an absolute
-file name, optionally prefixed with
+file name or wildcard expression, optionally 
prefixed with
 "-", which indicates that if the file
 does not exist it won't be read and no
 error or warning message is
diff --git a/src/core/execute.c b/src/core/execute.c
index 7628470..bf0458e 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef HAVE_PAM
 #include 
@@ -1657,6 +1658,8 @@ int exec_context_load_environment(const ExecContext *c, 
char ***l) {
 int k;
 bool ignore = false;
 char **p;
+glob_t pglob;
+int count, n;
 
 fn = *i;
 
@@ -1674,29 +1677,53 @@ int exec_context_load_environment(const ExecContext *c, 
char ***l) {
 return -EINVAL;
 }
 
-if ((k = load_env_file(fn, &p)) < 0) {
+/* Filename supports globbing, take all matching files */
+pglob.gl_pathc = 0;
+pglob.gl_pathv = NULL;
+if (glob(fn, 0, NULL, &pglob) != 0) {
+globfree(&pglob);
+if (ignore)
+continue;
 
+strv_free(r);
+return -EINVAL;
+}
+if ((count = pglob.gl_pathc) == 0) {
+globfree(&pglob);
 if (ignore)
 continue;
 
 strv_free(r);
-return k;
+return -EINVAL;
 }
+for (n = 0; n < count; n++) {
+if ((k = load_env_file(pglob.gl_pathv[n], &p)) < 0) {
+if (ignore)
+continue;
 
-if (r == NULL)
-r = p;
-else {
-char **m;
+strv_free(r);
+globfree(&pglob);
+return k;
+ }
 
-m = strv_env_merge(2, r, p);
-strv_free(r);
-strv_free(p);
+if (r == NULL)
+r = p;
+else {
+char **m;
 
-if (!m)
-return -ENOMEM;
+m = strv_env_merge(2, r, p);
+strv_free(r);
+strv_free(p);
 
-r = m;
+if (!m) {
+globfree(&pglob);
+return -ENOMEM;
+}
+
+r = m;
+}
 }
+globfree(&pglob);
 }
 
 *l = r;
-- 
1.7.9.5

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

Re: [systemd-devel] sometimes systemd takes a very long time to restart service

2013-01-02 Thread JB 

Andrey Borzenkov wrote:

В Wed, 02 Jan 2013 02:28:19 -0700
JB  пишет:

  

Here's the service file:
***
[Unit]
Description=Webrick Test Service
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/ruby /home/rtuser/test.rb

[Install]
WantedBy=multi-user.target
***

I put this in /etc/systemd/system/webrickd.service
Then ran systemctl --system daemon-reload
Then ran systemctl start webrickd.service

Running it from the command line runs as it should.  Web server starts 
and test.rb is running in the background as a daemon returning me back 
to the shell.


But as soon as I try to use systemd, it starts but as soon as the 
WEBrick::Daemon.start call is made, everything is killed.


That is because of ...
  

webrickd.service - Webrick Test Service
  Loaded: loaded (/etc/systemd/system/webrickd.service)
  Active: inactive (dead) since Wed, 02 Jan 2013 01:23:01 -0700; 
9min ago
 Process: 1605 ExecStart=/usr/bin/ruby /home/rtuser/test.rb 
(code=exited, status=0/SUCCESS)

Main PID: 1607 (code=exited, status=0/SUCCESS)


   ^^
  

  CGroup: name=systemd:/system/webrickd.service




You daemon forks too much. This would be a problem with some of
implementations of initscript as well. Even worse, it may sometimes
work due to race condition and sometimes it may fail.
  
As far as I know, it forks once.  You sure it forks "too much?"  I 
should pull an strace just to see exactly how many times it's forking so 
I can be sure.  Who decided how much forking was too much?  Pretty sure 
that's always been a "feature" of unix to be used at the discretion of 
the programmer.  Albeit an expensive one but a feature nonetheless.  Not 
trying to argue but I'm hoping you see my point.  Systemd decided that 
it would by default *only* allow daemon processes to fork once, yet 
accommodate through special configuration (RemainAfterExit) what I would 
consider normal unix programming behavior?  Init doesn't care how many 
times you fork because it's flexible that way.  Now systemd came along 
and decided that was somehow a programming error?
I'm really trying to understand systemd but it is times like this when 
do long for the simpler days of init.



initscripts often hide design or programming errors when systemd makes
them obvious. Do not shoot the messenger.
  
Not interested in shooting anyone but I am interested in the 
interpretation of "programming error."  Seems like you're assuming the 
systemd assumptions and paradigm are perfect.  Pretty sure Unix never 
dictated default forking limits, at least not until things like fork 
bombs came about and security issues were considered.  Forking more than 
once could hardly be considered a programming error.  I think systemd 
folks came up with that one all by themselves :)  My point is that 
assuming systemd's default allow one fork approach is "pure" and then 
passing the rigid inflexibility off as design flaws and programming 
errors on the part of daemon developers, IMHO goes too far.
  
If someone could tell me the "right way" to make this work with systemd, 
I would love to use it but I've been at this on and off for weeks and it 
isn't getting any easier.  From my perspective systemd appears rigid and 
quite unforgiving.  I can't call it buggy yet because I don't know that 
I've found any but it sure doesn't seem nearly as simple and easy to get 
something running at startup as the documentation would have me believe.






Currently systemd assumes "one service - one main process" model. This
process - main process - represents service for systemd. Service is
alive as long as it runs. When process exits (or terminates) systemd
considers service stopped (gracefully or ungracefully - it is another
matter).
  
Systemd also expects that program does what you say it does. When you

say that service is "simple" it expects that process is started and does
not fork. If you say that service is "forking" it expects that process
forks exactly once and child remains. It does not expect that child
itself forks yet again and exits.

  
That's what I meant when I said I tried "Simple."  I took out all 
daemonize calls.  Started ruby and made just one call to server.start 
using only an instance of WEBrick::HTTPServer (confirming it did not 
form) and it still failed.  Although I just tried it again with the over 
simplified example I had in my previous email and it worked.  I'm now 
going to have to figure out what else this ruby beast is doing that 
systemd doesn't like but if I find out it's another "normally supported" 
feature of Unix that systemd decided is no good it'll be very 
frustrating.  I'm not saying systemd is bad, but rather a little more on 
the inflexible side than I'd prefer.  It seems to force a bit more 
default big-brother type behavior than I like.  Flexibility is one of 
the things th

Re: [systemd-devel] sometimes systemd takes a very long time to restart service

2013-01-02 Thread Andrey Borzenkov 
В Wed, 02 Jan 2013 02:28:19 -0700
JB  пишет:

> Here's the service file:
> ***
> [Unit]
> Description=Webrick Test Service
> After=network.target
> 
> [Service]
> Type=forking
> ExecStart=/usr/bin/ruby /home/rtuser/test.rb
> 
> [Install]
> WantedBy=multi-user.target
> ***
> 
> I put this in /etc/systemd/system/webrickd.service
> Then ran systemctl enable webrickd.service

That is redundant. You can start service even if it is "disabled".

> Then ran systemctl --system daemon-reload
> Then ran systemctl start webrickd.service
> 
> Running it from the command line runs as it should.  Web server starts 
> and test.rb is running in the background as a daemon returning me back 
> to the shell.
> 
> But as soon as I try to use systemd, it starts but as soon as the 
> WEBrick::Daemon.start call is made, everything is killed.

That is because of ...

> webrickd.service - Webrick Test Service
>   Loaded: loaded (/etc/systemd/system/webrickd.service)
>   Active: inactive (dead) since Wed, 02 Jan 2013 01:23:01 -0700; 
> 9min ago
>  Process: 1605 ExecStart=/usr/bin/ruby /home/rtuser/test.rb 
> (code=exited, status=0/SUCCESS)
> Main PID: 1607 (code=exited, status=0/SUCCESS)
   ^^
>   CGroup: name=systemd:/system/webrickd.service
> 

You daemon forks too much. This would be a problem with some of
implementations of initscript as well. Even worse, it may sometimes
work due to race condition and sometimes it may fail.

> I'm really trying to understand systemd but it is times like this when 
> do long for the simpler days of init.

initscripts often hide design or programming errors when systemd makes
them obvious. Do not shoot the messenger.

> 
> If someone could tell me the "right way" to make this work with systemd, 
> I would love to use it but I've been at this on and off for weeks and it 
> isn't getting any easier.  From my perspective systemd appears rigid and 
> quite unforgiving.  I can't call it buggy yet because I don't know that 
> I've found any but it sure doesn't seem nearly as simple and easy to get 
> something running at startup as the documentation would have me believe.
> 
> 

Currently systemd assumes "one service - one main process" model. This
process - main process - represents service for systemd. Service is
alive as long as it runs. When process exits (or terminates) systemd
considers service stopped (gracefully or ungracefully - it is another
matter).

Systemd also expects that program does what you say it does. When you
say that service is "simple" it expects that process is started and does
not fork. If you say that service is "forking" it expects that process
forks exactly once and child remains. It does not expect that child
itself forks yet again and exits.

In your case obvious workaround is to declare RemainAfterExit=true. In
this case systemd will not consider service dead as soon as main
process exited as long as it did not fail (i.e. exit code was 0). 

Does your daemon need to keep internal state between different HTTP
requests? If not, you could make it to be socket-activated on demand.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sometimes systemd takes a very long time to restart service

2013-01-02 Thread JB 

Andrey Borzenkov wrote:

В Tue, 01 Jan 2013 23:37:56 -0700
JB  пишет:
  

Andrey Borzenkov wrote:


В Tue, 01 Jan 2013 18:52:38 -0700
JB  пишет:
  
Thanks!  I'll try and it may work in my case.  What's interesting is 
that in your case it sounded like rsyslog was hanging around while it 
was having problems dealing with the condition of having the network 
unavailable.  In my case, webrickd actually stops and shuts down almost 
immediately but for some reason systemd doesn't or can't figure that 
out.


Showing "systemctl status webrickd.service" before restarting and
during restart may give some hints.
  

Good idea.

It goes from active/running to this immediately after restart...

webrickd.service - Configuration ruby webrick daemon
  Loaded: loaded (/etc/systemd/system/webrickd.service)
  Active: deactivating (final-sigterm) since Tue, 01 Jan 2013 
22:44:39 -0700; 1min 14s ago
 Process: 15771 ExecStart=/home/rtuser/app/bin/webrickd.rb -d -p 
/home/rtuser/app/data/logs/webrickd.pid (code=exited, status=0/SUCCESS)


Then this, anywhere from 1 to 3 minutes later...

webrickd.service - Configuration ruby webrick daemon
  Loaded: loaded (/etc/systemd/system/webrickd.service)
  Active: active (running) since Tue, 01 Jan 2013 22:47:40 
-0700; 15s ago
 Process: 15807 ExecStart=/home/rtuser/app/bin/webrickd.rb -d -p 
/home/rtuser/app/data/logs/webrickd.pid (code=exited, status=0/SUCCESS)



And initial state (i.e. after it is started)?

  
Any ideas why it sits in state "deactivating (final-sigterm)" for 1 to 3 
minutes
It gets better.  I took a very stripped simple daemon to try to 
understand the interaction between systemd and the process.  Here it is:

***
#!/bin/env 
/usr/bin/ruby


require "webrick"

class SomeServlet < WEBrick::HTTPServlet::AbstractServlet
 def do_GET (request, response)
   response.status=200
   response.body="Howdy"
 end
end

class SomeServer < WEBrick::HTTPServer
 def initialize
   super(:Port => 1234, :DocumentRoot => ".")
   mount "/", SomeServlet
   ['TERM'].each { |signal| trap(signal) { shutdown } 
}   


   start
 end
end

WEBrick::Daemon.start
s = SomeServer.new
***


Here's the service file:
***
[Unit]
Description=Webrick Test Service
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/ruby /home/rtuser/test.rb

[Install]
WantedBy=multi-user.target
***

I put this in /etc/systemd/system/webrickd.service
Then ran systemctl enable webrickd.service
Then ran systemctl --system daemon-reload
Then ran systemctl start webrickd.service

Running it from the command line runs as it should.  Web server starts 
and test.rb is running in the background as a daemon returning me back 
to the shell.


But as soon as I try to use systemd, it starts but as soon as the 
WEBrick::Daemon.start call is made, everything is killed.
Nothing happens after that.  I've tried using the "simple" service 
type.  I've tried trapping different signals, I've tried starting it up 
different ways (e.g. just /home/rtuser/test.rb instead of call to ruby 
first.)  I've tried just starting the server and not calling 
WEBrick.Daemonize then systemd reports all kinds of errors and 
failures.  I've tried all kinds of things.  I opened a log file both 
before and after the WEBrick::Daemon.start call to see what was and was 
not getting executed.  Before call to WEBrick::Daemon.start everything 
works, afterward everything is dead but the systemctl command exits quickly.


systemctl status shows:
webrickd.service - Webrick Test Service
 Loaded: loaded (/etc/systemd/system/webrickd.service)
 Active: inactive (dead) since Wed, 02 Jan 2013 01:23:01 -0700; 
9min ago
Process: 1605 ExecStart=/usr/bin/ruby /home/rtuser/test.rb 
(code=exited, status=0/SUCCESS)

   Main PID: 1607 (code=exited, status=0/SUCCESS)
 CGroup: name=systemd:/system/webrickd.service

I'm really trying to understand systemd but it is times like this when 
do long for the simpler days of init.  At this point I would *gladly* 
trade a longer boot time for all the headache this has given me.  I had 
a working init script that has run great for years but quit working with 
systemd so I tried the systemd way and just can't make this stupid thing 
work.  It either takes forever or it flat out fails.


If someone could tell me the "right way" to make this work with systemd, 
I would love to use it but I've been at this on and off for weeks and it 
isn't getting any easier.  From my perspective systemd appears rigid and 
quite unforgiving.  I can't call it buggy yet because I don't know that 
I'v