Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Tomasz Torcz]

On Tue, Jul 16, 2013 at 07:41:08PM +, "Jóhann B. Guðmundsson" wrote:
> On 07/16/2013 07:34 PM, Kay Sievers wrote:
> >On Tue, Jul 16, 2013 at 9:28 PM, "Jóhann B. Guðmundsson"
> > wrote:
> >>On 07/16/2013 06:26 PM, Lennart Poettering wrote:
> >>>I discussed this a bit more with Kay on the phone. Here's what we'd
> >>>propose:
> >>>
> >>>I'd be very conservative regarding adding full tmpfiles support into
> >>>unit files directly. Instead, I'd suggest adding two very minimal, very
> >>>specific new unit file settings:
> >>>
> >>>RuntimeDirectory=
> >>>RuntimeDirectoyMode=
> >>
> >>What exactly are we trying to solve here which should not be fixed upstream
> >>in the daemons themselves?
> >Stuff that uses User= cannot be fixed in the daemon itself, at the
> >time it runs, systemd itself has already taken away the privileges to
> >create these directories.
> 
> We increase unit complexity with each option we add so I would
> suggest unless it's absolutely necessary to just stick with just
> tmpfiles to handle this.

  I second Jóhann.  As a packager, I never had problems with separate
configuration of runtime dir. Additionally, runtime dirs hardly need
customizations by admin.  It's not worth exposing them in unit file.


-- 
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen

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

Re: [systemd-devel] Automount behavior

[Mickaël THOMAS]

Here are some details.

fstab line :
LABEL=Data/dataext4nofail,auto01

journalctl -b | grep Data :
Jul 17 04:24:21 mickael-laptop systemd[1]: Expecting device
dev-disk-by\x2dlabel-Data.device...
Jul 17 04:25:51 mickael-laptop systemd[1]: Job
dev-disk-by\x2dlabel-Data.device/start timed out.
Jul 17 04:25:51 mickael-laptop systemd[1]: Timed out waiting for
device dev-disk-by\x2dlabel-Data.device.
Jul 17 04:25:51 mickael-laptop systemd[1]: Dependency failed for
File System Check on /dev/disk/by-label/Data.

systemctl list-jobs (before timeout) :
JOB UNIT   TYPE  STATE
 11 data.mount start waiting
 12 systemd-fsck@dev-disk-by\x2dlabel-Data.service start waiting
 13 dev-disk-by\x2dlabel-Data.device   start running

When shutting down, the message "A start job is running for
dev-disk-by\x2dlabel-Data.device" shows up and I have to wait for the
timeout to end.

For now, a workaround I found is to change "auto" to "noauto" and
symlink dev-disk-by\\x2dlabel-Data.device.wants/data.mount to
/run/systemd/generator/data.mount
Disabling the file-system check also seems to fix the issue
(discovered that just now)

2013/7/17 Lennart Poettering :
> On Sun, 16.06.13 22:32, Mickaël THOMAS (micka...@gmail.com) wrote:
>
>>
>> I've also found another issue regarding this (it's a small issue but 
>> still...)
>>
>> Using "nofail" (and implied "auto") works as expected but if the
>> device is not there at boot time, systemd will try to mount it anyway
>> and fail after a certain timeout.
>> Problem is, if I happen to shutdown my machine before the timeout
>> ends, it will hang until the timeout has passed.
>> Ideally, I don't need systemd to try to mount the device if the disk
>> isn't there. Perhaps this could be the behavior when "nofail" option
>> is used.
>>
>> What's your thoughts about this?
>
> Oh, umm. So "nofail" is not supposed to cause delays at boot
> really. This really should just mount the fs if it is found during
> early-boot. If it isn't found it shouldn't get mounted or anything
> delayed for it.
>
> if this causes a delay for you then there's a bug somewhere.
>
> What's the precise fstab line you use now?
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Andrey Borzenkov]

В Tue, 16 Jul 2013 20:26:23 +0200
Lennart Poettering  пишет:

> On Tue, 16.07.13 18:53, Lennart Poettering (lenn...@poettering.net) wrote:
> 
> I'd be very conservative regarding adding full tmpfiles support into
> unit files directly. Instead, I'd suggest adding two very minimal, very
> specific new unit file settings:
> 
> RuntimeDirectory=
> RuntimeDirectoyMode=
> 
> If RuntimeDirectory= is set we'd create it and chown() it to the UID/GID
> set with User= and Group=. We'd apply the mode specified in
> RuntimeDirectoryMode= to it.
> 
> We'd even allow multiple runtime directories to be specified.
>

What if different directories need different modes? I'm afraid it will
become hard to express in unit file.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv2] systemctl, man: option to list units by state

[Lennart Poettering]

On Fri, 17.05.13 12:09, m.were...@partner.samsung.com 
(m.were...@partner.samsung.com) wrote:

> From: Maciej Wereski 
> 
> This allows to show only units with specified SUB or ACTIVE state.

Sounds like a worthwile addition. Sorry for the way too late review. But
in cse you are still interested:

We already support filtering for load states via --type= which is
overloaded for both load states and unit types. I think it would
probably be nicer to have --type= as you suggest, and then overload it
with load state, active state, and sub state. These three namespaces are
closer to each other so that we can avoid clashes easier.

> +static const char *arg_state = NULL;
> +static const char *const failed_str = "failed";

You can just use "failed" insted of failed_str where you need it, no
need to define this.

>  static enum action {
>  ACTION_INVALID,
>  ACTION_SYSTEMCTL,
> @@ -300,8 +301,8 @@ static int compare_unit_info(const void *a, const void 
> *b) {
>  static bool output_show_unit(const struct unit_info *u) {
>  const char *dot;
>  
> -if (arg_failed)
> -return streq(u->active_state, "failed");
> +if (arg_state != NULL)
> +return (streq(u->sub_state, arg_state) ||
> -streq(u->active_state, arg_state));

No need for the surrounding parenthesis.

>  
>  return (!arg_types || ((dot = strrchr(u->id, '.')) &&
> strv_find(arg_types, dot+1))) &&
> @@ -4503,7 +4504,7 @@ static int systemctl_help(void) {
> "  ones. To list all units installed on 
> the system, use\n"
> "  the 'list-unit-files' command 
> instead.\n"
> " --reverseShow reverse dependencies with 
> 'list-dependencies'\n"
> -   " --failed Show only failed units\n"
> +   " --failed Show only failed units (the same as 
> --state=failed)\n"
> " --full   Don't ellipsize unit names on output\n"
> " --fail   When queueing a new job, fail if 
> conflicting jobs are\n"
> "  pending\n"
> @@ -4536,7 +4537,8 @@ static int systemctl_help(void) {
> " --runtimeEnable unit files only temporarily 
> until next reboot\n"
> "  -n --lines=INTEGER  Journal entries to show\n"
> "  -o --output=STRING  Change journal output mode (short, 
> short-monotonic,\n"
> -   "  verbose, export, json, json-pretty, 
> json-sse, cat)\n\n"
> +   "  verbose, export, json, json-pretty, 
> json-sse, cat)\n"
> +   " --state=STATEShow only units with particular
> sub or active state\n\n"

Please move this up to the other filter switches like --type=.

I'd really like to see support for passing multiple states at once, the
same way as we support filtering for multiple types at once.

Lennart

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

Re: [systemd-devel] Systemd debugging option, documentation clarification

[Lennart Poettering]

On Thu, 06.06.13 18:54, Andrey Borzenkov (arvidj...@gmail.com) wrote:

> > On Wed, 15.05.13 22:28, John Connor (jaconno...@gmail.com) wrote:
> > 
> > > 1: It would be useful for debugging if systemctl had an option to show
> > > output on the screen (especially output from scripts run under
> > > systemd), rather than dumping it in a journal which you then have to
> > > search through.  This should be a command-line option, because you
> > > would normally use it only for debugging, not for a normal boot. I
> > > don't know how practicable this would be, but it would be useful.
> > 
> > This is actually harder than it sounds, since notification when a job
> > finished is asynchronous to the stream of logs, and I have no idea how
> > we could ever fix that.
> 
> By default systemctl is blocking - it waits until job is completed,
> right? So it could fetch logs for this job after completion, similar to
> "systemctl status"? What does it involve beyond sticking
> show_journal_by_unit() in the right place?

There's no guarantee that journald has written the logs to disk when
systemctl would check them there. systemctl blocks until the PID 1 told
it that the execution job is done, but there's no way how journald could
communicate that everything queued from that service has been read and
written to disk, so that systemctl could find it there.

It's really hard to get right. No idea how to make this work.

Lennart

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

Re: [systemd-devel] systemd-shutdown static linking (was: Please proof-read: ...)

[Lennart Poettering]

On Tue, 11.06.13 10:07, Umut Tezduyar (u...@tezduyar.com) wrote:

> Hi,
> 
> Those 2 lines were added on 89b1d5e0e49d3b3501e5f3aadcad712290bcd9bf and
> the commit log explains why we needed them. "/" can be treated as special
> case and excluded.

Just for completeness' sake. This was implemented in
602c0e740f8290cc9c4f13f2eb4b23fbbd7a8d2b a while back.

Lennart

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

Re: [systemd-devel] [PATCH] service: don't try to kill the service more than once when the watchdog timeout hits

[Lennart Poettering]

On Wed, 12.06.13 01:22, Michael Olbrich (m.olbr...@pengutronix.de) wrote:

> If ExecStopPost= is defined then it is executed after SIGKILL. Otherwise
> another round of SIGTERM/SIGSTOP is started which is rather useless when
> the watchdog timeout hits.
> So go directly to the final SIGKILL if ExecStopPost= is not defined.

Hmm, why not go always directly into SERVICE_FINAL_SIGKILL? Why bother
with SERVICE_STOP_SIGKILL at all? What am I missing?

> ---
> 
> Hi,
> 
> I did some more testing with this. I think this is better. Running
> ExecStopPost= if available is a good idea, but don't waste any time
> otherwise.
> 
> Michael
> 
>  src/core/service.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/core/service.c b/src/core/service.c
> index dadd981..984993f 100644
> --- a/src/core/service.c
> +++ b/src/core/service.c
> @@ -249,7 +249,10 @@ static void service_handle_watchdog(Service *s) {
>  offset = now(CLOCK_MONOTONIC) - s->watchdog_timestamp.monotonic;
>  if (offset >= s->watchdog_usec) {
>  log_error_unit(UNIT(s)->id, "%s watchdog timeout!", 
> UNIT(s)->id);
> -service_enter_signal(s, SERVICE_STOP_SIGKILL, 
> SERVICE_FAILURE_WATCHDOG);
> +if (s->exec_command[SERVICE_EXEC_STOP_POST])
> +service_enter_signal(s, SERVICE_STOP_SIGKILL, 
> SERVICE_FAILURE_WATCHDOG);
> +else
> +service_enter_signal(s, SERVICE_FINAL_SIGKILL, 
> SERVICE_FAILURE_WATCHDOG);
>  return;
>  }
>  


Lennart

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

Re: [systemd-devel] Debugging Plugable Multiseat

[Lennart Poettering]

On Tue, 11.06.13 17:44, Billy Crook (bcr...@riskanalytics.com) wrote:

> I have a few Plugable multiseat consoles on Fedora 18.  They mostly
> work, but it seems after a day of use and logging out, the gdm greeter
> never returns.  Instead the monitor DPMS off and the  Plugable
> consoles have to be power cycled to get the greeter to return.
> 
> While the consoles are in this 'nuked' state, udevadm monitor shows
> the following hardware removal and addition once every five minutes.

Hmm, such remove/add events really should only appear if the USB devices
got unplugged and then replugged... Smells like a hw problem.

Do you see anything interesting in dmesg when this happens?

Lennart

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

Re: [systemd-devel] start/stop messages when activating a target?

[Lennart Poettering]

On Wed, 12.06.13 01:32, Michael Olbrich (m.olbr...@pengutronix.de) wrote:

> Hi,
> 
> When booting or during shutdown systemd prints the start stop messages for
> the services. Is it possible to get those messages when activating a target
> with systemctl?

The boot-time output is done by PID 1 itself and directly to the system
console, and we turn it off as soon as the machine is up (and as long as
it stays up) in order to not interfere with any output of whatevr is
running on the console after bootup.

Now, I figoure what you actually want is some output of systemctl
(i.e. not PID1) and directly to the tty that you ran it from? 

We could certainly add that, and it has been requested before. It's a
change with implications however, given that people who are already
using things now in scripts expect that no output is generated and might
be annyoed if it now is.

That said, I am not against changing systemctl to actually inform the
user what is going on even if the operation it executed was
successful. The least to make sure though would be that the output is
suppressed if --quiet is used.

Lennart

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

Re: [systemd-devel] Automount behavior

[Lennart Poettering]

On Sun, 16.06.13 22:32, Mickaël THOMAS (micka...@gmail.com) wrote:

> 
> I've also found another issue regarding this (it's a small issue but still...)
> 
> Using "nofail" (and implied "auto") works as expected but if the
> device is not there at boot time, systemd will try to mount it anyway
> and fail after a certain timeout.
> Problem is, if I happen to shutdown my machine before the timeout
> ends, it will hang until the timeout has passed.
> Ideally, I don't need systemd to try to mount the device if the disk
> isn't there. Perhaps this could be the behavior when "nofail" option
> is used.
> 
> What's your thoughts about this?

Oh, umm. So "nofail" is not supposed to cause delays at boot
really. This really should just mount the fs if it is found during
early-boot. If it isn't found it shouldn't get mounted or anything
delayed for it.

if this causes a delay for you then there's a bug somewhere.

What's the precise fstab line you use now?

Lennart

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

Re: [systemd-devel] systemd waiting for already existing devices

[Lennart Poettering]

On Mon, 17.06.13 20:12, Alexander Koch (lyni...@gmail.com) wrote:

> > Bootup is not yet finished. Please try again later.
> 
> > [alex@thor ~]$ systemctl list-jobs
> > JOB UNITTYPE  STATE  
> >  41 dev-mapper-archive4\x2dplain.device start running
> >  47 dev-mapper-archive2\x2dplain.device start running
> >  50 dev-mapper-archive1\x2dplain.device start running
> 
> The number of the device that gets recognized changes randomly on each
> bootup, so I see no dependency on a specific one.
> 
> 
> If I were to guess, then I'd say systemd does not recognize the other
> three volumes being created because they all have the same (primary)
> UUID as the first one, and therefore there is no additional notification
> from the kernel, blockdevice subsystem or wherever systemd gets its
> notifications from.
> 
> 
> Any comments or recommendations on this? It's no big trouble to me,
> because the volume is mounted correctly, but I'm not able to use
> systemd-analyze like this ;)

Hmm this looks like a bug in the btrfs raid assembly logic in
systemd. So what happens when a multi-volume btrfs fs is to be mounted
is that udev will immediately inform the btrfs kernel logic that a new
device appeared as it appears. As soon as btrfs then tells udev that all
devices have been found, then udev will mark that device as ready, which
systemd then takes as hint to mount the thing.

I have a very similar setup of btrfs raid on top of two LUKS disks, I
should be able to reprodeuce this. I added this to the TODO list now.

Lennart

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

Re: [systemd-devel] [PATCH] core: notify triggered by socket of a service

[Lennart Poettering]

On Fri, 12.07.13 09:19, Umut Tezduyar (u...@tezduyar.com) wrote:

> >> +if ((se->state == SERVICE_DEAD ||
> >> +se->state == SERVICE_STOP ||
> >> +se->state == SERVICE_STOP_SIGTERM ||
> >> +se->state == SERVICE_STOP_SIGKILL ||
> >> +se->state == SERVICE_STOP_POST ||
> >> +se->state == SERVICE_FINAL_SIGTERM ||
> >> +se->state == SERVICE_FINAL_SIGKILL ||
> >> +se->state == SERVICE_AUTO_RESTART) &&
> >> +se->socket_fd < 0)
> >> +socket_notify_service_dead(s, false);
> >> +
> >> +if (se->state == SERVICE_RUNNING)
> >> +socket_set_state(s, SOCKET_RUNNING);
> > This doesn't work for socket activated/instantiated services. I should
> > be able to detect if a service is instantiated..
> 
> Lennart, do you have a solution for this that I can take in and
> re-send the patch?  It works great for socket activated services that
> when service is running, the triggered by socket is set to running too
> but it is not working for instantiated services. For instantiated
> services, socket needs to stay in "listening" stay all the time.

I am not really grokking the problem, but I figure the entire trigger
callback should be skipped (with an early return) if s->accept is
set. Are you looking for something else?

Lennart

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

Re: [systemd-devel] Compile errors with -Og

[Lennart Poettering]

On Wed, 12.06.13 13:02, Jan Janssen (medhe...@web.de) wrote:

> Hi,
> 
> I just tried compiling with -Og and I get these compiler errors.
> Those don't appear with any other optimization level, so I'm
> suspecting a compiler but here. But since I'm no C expert, I thought
> it would be best if I share this here to see if I'm right about this
> or whether this just shows some subtle bug in the code.
> 
> This is on a up-to-date arch box (gcc 4.8.1) and "make clean"
> run before trying to compile.
> 
> Jan
> 
> ---
>   CC   src/shared/util.lo
> src/shared/util.c: In function 'safe_atod':
> src/shared/util.c:383:16: warning: 'd' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>  *ret_d = (double) d;

Seems your gcc is confused by our RUN_WITH_LOCALE() magic macro, because
it contains a for() loop that it thinks might not be run, but actually
always is.

I added an initialization that should make sure the warning goes away.

> ^
> In file included from /usr/include/fcntl.h:296:0,
>  from src/shared/util.c:35:
> In function 'open',
> inlined from 'open_terminal' at src/shared/util.c:1834:20:
> /usr/include/bits/fcntl2.h:50:24: error: call to
> '__open_missing_mode' declared with attribute error: open with
> O_CREAT in second argument needs 3 arguments
> __open_missing_mode ();

Hmm, gcc is confused if we invoke open() with no mode argument but flags
seeded from a variable. Added a work-around for this.

> In file included from /usr/include/fcntl.h:296:0,
>  from src/shared/util.c:35:
> In function 'openat',
> inlined from 'xopendirat' at src/shared/util.c:3478:13:
> /usr/include/bits/fcntl2.h:126:26: error: call to
> '__openat_missing_mode' declared with attribute error: openat with
> O_CREAT in third argument needs 4 arguments
> __openat_missing_mode ();

Same here.
>   ^
> src/shared/util.c: In function 'create_tmp_dir':
> src/shared/util.c:5718:12: warning: 'd' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>  dt = strjoin(d, "/tmp", NULL);

Your gcc also doesn't like our RUN_WITH_UMASK macro either, also fixed.

Lennart

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

Re: [systemd-devel] [HEADSUP] cgroup changes

[Lennart Poettering]

On Tue, 25.06.13 08:31, Brian Bockelman (bbock...@cse.unl.edu) wrote:

> 
> On Jun 25, 2013, at 4:56 AM, Lennart Poettering  
> wrote:
> 
> > On Tue, 25.06.13 02:21, Brian Bockelman (bbock...@cse.unl.edu) wrote:
> > 
> >> A few questions came to mind which may provide interesting input 
> >> to your design process:
> >> 1) I use cgroups heavily for resource accounting.  Do you envision 
> >>  me querying via dbus for each accounting attribute?  Or do you 
> >>  envision me querying for the cgroup name, then accessing the 
> >> controller statistics directly?
> > 
> > Good question. Tejun wants systemd to cover that too. I am not entirely
> > sure. I don't like the extra roundtrip for measuring the accounting
> > bits. But maybe we can add a library that avoids the roundtrip, and
> > simply provides you with high-level accounting values for cgroups. That
> > way, for *changing* things you'd need to go via the bus, for *reading*
> > things we'd give you a library that goes directly to the cgroupfs and
> > avoids the roundtrip.
> 
> I like this idea.  Hopefully single-writer, multiple-reader is more 
> sustainable path forward.
> 
> What about the notification APIs?  We currently use the
> memory.oom_control to get a notification when a job hits limits (this
> allows us to know the job died due to memory issues, as the user code
> itself typically just SIGSEGV's).  Is subscribing to notifications
> considered reading or writing in this case?

That sounds like another case for the library, i.e. is more considered
reading. That said I think the current notification infrastructure of
cgroup attributes is really really awful, so I am not to keen to support
that right-away.

Lennart

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

Re: [systemd-devel] [PATCH] [RFC] systemctl-clock: Use monotonic instead of realtime clock

[Lennart Poettering]

On Tue, 25.06.13 18:58, Shakeel, Muhammad (muhammad_shak...@mentor.com) wrote:

> From: Muhammad Shakeel 
> 
> Currently if system clock is updated then 'ago' part of any service
> running time doesn't show correct information. This is reported here:
> https://bugs.freedesktop.org/show_bug.cgi?id=65616

Looks good in principle, but I am not really happy about changing the
clock format_timestamp_relative() works on without indicating that in
any way in the name of that function. 

Maybe rename format_timestamp() to format_timestamp_realtime() and
format_timestamp_relative() to format_timestamp_monotonic()? I think
that would be a lot more descriptive?

Lennart

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

[systemd-devel] hwdb for sane

[Tom Gundersen]

Hi guys,

I had a stab at converting sane to using hwdb rather than a huge udev
rules file.

For now only the usb entries have been converted, I didn't look at how
to deal with scsi.

hwdb file: 
udev rules: 
patch1: 

patch2: 


Any comments welcome (especially as I don't have the hardware to do
any testing...).

Cheers,

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Michael Biebl]

And to follow up on that:

2013/7/16 Michael Biebl :
> I think it's even less of an issue for Debian, as we usually only
> install stuff when needed and not in a disabled state.

So the unused directories in /run are something I don't expect to be
an issue for Debian.

As for tmpfiles support:
In Debian we already have pretty nice support and debhelper
(dh_installinit) scans the installed files and creates postinst
snippet like

if [ -d /run/systemd/system ] ; then
   systemd-tmpfiles --create /usr/lib/tmpfiles.d/xconsole.conf
>/dev/null || true
fi

which is run before the daemon is started.

So, also not an issue for Debian.

That leaves the only point: the configuration is split between two
files. Tbh, I'm not too thrilled duplicating part of the tmpfiles
functionality in .service files itself.
What we could do though, similar to Documentation, reference a tmpfile
which belongs to the service.
So when you run systemctl status foo.service, it would show the
corresponding file.

This would it more discoverable for the admin and he'd see which file to modify.

Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv3 2/2] logind: apply ACL's to "dead" device nodes

[Tom Gundersen]

On Tue, Jul 16, 2013 at 8:39 PM, Lennart Poettering
 wrote:
> On Tue, 16.07.13 19:38, Tom Gundersen (t...@jklm.no) wrote:
>
>> -udev_enumerate_unref(e);
>> +/* udev exports "dead" device nodes to allow module on-demand 
>> loading,
>> + * these devices are not known to the kernel at this moment */
>> +dir = opendir("/run/udev/static_node-tags/uaccess");
>> +if (dir) {
>> +for (dent = readdir(dir); dent != NULL; dent =
>> readdir(dir)) {
>
> Please use FOREACH_DIRENT here!
>
>> +_cleanup_free_ char *unescaped_devname = NULL;
>>
>> +if (dent->d_name[0] == '.')
>> +continue;
>
> This is unnecessary if you use FOREACH_DIRENT.
>
>> +
>> +unescaped_devname = cunescape(dent->d_name);
>> +if (unescaped_devname == NULL) {
>> +r = -ENOMEM;
>> +closedir(dir);
>
> Looks like you want to use _cleanup_closedir_ for this?

Thanks for the suggestions. Will push fix after testing.

>> +goto finish;
>> +}
>> +
>> +n = strappend("/dev/", unescaped_devname);
>
> Good candidate for strappenda?

Except for this one.

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Michael Biebl]

2013/7/16 Zbigniew Jędrzejewski-Szmek :
> On Tue, Jul 16, 2013 at 05:08:12PM +0100, Colin Guthrie wrote:

>> I am not too concerned about unused runtime directories. After all this
>> is not something that would (or even could) grow without bounds. There
>> will never be more than O(n) runtime directores for n being the number
>> of packages you have installed (or had installed).
> Sure, but this n can be around a couple hundred I'd image when debian
> is fully converted and installed. For efficiency this is probably
> unmesurable, but as an admin I'd prefer not to have hundreds of empty
> dirs in /run.

That seems to be misconception: Even when all 1200+ packages currently
shipping SysV init scripts, have native systemd support, this doesn't
mean that all those 1200 packages are actually installed.
I think it's even less of an issue for Debian, as we usually only
install stuff when needed and not in a disabled state.

I expect that a typical desktop installation has around 30 system
services, and I'm pretty sure it's rather uncommon to have more then 5
disabled system services.



--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv3 2/2] logind: apply ACL's to "dead" device nodes

[Lennart Poettering]

On Tue, 16.07.13 20:39, Lennart Poettering (lenn...@poettering.net) wrote:

> > +goto finish;
> > +}
> > +
> > +n = strappend("/dev/", unescaped_devname);
> 
> Good candidate for strappenda?

I take this back. Awful candidate for strappenda() since this is inside
a loop, and you cannot sanely use alloca() in a loop, since it keeps
appending to the stack.

So, please keep using strappend() for this one.

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Jóhann B. Guðmundsson]

On 07/16/2013 07:34 PM, Kay Sievers wrote:

On Tue, Jul 16, 2013 at 9:28 PM, "Jóhann B. Guðmundsson"
 wrote:

On 07/16/2013 06:26 PM, Lennart Poettering wrote:

I discussed this a bit more with Kay on the phone. Here's what we'd
propose:

I'd be very conservative regarding adding full tmpfiles support into
unit files directly. Instead, I'd suggest adding two very minimal, very
specific new unit file settings:

RuntimeDirectory=
RuntimeDirectoyMode=


What exactly are we trying to solve here which should not be fixed upstream
in the daemons themselves?

Stuff that uses User= cannot be fixed in the daemon itself, at the
time it runs, systemd itself has already taken away the privileges to
create these directories.


We increase unit complexity with each option we add so I would suggest 
unless it's absolutely necessary to just stick with just tmpfiles to 
handle this.


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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Kay Sievers]

On Tue, Jul 16, 2013 at 9:28 PM, "Jóhann B. Guðmundsson"
 wrote:
> On 07/16/2013 06:26 PM, Lennart Poettering wrote:
>>
>> I discussed this a bit more with Kay on the phone. Here's what we'd
>> propose:
>>
>> I'd be very conservative regarding adding full tmpfiles support into
>> unit files directly. Instead, I'd suggest adding two very minimal, very
>> specific new unit file settings:
>>
>> RuntimeDirectory=
>> RuntimeDirectoyMode=
>
>
> What exactly are we trying to solve here which should not be fixed upstream
> in the daemons themselves?

Stuff that uses User= cannot be fixed in the daemon itself, at the
time it runs, systemd itself has already taken away the privileges to
create these directories.

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 16, 2013 at 07:28:12PM +, "Jóhann B. Guðmundsson" wrote:
> On 07/16/2013 06:26 PM, Lennart Poettering wrote:
> >I discussed this a bit more with Kay on the phone. Here's what we'd propose:
> >
> >I'd be very conservative regarding adding full tmpfiles support into
> >unit files directly. Instead, I'd suggest adding two very minimal, very
> >specific new unit file settings:
> >
> >RuntimeDirectory=
> >RuntimeDirectoyMode=
> 
> What exactly are we trying to solve here which should not be fixed
> upstream in the daemons themselves?
It was written in the part you removed:

Putting this all together we'd recommend:
a) in the best case make your daemon create all runtime dirs as
   necessary
b) if that's not possible (for example, due to privs), then use
   RuntimeDirectory= instead.
...

Zbyszek
-- 
they are not broken. they are refucktored
   -- alxchk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Jóhann B. Guðmundsson]

On 07/16/2013 06:26 PM, Lennart Poettering wrote:

I discussed this a bit more with Kay on the phone. Here's what we'd propose:

I'd be very conservative regarding adding full tmpfiles support into
unit files directly. Instead, I'd suggest adding two very minimal, very
specific new unit file settings:

RuntimeDirectory=
RuntimeDirectoyMode=


What exactly are we trying to solve here which should not be fixed 
upstream in the daemons themselves?


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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Kay Sievers]

On Tue, Jul 16, 2013 at 9:17 PM, Tomasz Torcz  wrote:

>> If RuntimeDirectory= is set we'd create it and chown() it to the UID/GID
>> set with User= and Group=. We'd apply the mode specified in
>> RuntimeDirectoryMode= to it.
>
>   There are daemons which do, in order:
> 1) start as root
> 2) open some root-only resources, like network sockets
> 3) change to less priviledge user
> 4) if all OK, write PID file or some state in /run
> 5) do the work
>
>   Those daemons can't have User= specified, because 2) would fail.
> And because they must start as root, systemd can't know what
> chown() to do on runtime dir.
>
>   So what's the solution?
> a) declare those daemons incompatible with RuntimeDirectory* stuff
>- nothing changes, they continue to use separate tmpfile .conf
> b) fix the daemons?

B, sure, when it's private to the daemon and it run as root, it should
prepare its own environment itslef. It's just weird to assume someone
else does that for the daemon.

And it's just slightly less broken to use a tmpfiles to work around
such a broken daemon init. :)

Stuff is different though if the directory is some kind of an API,
then tmpfiles are sure fine, and creating them at boot is the right
thing.

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Tomasz Torcz]

On Tue, Jul 16, 2013 at 08:26:23PM +0200, Lennart Poettering wrote:
> On Tue, 16.07.13 18:53, Lennart Poettering (lenn...@poettering.net) wrote:
> 
> > > > I can do a mass update to all our packages anyway so the slight change
> > > > in syntax isn't a problem.
> > > Hm, can we take a step back for a moment? It seems that the rpm macros
> > > are a fairly complicated solution, and they also don't carry over into
> > > debian or arch. User mode sessions also will not work with rpm macros.
> > 
> > Well, it's easy to come up with similar macros for debhelper or arch...
> > 
> > User session don't really need this, as there as user daemons usually
> > create the dirs they need on their own and there are no privileges
> > involved which might forbid this.
> > 
> > I have commite the RPM macro fro now, since either way we will need it
> > for the packages where the dirs need to exist all the time.
> 
> I discussed this a bit more with Kay on the phone. Here's what we'd propose:
> 
> I'd be very conservative regarding adding full tmpfiles support into
> unit files directly. Instead, I'd suggest adding two very minimal, very
> specific new unit file settings:
> 
> RuntimeDirectory=
> RuntimeDirectoyMode=
> 
> If RuntimeDirectory= is set we'd create it and chown() it to the UID/GID
> set with User= and Group=. We'd apply the mode specified in
> RuntimeDirectoryMode= to it.

  There are daemons which do, in order:
1) start as root
2) open some root-only resources, like network sockets
3) change to less priviledge user
4) if all OK, write PID file or some state in /run
5) do the work

  Those daemons can't have User= specified, because 2) would fail.
And because they must start as root, systemd can't know what
chown() to do on runtime dir.

  So what's the solution?
a) declare those daemons incompatible with RuntimeDirectory* stuff
   - nothing changes, they continue to use separate tmpfile .conf
b) fix the daemons?

-- 
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzich...@chrome.pl "God is more forgiving."

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

Re: [systemd-devel] Patch for Smack labelling support in udev

[Kay Sievers]

On Tue, Jul 9, 2013 at 4:34 PM, Reshetova, Elena
 wrote:
>> -static int node_permissions_apply(struct udev_device *dev, bool
>> apply, mode_t mode, uid_t uid, gid_t gid)
>> +static int node_permissions_apply(struct udev_device *dev, bool apply,
>> mode_t mode,
>> +  uid_t uid, gid_t gid, struct
>> +udev_list xattr_list)
>
>>Guess we better pass the udev_list as a const pointer here.
>
> Ups, sorry, missed this one, of course it won't even work this way (I haven't
> tried to run it yet ...

It looks like it could work, but please test it and make sure it does
the right thing before we go ahead from here.

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Lennart Poettering]

On Tue, 16.07.13 17:59, Colin Guthrie (co...@mageia.org) wrote:

> 
> 'Twas brillig, and Kay Sievers at 16/07/13 17:24 did gyre and gimble:
> > On Tue, Jul 16, 2013 at 6:01 PM, Lennart Poettering
> >  wrote:
> > 
> >> Hmm, I'd like such an automatism, but I'd really prefer if we could come
> >> up with some scheme to automatically determine all tmpfiles snippets in
> >> the package and apply them all automatically. But I am not sure how that
> >> could be done with current RPM.
> >>
> >> In fact, I'd actually like to do the same for the %systemd_post macros,
> >> and suchlike, where people tend to be pretty bad at always listing all
> >> unit files correctly.
> 
> Actually rereading this bit above, I can see the desire for automated
> snippets, but are there not some cases where you would want to avoid
> calling %systemd_post macros for some shipped units? e.g. they may only
> be used internally by others (Requires=, Also= and similar). I think
> such automation might not be good. (just look at the NFS units which I
> think we've finally cleaned up a bit in Mageia - enough to actually work
> at least).

No. You really want the macros for all units, always. 

The macros use the preset information to enable units if that's
what the vendor or admin wants. This preset information should be what
decides what is enabled and what is not, not the packager who accidently
forgot to invoke "systemctl preset" on one of his units.

The unit names also matter to shutdown running units before uninstalling
them. For that too you really need the list of all units the package
installs and not just the ones the package might have though about
listing.

So yeah, we want that the scritps process *all* units the package
installs, not just some subset. Only that guarantees correct behaviour
regarding presets and regarding stopping things when we uninstall.

Of coruse, this is not obvious to people, which is why many packages
don't get this right. With the automatic logic we'd avoid this confusion.

> 
> > Hmm, an rpmlint check for stuff like this maybe is the first step? At
> > least people who care and look at that would fix their stuff?
> 
> Misc was looking at doing most of that. Not sure what you mean about
> naming tho'... do you just mean the folder name (etc vs usr) or just not
> picking very nice unit names?

The rpmlint should just check that all units a package ships are listed
as arguments for the RPM macro.

> For the folder, I put rpmlint checks in Mageia a while ago to ban units,
> tmpfiles and udev rules from shipping in /etc.

That's a very good choice.

> And another to do with non-ghost files in /run or /var/run.

Also a good choice!

Lennart

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

Re: [systemd-devel] [PATCHv3 2/2] logind: apply ACL's to "dead" device nodes

[Lennart Poettering]

On Tue, 16.07.13 19:38, Tom Gundersen (t...@jklm.no) wrote:

> -udev_enumerate_unref(e);
> +/* udev exports "dead" device nodes to allow module on-demand 
> loading,
> + * these devices are not known to the kernel at this moment */
> +dir = opendir("/run/udev/static_node-tags/uaccess");
> +if (dir) {
> +for (dent = readdir(dir); dent != NULL; dent =
> readdir(dir)) {

Please use FOREACH_DIRENT here!

> +_cleanup_free_ char *unescaped_devname = NULL;
>  
> +if (dent->d_name[0] == '.')
> +continue;

This is unnecessary if you use FOREACH_DIRENT.

> +
> +unescaped_devname = cunescape(dent->d_name);
> +if (unescaped_devname == NULL) {
> +r = -ENOMEM;
> +closedir(dir);

Looks like you want to use _cleanup_closedir_ for this?

> +goto finish;
> +}
> +
> +n = strappend("/dev/", unescaped_devname);

Good candidate for strappenda?

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Lennart Poettering]

On Tue, 16.07.13 18:53, Lennart Poettering (lenn...@poettering.net) wrote:

> > > I can do a mass update to all our packages anyway so the slight change
> > > in syntax isn't a problem.
> > Hm, can we take a step back for a moment? It seems that the rpm macros
> > are a fairly complicated solution, and they also don't carry over into
> > debian or arch. User mode sessions also will not work with rpm macros.
> 
> Well, it's easy to come up with similar macros for debhelper or arch...
> 
> User session don't really need this, as there as user daemons usually
> create the dirs they need on their own and there are no privileges
> involved which might forbid this.
> 
> I have commite the RPM macro fro now, since either way we will need it
> for the packages where the dirs need to exist all the time.

I discussed this a bit more with Kay on the phone. Here's what we'd propose:

I'd be very conservative regarding adding full tmpfiles support into
unit files directly. Instead, I'd suggest adding two very minimal, very
specific new unit file settings:

RuntimeDirectory=
RuntimeDirectoyMode=

If RuntimeDirectory= is set we'd create it and chown() it to the UID/GID
set with User= and Group=. We'd apply the mode specified in
RuntimeDirectoryMode= to it.

We'd even allow multiple runtime directories to be specified.

I want this to be specific to the purpose of running daemons so I would
even go es far as generating a parse error if the specified directory is
not within /run. We wouldn't do any of the fancier things that tmpfiles
does, because we want people to use tmpfiles for that. For example, if
automatic clean-up needs to take place this information needs to be in
tmpfiles, not in a service unit.

We would hook this up with the same logic that currently handles
PrivateTmp= and remove the the runtime directory when the service goes
down.

With this in place we could probably cover 60% of the current users of
tmpfiles or so.

Putting this all together we'd recommend:

a) in the best case make your daemon create all runtime dirs as
   necessary

b) if that's not possible (for example, due to rpivs), then use
   RuntimeDirectory= instead.

c) If that's not enough (for example, because you need your dirs around
   even if the daemon is not running) , then drop in a tmpfiles snippet
   instead, and hook it in via the new RPM macro (or counterparts for
   non-RPM distributions) so that it is executed at package
   installation time 

More specific to Fedora, there's still the question  whether these dirs
in /run should be tracked by RPM or not. For this I think I am leaning towards:

d) List the runtime dirs you have in the RPM spec file, but %ghost
   them. This is nice so that the directory can be easily traced back to
   the package that created them.

Opinions? Suggestions?

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Jóhann B. Guðmundsson]

On 07/16/2013 04:53 PM, Lennart Poettering wrote:

On my (pretty much fully converted) Fedora I currently have 20 tmpfiles
snippets around. I doubt on an everage Debian machine this would grow
much larger. May 40 or so, but that's still not much.



Well we have only migrated what 400 components out of ca 550 Debian has 
twice that much ( around 1100 - 1200 I think ) but yes that number seems 
to fairly accurate which means it might actually be better pay off to 
simple fix those 20 daemons that require the tmpfiles in the first place.


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

[systemd-devel] [PATCHv3 2/2] logind: apply ACL's to "dead" device nodes

[Tom Gundersen]

Based on a patch by Kay Sievers.

When a dead device nodes is tagged with "uaccess" using the static_node 
mechanism,
it's ACL's are managed by logind in the same way as "live" device nodes.

This allows in particular /dev/snd/{seq,timer} to cause modules to be loaded
on-demand when accessed by a non-privileged user.
---

v3: no change

 src/login/logind-acl.c | 75 ++
 1 file changed, 64 insertions(+), 11 deletions(-)

diff --git a/src/login/logind-acl.c b/src/login/logind-acl.c
index cb045a9..c0ff509 100644
--- a/src/login/logind-acl.c
+++ b/src/login/logind-acl.c
@@ -28,6 +28,7 @@
 #include "logind-acl.h"
 #include "util.h"
 #include "acl-util.h"
+#include "set.h"
 
 static int flush_acl(acl_t acl) {
 acl_entry_t i;
@@ -179,23 +180,34 @@ int devnode_acl_all(struct udev *udev,
 
 struct udev_list_entry *item = NULL, *first = NULL;
 struct udev_enumerate *e;
+Set *nodes;
+Iterator i;
+char *n;
+DIR *dir;
+struct dirent *dent;
 int r;
 
 assert(udev);
 
-if (isempty(seat))
-seat = "seat0";
+nodes = set_new(string_hash_func, string_compare_func);
+if (!nodes) {
+return -ENOMEM;
+}
 
 e = udev_enumerate_new(udev);
-if (!e)
-return -ENOMEM;
+if (!e) {
+r = -ENOMEM;
+goto finish;
+}
+
+if (isempty(seat))
+seat = "seat0";
 
 /* We can only match by one tag in libudev. We choose
  * "uaccess" for that. If we could match for two tags here we
  * could add the seat name as second match tag, but this would
  * be hardly optimizable in libudev, and hence checking the
  * second tag manually in our loop is a good solution. */
-
 r = udev_enumerate_add_match_tag(e, "uaccess");
 if (r < 0)
 goto finish;
@@ -231,18 +243,59 @@ int devnode_acl_all(struct udev *udev,
 continue;
 }
 
-log_debug("Fixing up %s for seat %s...", node, sn);
-
-r = devnode_acl(node, flush, del, old_uid, add, new_uid);
+n = strdup(node);
 udev_device_unref(d);
+if (!n)
+goto finish;
 
+log_debug("Found udev node %s for seat %s", n, seat);
+r = set_put(nodes, n);
 if (r < 0)
 goto finish;
 }
 
-finish:
-if (e)
-udev_enumerate_unref(e);
+/* udev exports "dead" device nodes to allow module on-demand loading,
+ * these devices are not known to the kernel at this moment */
+dir = opendir("/run/udev/static_node-tags/uaccess");
+if (dir) {
+for (dent = readdir(dir); dent != NULL; dent = readdir(dir)) {
+_cleanup_free_ char *unescaped_devname = NULL;
 
+if (dent->d_name[0] == '.')
+continue;
+
+unescaped_devname = cunescape(dent->d_name);
+if (unescaped_devname == NULL) {
+r = -ENOMEM;
+closedir(dir);
+goto finish;
+}
+
+n = strappend("/dev/", unescaped_devname);
+if (!n) {
+r = -ENOMEM;
+closedir(dir);
+goto finish;
+}
+
+log_debug("Found static node %s for seat %s", n, seat);
+r = set_put(nodes, n);
+if (0 && r < 0 && r != -EEXIST) {
+closedir(dir);
+goto finish;
+} else
+r = 0;
+}
+closedir(dir);
+}
+
+SET_FOREACH(n, nodes, i) {
+log_debug("Fixing up ACLs at %s for seat %s", n, seat);
+r = devnode_acl(n, flush, del, old_uid, add, new_uid);
+}
+
+finish:
+udev_enumerate_unref(e);
+set_free_free(nodes);
 return r;
 }
-- 
1.8.3.3

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

[systemd-devel] [PATCHv3 1/2] udev: export tags of "dead" device nodes to /run/udev/static_node-tags/

[Tom Gundersen]

Based on a patch by Kay Sievers.

A tag is exported at boot as a symlinks to the device node in the folder
/run/udev/static_node-tags//, if the device node exists.

These tags are cleaned up by udevadm info --cleanup-db, but are otherwise
never removed.
---
 man/udev.xml   | 10 --
 src/login/70-uaccess.rules |  3 +-
 src/udev/udev-rules.c  | 82 ++
 src/udev/udev.h|  2 +-
 src/udev/udevadm-info.c|  6 
 src/udev/udevd.c   |  4 ++-
 6 files changed, 88 insertions(+), 19 deletions(-)

diff --git a/man/udev.xml b/man/udev.xml
index 553bbfd..ca8444c 100644
--- a/man/udev.xml
+++ b/man/udev.xml
@@ -521,9 +521,13 @@
 static_node=
 
   Apply the permissions specified in this rule to the 
static device node with
-  the specified name. Static device node creation can be 
requested by kernel modules.
-  These nodes might not have a corresponding kernel device at 
the time systemd-udevd is
-  started; they can trigger automatic kernel module 
loading.
+  the specified name. Also, for every tag specified in this 
rule, create a symlink
+  in the directory
+  
/run/udev/static_node-tags/tag
+  pointing at the static device node with the specified name. 
Static device node
+  creation is performed by systemd-tmpfiles before 
systemd-udevd is started. The
+  static nodes might not have a corresponding kernel device; 
they are used to
+  trigger automatic kernel module loading when they are 
accessed.
 
   
   
diff --git a/src/login/70-uaccess.rules b/src/login/70-uaccess.rules
index a118f8e..01484c9 100644
--- a/src/login/70-uaccess.rules
+++ b/src/login/70-uaccess.rules
@@ -25,7 +25,8 @@ SUBSYSTEM=="block", ENV{ID_CDROM}=="1", TAG+="uaccess"
 SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", 
TAG+="uaccess"
 
 # Sound devices
-SUBSYSTEM=="sound", TAG+="uaccess"
+SUBSYSTEM=="sound", TAG+="uaccess" \
+  OPTIONS+="static_node=snd/timer", OPTIONS+="static_node=snd/seq"
 
 # ffado is an userspace driver for firewire sound cards
 SUBSYSTEM=="firewire", ENV{ID_FFADO}=="1", TAG+="uaccess"
diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index fe65e2d..8ace705 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -33,6 +33,7 @@
 #include "path-util.h"
 #include "conf-files.h"
 #include "strbuf.h"
+#include "strv.h"
 
 #define PREALLOC_TOKEN  2048
 
@@ -152,9 +153,9 @@ enum token_type {
 TK_A_OWNER_ID,  /* uid_t */
 TK_A_GROUP_ID,  /* gid_t */
 TK_A_MODE_ID,   /* mode_t */
+TK_A_TAG,   /* val */
 TK_A_STATIC_NODE,   /* val */
 TK_A_ENV,   /* val, attr */
-TK_A_TAG,   /* val */
 TK_A_NAME,  /* val */
 TK_A_DEVLINK,   /* val */
 TK_A_ATTR,  /* val, attr */
@@ -2496,16 +2497,21 @@ int udev_rules_apply_to_event(struct udev_rules *rules, 
struct udev_event *event
 }
 }
 
-void udev_rules_apply_static_dev_perms(struct udev_rules *rules)
+int udev_rules_apply_static_dev_perms(struct udev_rules *rules)
 {
 struct token *cur;
 struct token *rule;
 uid_t uid = 0;
 gid_t gid = 0;
 mode_t mode = 0;
+_cleanup_strv_free_ char **tags = NULL;
+char **t;
+FILE *f = NULL;
+_cleanup_free_ char *path = NULL;
+int r = 0;
 
 if (rules->tokens == NULL)
-return;
+return 0;
 
 cur = &rules->tokens[0];
 rule = cur;
@@ -2522,6 +2528,8 @@ void udev_rules_apply_static_dev_perms(struct udev_rules 
*rules)
 uid = 0;
 gid = 0;
 mode = 0;
+strv_free(tags);
+tags = NULL;
 break;
 case TK_A_OWNER_ID:
 uid = cur->key.uid;
@@ -2532,18 +2540,52 @@ void udev_rules_apply_static_dev_perms(struct 
udev_rules *rules)
 case TK_A_MODE_ID:
 mode = cur->key.mode;
 break;
+case TK_A_TAG:
+r = strv_extend(&tags, rules_str(rules, 
cur->key.value_off));
+if (r < 0)
+goto finish;
+
+break;
 case TK_A_STATIC_NODE: {
-char filename[UTIL_PATH_SIZE];
+char device_node[UTIL_PATH_SIZE];
+char tags_dir[UTIL_PATH_SIZE];
+char tag_symlink[UTIL_PATH

Re: [systemd-devel] [PATCHv2 1/2] udev: export tags of "dead" device nodes to /run/udev/static_node-tags/

[Tom Gundersen]

On Sun, Jul 14, 2013 at 2:51 PM, Dave Reisner  wrote:
>> @@ -152,9 +153,9 @@ enum token_type {
>>  TK_A_OWNER_ID,  /* uid_t */
>>  TK_A_GROUP_ID,  /* gid_t */
>>  TK_A_MODE_ID,   /* mode_t */
>> +TK_A_TAG,   /* val */
>>  TK_A_STATIC_NODE,   /* val */
>>  TK_A_ENV,   /* val, attr */
>> -TK_A_TAG,   /* val */
>
> Is this swap really needed?

Yeah, this indicates the precedence of the tokens and we need to
handle the TAG tokens before the STATIC_NODE ones.

>> @@ -2532,18 +2540,56 @@ void udev_rules_apply_static_dev_perms(struct 
>> udev_rules *rules)
>>  case TK_A_MODE_ID:
>>  mode = cur->key.mode;
>>  break;
>> +case TK_A_TAG:
>> +t = strv_append(tags, rules_str(rules, 
>> cur->key.value_off));
>
> Isn't strv_extend what you want here? It wouldn't copy the whole string
> array, just push the string onto it.

Indeed, fixed.

>> +finish:
>> +if (f) {
>> +fflush(f);
>> +fchmod(fileno(f), 0644);
>> +if (ferror(f) || rename(path, "/run/udev/static_node-tags") 
>> < 0) {
>> +r = -errno;
>
> I'm not sure this will capture a useful/accurate errno if fflush()
> fails, setting the error flag on the FILE*.

As discussed on IRC, this should be fine.

>> diff --git a/src/udev/udevd.c b/src/udev/udevd.c
>> index c4127cd..285f9a0 100644
>> --- a/src/udev/udevd.c
>> +++ b/src/udev/udevd.c
>> @@ -1197,7 +1197,8 @@ int main(int argc, char *argv[])
>>  }
>>  log_debug("set children_max to %u\n", children_max);
>>
>> -udev_rules_apply_static_dev_perms(rules);
>> +if (udev_rules_apply_static_dev_perms(rules) < 0)
>> +log_error("failed to apply permissions on static device 
>> nodes\n");
>
> Hmm, not going to use the return from udev_rules_apply_static_dev_perms
> to add to the error?

Fixed.

Thanks,

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

Re: [systemd-devel] Inhibiting plug and play

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/16/2013 1:23 PM, Lennart Poettering wrote:
> So, Kay suggested we should use BSD file locks for this. i.e. all
> tools which want to turn off events for a device would take one on
> that specific device fd. As long as it is taken udev would not
> generate events. As soon as the BSD lock is released again it would
> recheck the device.
> 
> To me this sounds like a pretty clean thing to do. Locks usually
> suck, but for this purpose they appear to do exactly what they
> should, and most of the problematic things with them don't apply in
> this specific case.
> 
> Doing things way would be quite robust, as we have clean
> synchronization and the kernel will release the locks automatically
> when the owner dies.
> 
> Opinions?

Sounds like it might work.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR5YRIAAoJEJrBOlT6nu75VLUH/3X7fHhppdUCw5WFt1PpitKK
O9tuPcs9RZBWhaQ+Ol9Sp82qnEG+mqmmCLAc3z35Zj1PpNRKTLYrGWbmqlbkPsks
ZU4UZTnr9i03uDRuQfSMtUsTpnriBILT8tfyPkH7XYulGBligI3D3Sdk6LWD6Y6J
tm0SnVlOk/tm4FasWFT4KlFp/obRuL8yUBnZvgYqyTblCeVTX2013xEtXN/TG9pH
4iNSgRTQ98K/EdZQP1yz2j/LSLn0MFQTCPU4YuDVmds9nU2iZAllaY+sSMQCSkm6
Ks4giagyhKsBw8oy3AAN5f/VEvpriuAAVrLxNNaTzTAfR//J7gHwzB40ploB3oo=
=+o3u
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unbuffered stderr for my systemd service?

[WANG Chao]

On 07/16/13 at 02:00pm, Kay Sievers wrote:
> On Tue, Jul 16, 2013 at 5:30 AM, WANG Chao  wrote:
> > On 07/15/13 at 10:46pm, Lennart Poettering wrote:
> >> On Mon, 15.07.13 17:56, WANG Chao (chaow...@redhat.com) wrote:
> >>
> >> > I have a service (a script) running under systemd and need its stderr to
> >> > be output'd immediately, not line buffered. I tried serveral ways but
> >> > didn't work out. I hope to get some feedback here :)
> >>
> >> This is not supported. Logging doesn't deal in individual
> >> characters, really, but in log lines. Syslog doesn't do that, and
> >> neither does the Journal.
> >>
> >> And we will never support that, as allowing this would require us to
> >> always store the context a character was printed in so that lines could
> >> later be reassembled. But we cannot really do that.
> >>
> >> So, I fear I have to tell you that this is not supported and never
> >> will...
> >
> > I understand that. Record the context of a character is printed would
> > never be a good idea. But still, I feel pity about line buffered stderr
> > stream in Journal :(
> 
> It is the right thing to buffer just buffer them to full lines.

Yes. Or buffer wouldn't be called "buffer".

> 
> For the kernel counterpart, we added unbuffered console magic to the
> kernel. It is really nasty and broken hack and really makes not much
> sense in th eend. The code does work in the most common case, but just
> does stupid things as soon as things start to compete about the log.
> 
>  
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=084681d14e429cb6192262ac7437f00e2c02f26a
>  
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eab072609e11a357181806ab5a5c309ef6eb76f5
> 
> Pretending to support pushing "animations" through a log system is a
> pretty bad idea and relies on technical promises nobody can really
> hold without inventing something that isn't logging anymore. But we
> have that already, it's the console. :)

I couldn't agree more. Log system can't really record "animations" in a
common way. So in my case, console is right thing to use. Thanks for
your information here. Have a good day!

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

Re: [systemd-devel] Inhibiting plug and play

[Lennart Poettering]

On Tue, 18.06.13 13:45, Phillip Susi (ps...@ubuntu.com) wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Various tools, but most notably partitioners, manipulate disks in such
> a way that they need to prevent the rest of the system from racing
> with them while they are in the middle of manipulating the disk.
> Presently this is done with a hodge podge of hacks that involve
> running some script or executable to temporarily hold off on some
> aspects ( typically only auto mounting ) of plug and play processing.
>  Which one depends on whether you are running hal, udisks, udisks2, or
> systemd.
> 
> There really needs to be a proper way at a lower level, either udev,
> or maybe in the kernel, to inhibit processing events until the tool
> changing the device has finished completely.  The question is, should
> this be in the kernel, or in udev, and what should the interface be?

So, Kay suggested we should use BSD file locks for this. i.e. all tools
which want to turn off events for a device would take one on that
specific device fd. As long as it is taken udev would not generate
events. As soon as the BSD lock is released again it would recheck the
device.

To me this sounds like a pretty clean thing to do. Locks usually suck,
but for this purpose they appear to do exactly what they should, and
most of the problematic things with them don't apply in this specific
case.

Doing things way would be quite robust, as we have clean synchronization
and the kernel will release the locks automatically when the owner dies.

Opinions?

Lennart

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

Re: [systemd-devel] Unbuffered stderr for my systemd service?

[WANG Chao]

On 07/16/13 at 01:39pm, Kay Sievers wrote:
> On Tue, Jul 16, 2013 at 5:30 AM, WANG Chao  wrote:
> 
> >> (Humm, please do not use "--" on a single line in the middle of an
> >> email, that's indication for many MUAs that this is where the signature
> >> starts, and they chop this off when replying...)
> >
> > Sorry about "--", never thought that would be an issue. Thanks for
> > telling!
> 
> It would only happen on _really_ broken mail programs, because the
> convention includes a trailing space character which you didn't add.
> The delimiter line is defined as "-- ".
> 
>   http://tools.ietf.org/html/rfc3676#section-4.3

Great to know!

I'm curious about what mail client Lennart has been using. Surely he
deserves a better one :P

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

Re: [systemd-devel] [PATCH] Log failing start conditions

[Lennart Poettering]

On Wed, 26.06.13 15:06, har...@redhat.com (har...@redhat.com) wrote:

> From: Harald Hoyer 
> 
> $ systemctl status dracut-initqueue.service
> dracut-initqueue.service - dracut initqueue hook
>Loaded: loaded (/usr/lib/systemd/system/dracut-initqueue.service;
> static)
>Active: inactive (dead)
>   start condition failed at Wed 2013-06-26 13:01:05 UTC; 22s ago
>  Docs: man:dracut-initqueue.service(8)

I'd prefer if we'd solve this without the journal. Instead, I think
"struct Condition" should be extended to store the most recent test
result in a tri-state, i.e. negative for "untested", zero for "failed",
positive for "succeeded". Then we should add bus property to the Unit
interface that is an array of structs with the conditions in them,
including their results.

We currently do not expose the parsed conditions at all on the bus. This
was mostly an oversight, but this this gives us the freedom to introduce
it now and include the result value in the array entries.

With that in place systemctl should simple retrieve this property and
show the results of *all* individual condition checks if the overall
condition result was negatzive.

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Colin Guthrie]

'Twas brillig, and Kay Sievers at 16/07/13 17:24 did gyre and gimble:
> On Tue, Jul 16, 2013 at 6:01 PM, Lennart Poettering
>  wrote:
> 
>> Hmm, I'd like such an automatism, but I'd really prefer if we could come
>> up with some scheme to automatically determine all tmpfiles snippets in
>> the package and apply them all automatically. But I am not sure how that
>> could be done with current RPM.
>>
>> In fact, I'd actually like to do the same for the %systemd_post macros,
>> and suchlike, where people tend to be pretty bad at always listing all
>> unit files correctly.

Actually rereading this bit above, I can see the desire for automated
snippets, but are there not some cases where you would want to avoid
calling %systemd_post macros for some shipped units? e.g. they may only
be used internally by others (Requires=, Also= and similar). I think
such automation might not be good. (just look at the NFS units which I
think we've finally cleaned up a bit in Mageia - enough to actually work
at least).

> Hmm, an rpmlint check for stuff like this maybe is the first step? At
> least people who care and look at that would fix their stuff?

Misc was looking at doing most of that. Not sure what you mean about
naming tho'... do you just mean the folder name (etc vs usr) or just not
picking very nice unit names?

For the folder, I put rpmlint checks in Mageia a while ago to ban units,
tmpfiles and udev rules from shipping in /etc.

And another to do with non-ghost files in /run or /var/run.

I had it in my head that I'd spoken to Misc about this at the time I
wrote them but now I have a paranoid fear that maybe I didn't... They
are simple enough anyway, so if they are not upstream and have instead
been reimplemented then it's no great loss, but apologies if forgot to
ping you at the time Misc (and I've seen you twice in person since then
too!!)

Patches here. Can't check if it's upstream yet as rpmlint.zarb.org is
down for now...

http://svnweb.mageia.org/packages/cauldron/rpmlint/current/SOURCES/

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] [PATCH 2/2] util.c:is_locale_utf8(): check, if "C" was set on purpose

[Lennart Poettering]

On Thu, 27.06.13 11:26, har...@redhat.com (har...@redhat.com) wrote:

> From: Harald Hoyer 
> 
> If you have a ASCII only terminal, there is no way to set the charmap to
> ANSI_X3.4-1968, other than using LC_CTYPE=C.
> 
> We don't want to assume a UTF-8 capable terminal in this case and only
> do so, if LANG, LC_ALL and LC_CTYPE are unset.

Applied, but folded the check into one line. Please verify!

Thanks!

> ---
>  src/shared/util.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/shared/util.c b/src/shared/util.c
> index 04811ff..c4b644b 100644
> --- a/src/shared/util.c
> +++ b/src/shared/util.c
> @@ -5387,6 +5387,10 @@ bool is_locale_utf8(void) {
>  
>  cached_answer = streq(set, "C");
>  
> +/* LC_CTYPE=="C", now check, if it was set by purpose */
> +if (cached_answer && (getenv("LC_ALL") || getenv("LC_CTYPE") || 
> getenv("LANG")))
> +cached_answer = false;
> +
>  out:
>  return (bool)cached_answer;
>  }


Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Lennart Poettering]

On Tue, 16.07.13 18:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> 
> On Tue, Jul 16, 2013 at 05:08:12PM +0100, Colin Guthrie wrote:
> > 'Twas brillig, and Lennart Poettering at 16/07/13 17:01 did gyre and gimble:
> > > Anyway, does that RPM macro sound good to you?
> >
> > Sure, seems close enough :)
> >
> > I can do a mass update to all our packages anyway so the slight change
> > in syntax isn't a problem.
> Hm, can we take a step back for a moment? It seems that the rpm macros
> are a fairly complicated solution, and they also don't carry over into
> debian or arch. User mode sessions also will not work with rpm macros.

Well, it's easy to come up with similar macros for debhelper or arch...

User session don't really need this, as there as user daemons usually
create the dirs they need on their own and there are no privileges
involved which might forbid this.

I have commite the RPM macro fro now, since either way we will need it
for the packages where the dirs need to exist all the time.

> > I am not too concerned about unused runtime directories. After all this
> > is not something that would (or even could) grow without bounds. There
> > will never be more than O(n) runtime directores for n being the number
> > of packages you have installed (or had installed).
> Sure, but this n can be around a couple hundred I'd image when debian
> is fully converted and installed. For efficiency this is probably
> unmesurable, but as an admin I'd prefer not to have hundreds of empty
> dirs in /run.

On my (pretty much fully converted) Fedora I currently have 20 tmpfiles
snippets around. I doubt on an everage Debian machine this would grow
much larger. May 40 or so, but that's still not much.

> > However, I am not convinced that allowing tmpfiles to be denoted in unit
> > files would be a good thing though, because it sounds unnecessary. It
> > really sounds as if the daemons which need that should rather create the
> > directories on their own before making use of them. This should
> > generally be the most robust solution. And in such a case there's no
> > need to denote anything about this in the unit files at all...
>
> Well, we seem to be using the tmpfiles mechanism quite a lot. And
> there are good reasons for that: we get a lot of flexibility with a
> powerful syntax, and actually there's significant downsides to putting
> all this logic in daemons, e.g. support for various xattr
> mechanisms. We want to simplify daemons. Also, as you mentioned, some
> stuff runs unpriviledged.

I want daemons to be robust. So if possible I think daemons should do
these things on their own. This also has benefits for systems like selinux
where the label for files can be determined using the normal security
transitions, rather then databse checks like we currently need to do
it...

> Also, we could grow a mechanism to *remove* dirs after the daemon is
> stopped. Putting it in rpm specific mechanism removes this possibility.

I can see how this could be nice but it kinda reminds me of the
situation regarding removing UIDs from /etc/passwd after package
deinstallation, which is soemthing that is simply very hard to ever get
rid, and which is why Fedora is not doing this at all...

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Lennart Poettering]

On Tue, 16.07.13 17:08, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> 
> 'Twas brillig, and Lennart Poettering at 16/07/13 17:01 did gyre and gimble:
> > Anyway, does that RPM macro sound good to you?
> 
> Sure, seems close enough :)
> 
> I can do a mass update to all our packages anyway so the slight change
> in syntax isn't a problem.

As mentioned, I commited this now, since we need this in any way. Could
you check if this works for you, please?

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Lennart Poettering]

On Tue, 16.07.13 18:24, Kay Sievers (k...@vrfy.org) wrote:

> 
> On Tue, Jul 16, 2013 at 6:01 PM, Lennart Poettering
>  wrote:
> 
> > Hmm, I'd like such an automatism, but I'd really prefer if we could come
> > up with some scheme to automatically determine all tmpfiles snippets in
> > the package and apply them all automatically. But I am not sure how that
> > could be done with current RPM.
> >
> > In fact, I'd actually like to do the same for the %systemd_post macros,
> > and suchlike, where people tend to be pretty bad at always listing all
> > unit files correctly.
> 
> Hmm, an rpmlint check for stuff like this maybe is the first step? At
> least people who care and look at that would fix their stuff?

Makes sense. Added to the TODO list for now.

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Tom Gundersen]

On Tue, Jul 16, 2013 at 6:34 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> Hm, can we take a step back for a moment? It seems that the rpm macros
> are a fairly complicated solution, and they also don't carry over into
> debian or arch. User mode sessions also will not work with rpm macros.

For what it is worth we have been calling "systemd-tmpfiles --create
$pkgname.conf" in post-install for a long time in Arch (since the
beginning I think), and it doesn't seem to be a big problem. However,
if you have some idea for simplifying it somehow, I'd be all for that
of course :-)

Maybe establish an implicit link between foo.service and
tmpfiles.d/foo.conf, which would allow calling systemd-tmpfiles
--create/--clean before/after start/stop? Not sure if it is really
worth it, and not sure there won't be regressions though...

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 16, 2013 at 05:08:12PM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Lennart Poettering at 16/07/13 17:01 did gyre and gimble:
> > Anyway, does that RPM macro sound good to you?
>
> Sure, seems close enough :)
>
> I can do a mass update to all our packages anyway so the slight change
> in syntax isn't a problem.
Hm, can we take a step back for a moment? It seems that the rpm macros
are a fairly complicated solution, and they also don't carry over into
debian or arch. User mode sessions also will not work with rpm macros.

I'm sure we can get them to work, but I'd like to explore the idea of
moving that into unit files first.

> I am not too concerned about unused runtime directories. After all this
> is not something that would (or even could) grow without bounds. There
> will never be more than O(n) runtime directores for n being the number
> of packages you have installed (or had installed).
Sure, but this n can be around a couple hundred I'd image when debian
is fully converted and installed. For efficiency this is probably
unmesurable, but as an admin I'd prefer not to have hundreds of empty
dirs in /run.

> We will always need setting up of tmpfiles during boot, as many clients
> expect certain directories to be existant in /run without any specific
> daemon running. Thus, we couldn't move this stuff into service files ---
> we could only allow both.
Yes, I'm not arguing for removing boot time tmpfiles.

> However, I am not convinced that allowing tmpfiles to be denoted in unit
> files would be a good thing though, because it sounds unnecessary. It
> really sounds as if the daemons which need that should rather create the
> directories on their own before making use of them. This should
> generally be the most robust solution. And in such a case there's no
> need to denote anything about this in the unit files at all...
Well, we seem to be using the tmpfiles mechanism quite a lot. And
there are good reasons for that: we get a lot of flexibility with a
powerful syntax, and actually there's significant downsides to putting
all this logic in daemons, e.g. support for various xattr
mechanisms. We want to simplify daemons. Also, as you mentioned, some
stuff runs unpriviledged.

Also, we could grow a mechanism to *remove* dirs after the daemon is
stopped. Putting it in rpm specific mechanism removes this possibility.

> I mean, this is the general recommendation anyway: if possible just fix
> the daemon to create the dirs as it needs it. Use tmpfiles only if
> that's not feasible, maybe because the daemon never runs privileged code
> or because the dirs need to exist at boot already.
> 
> Something I'd love to see though is if we could make it easier to apply
> tmpfiles stuff automatically on package installation. More specifically,
> I'd like an RPM macro to be added that handles this, and which is
> sufficient for packagers to call for their tmpfiles. ALl in order to
> ensure that the user can invoke the services right after package
> installation without requiring a reboot.
>

Zbyszek
-- 
they are not broken. they are refucktored
   -- alxchk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Kay Sievers]

On Tue, Jul 16, 2013 at 6:01 PM, Lennart Poettering
 wrote:

> Hmm, I'd like such an automatism, but I'd really prefer if we could come
> up with some scheme to automatically determine all tmpfiles snippets in
> the package and apply them all automatically. But I am not sure how that
> could be done with current RPM.
>
> In fact, I'd actually like to do the same for the %systemd_post macros,
> and suchlike, where people tend to be pretty bad at always listing all
> unit files correctly.

Hmm, an rpmlint check for stuff like this maybe is the first step? At
least people who care and look at that would fix their stuff?

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 16/07/13 17:01 did gyre and gimble:
> Anyway, does that RPM macro sound good to you?

Sure, seems close enough :)

I can do a mass update to all our packages anyway so the slight change
in syntax isn't a problem.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
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] [PATCH 1/2] Do not set LANG=C in every child environment.

[Lennart Poettering]

On Thu, 27.06.13 11:26, har...@redhat.com (har...@redhat.com) wrote:

> From: Harald Hoyer 
> 
> LANG does not have to be set and setting it to default to the default
> does not add any value.

Hmm, I wonder why we had this in in the first place. 

Thanks, applied!

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Lennart Poettering]

On Tue, 16.07.13 16:50, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> 3. Finally I settled on:
> 
> %_tmpfilesdir /usr/lib/tmpfiles.d
> %_tmpfilescreate() /usr/bin/systemd-tmpfiles --create %{1}.conf \
> %{nil}
> 

This looks pretty close to what I'd like to see in place. Note that
%_tmpfilesdir is already set in macros.systemd as we ship it upstream.

My suggestion would be this however:

_tmpfiles_create() \
/usr/bin/systemd-tmpfiles --create %{1} >/dev/null 2>&1 || : \
%{nil} 

I thik that people should specify file names rather than package names
(just to keep this closer to the underlying command and to make the
multiple drop-in case less exotic, and since we require the suffixe for
the unit macros too) and ignore errors. Also, add an underscore since
our other macros use the same naming style.

> In spec files I just put "%_tmpfilescreate %{name}" in %post in 99% of
> cases and a custom basename for when the file name does not match the
> package name in some rare cases.
> 
> I'm sure the macro could be tweaked to put %{name} in magically if no
> argument is supplied..

Hmm, I'd like such an automatism, but I'd really prefer if we could come
up with some scheme to automatically determine all tmpfiles snippets in
the package and apply them all automatically. But I am not sure how that
could be done with current RPM.

In fact, I'd actually like to do the same for the %systemd_post macros,
and suchlike, where people tend to be pretty bad at always listing all
unit files correctly.

Anyway, does that RPM macro sound good to you? If so, let's add this to
macros.systemd and I'll ask our Fedora guys to add this to the
guidelines.

Lennart

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

Re: [systemd-devel] [PATCH] journal: return -ECHILD after a fork

[Lennart Poettering]

On Wed, 26.06.13 19:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> A few asserts are replaced with 'return -EINVAL'. I think that
> assert should not be used to check argument in public functions.
> 
> Fields in struct sd_journal are rearranged to make it less
> swiss-cheesy.
> ---
> Does this look sound?

Yupp! Looks great! Please commit!

> 
> Zbyszek
> 
>  TODO   |  5 +--
>  man/sd_journal_open.xml|  7 
>  src/journal/journal-internal.h | 18 +-
>  src/journal/sd-journal.c   | 80 
> +++---
>  4 files changed, 93 insertions(+), 17 deletions(-)
> 
> diff --git a/TODO b/TODO
> index caba4e3..2968d18 100644
> --- a/TODO
> +++ b/TODO
> @@ -68,7 +68,7 @@ Features:
>  
>  * document systemd-journal-flush.service properly
>  
> -* chane systemd-journal-flush into a service that stays around during
> +* change systemd-journal-flush into a service that stays around during
>boot, and causes the journal to be moved back to /run on shutdown,
>so that we don't keep /var busy. This needs to happen synchronously,
>hence doing this via signals is not going to work.
> @@ -76,9 +76,6 @@ Features:
>  * allow implementation of InaccessibleDirectories=/ plus
>ReadOnlyDirectories=... for whitelisting files for a service.
>  
> -* libsystemd-journal:
> -  - return ECHILD as soon as somebody tries to reuse a journal object across 
> a fork()
> -
>  * libsystemd-bus:
>- default policy (allow uid == 0 and our own uid)
>- enforce alignment of pointers passed in
> diff --git a/man/sd_journal_open.xml b/man/sd_journal_open.xml
> index d7ea8ff..b2f6f9e 100644
> --- a/man/sd_journal_open.xml
> +++ b/man/sd_journal_open.xml
> @@ -131,6 +131,13 @@
>  can be rotated at any moment, and the opening of
>  specific files is inherently racy.
>  
> +sd_journal objects cannot be
> +used in the child after a fork. Functions which take a
> +journal object as an argument
> +(sd_journal_next() and others)
> +will return -ECHILD after a fork.
> +
> +
>  sd_journal_close() will
>  close the journal context allocated with
>  sd_journal_open() or
> diff --git a/src/journal/journal-internal.h b/src/journal/journal-internal.h
> index 5b717f8..5bc6535 100644
> --- a/src/journal/journal-internal.h
> +++ b/src/journal/journal-internal.h
> @@ -97,8 +97,6 @@ struct Directory {
>  };
>  
>  struct sd_journal {
> -int flags;
> -
>  char *path;
>  
>  Hashmap *files;
> @@ -109,27 +107,29 @@ struct sd_journal {
>  JournalFile *current_file;
>  uint64_t current_field;
>  
> -Hashmap *directories_by_path;
> -Hashmap *directories_by_wd;
> -
> -int inotify_fd;
> -
>  Match *level0, *level1, *level2;
>  
> +pid_t original_pid;
> +
> +int inotify_fd;
>  unsigned current_invalidate_counter, last_invalidate_counter;
> +usec_t last_process_usec;
>  
>  char *unique_field;
>  JournalFile *unique_file;
>  uint64_t unique_offset;
>  
> +int flags;
> +
>  bool on_network;
>  bool no_new_files;
>  
>  size_t data_threshold;
>  
> -Set *errors;
> +Hashmap *directories_by_path;
> +Hashmap *directories_by_wd;
>  
> -usec_t last_process_usec;
> +Set *errors;
>  };
>  
>  char *journal_make_match_string(sd_journal *j);
> diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c
> index 1e70739..81b0c13 100644
> --- a/src/journal/sd-journal.c
> +++ b/src/journal/sd-journal.c
> @@ -50,6 +50,15 @@
>  
>  #define DEFAULT_DATA_THRESHOLD (64*1024)
>  
> +static bool journal_pid_changed(sd_journal *j) {
> +assert(j);
> +
> +/* We don't support people creating a journal object and
> + * keeping it around over a fork(). Let's complain. */
> +
> +return j->original_pid != getpid();
> +}
> +
>  /* We return an error here only if we didn't manage to
> memorize the real error. */
>  static int set_put_error(sd_journal *j, int r) {
> @@ -209,6 +218,8 @@ _public_ int sd_journal_add_match(sd_journal *j, const 
> void *data, size_t size)
>  
>  if (!j)
>  return -EINVAL;
> +if (journal_pid_changed(j))
> +return -ECHILD;
>  
>  if (!data)
>  return -EINVAL;
> @@ -303,7 +314,10 @@ fail:
>  }
>  
>  _public_ int sd_journal_add_conjunction(sd_journal *j) {
> -assert(j);
> +if (!j)
> +return -EINVAL;
> +if (journal_pid_changed(j))
> +return -ECHILD;
>  
>  if (!j->level0)
>  return 0;
> @@ -321,7 +335,10 @@ _public_ int sd_journal_add_conjunction(sd_journal *j) {
>  }
>  
>  _public_ int sd_journal_add_disjunction(sd_journa

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 16/07/13 16:00 did gyre and gimble:
> Something I'd love to see though is if we could make it easier to apply
> tmpfiles stuff automatically on package installation. More specifically,
> I'd like an RPM macro to be added that handles this, and which is
> sufficient for packagers to call for their tmpfiles. ALl in order to
> ensure that the user can invoke the services right after package
> installation without requiring a reboot.

I've gone around the block a few times on this.

1. We used file triggers (which we've supported for a while with various
patches to rpm but which think are only just now coming to fedora via
official support in upstream rpm - I forget the details tho', so could
be wrong), but this was a bad idea as these triggers ran too late after
%post. As %post might need these folders to start/restart the daemon, I
had to abandon that.

2. I used to recommend just running "systemd-tmpfiles --create" but this
meant that the /run/nologin file was created which meant you couldn't
login... ugg. Don't do that in any macro please :D

3. Finally I settled on:

%_tmpfilesdir /usr/lib/tmpfiles.d
%_tmpfilescreate() /usr/bin/systemd-tmpfiles --create %{1}.conf \
%{nil}


In spec files I just put "%_tmpfilescreate %{name}" in %post in 99% of
cases and a custom basename for when the file name does not match the
package name in some rare cases.

I'm sure the macro could be tweaked to put %{name} in magically if no
argument is supplied..

HTHs (and if you have no preference as to the name, that you can use the
one I already use ;)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
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] test-tables failure

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 16, 2013 at 05:43:02PM +0200, Jan Janssen wrote:
> On 07/16/2013 04:33 PM, Lennart Poettering wrote:
> >On Tue, 16.07.13 14:57, Jan Janssen (medhe...@web.de) wrote:
> >
> >>Hi,
> >>
> >>test-tables fails on my system. The one it's failing on is:
> >> syscall: 222 → (null) → -1
> >>
> >>syscall_max() tells me that I have 351 syscalls, so I guess
> >>there is a logic error in the test case?
> >>
> >>This is on a pretty old x86 machine.
> >
> >Hmm, on your system do you have a syscall 222 defined anywhere in
> >sys/syscall.h (or any of the headers that pulls in)?
> >
> >Lennart
> >
> 
> Nope, unistd_x32.h nor unistd_32.h (whichever one is included from
> syscall.h on my system) has syscall 222.
I'll fix the test to accept holes in the syscall table.

-- 
they are not broken. they are refucktored
   -- alxchk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v5] journalctl: Add support for showing messages from a previous boot

[Lennart Poettering]

On Tue, 16.07.13 17:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> 
> On Tue, Jul 16, 2013 at 05:39:54PM +0200, Lennart Poettering wrote:
> > On Fri, 28.06.13 17:26, Jan Janssen (medhe...@web.de) wrote:
> > Applied this one now. If people start complaining about its speed we can
> > reinvestigate and do find some way for optimization...
> We need to think about negative matches. Looking for previous boots
> with negative matches should work nicely.

The bisection tables make this less efficient but certainly possible.

> I'd like to complain about the : in the syntax though.

Hmm, what would you propose? There's still time to fix it!

Lennart

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

Re: [systemd-devel] [PATCH] man: use HTTPS links for links that support it

[Lennart Poettering]

On Tue, 16.07.13 10:19, Jason St. John (jstj...@purdue.edu) wrote:

Thanks!

Applied!

> From: "Jason St. John" 
> 
> ---
>  man/binfmt.d.xml   |  2 +-
>  man/journald.conf.xml  |  2 +-
>  man/machine-id.xml |  2 +-
>  man/os-release.xml |  2 +-
>  man/sd-id128.xml   |  2 +-
>  man/systemd.cgroup.xml | 20 ++--
>  man/systemd.exec.xml   |  6 +++---
>  man/systemd.xml|  2 +-
>  8 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml
> index 7f31b76..f4f4195 100644
> --- a/man/binfmt.d.xml
> +++ b/man/binfmt.d.xml
> @@ -67,7 +67,7 @@
>  
>  Each file contains a list of binfmt_misc kernel
>  binary format rules. Consult  -
> url="http://www.kernel.org/doc/Documentation/binfmt_misc.txt";>binfmt_misc.txt
> +
> url="https://www.kernel.org/doc/Documentation/binfmt_misc.txt";>binfmt_misc.txt
>  for more information on registration of additional
>  binary formats and how to write rules.
>  
> diff --git a/man/journald.conf.xml b/man/journald.conf.xml
> index 5986d61..487e8d6 100644
> --- a/man/journald.conf.xml
> +++ b/man/journald.conf.xml
> @@ -133,7 +133,7 @@
>  command), forward secure sealing (FSS)
>  for all persistent journal files is
>  enabled. FSS is based on  -
> url="http://eprint.iacr.org/2013/397";>Seekable
> +
> url="https://eprint.iacr.org/2013/397";>Seekable
>  Sequential Key Generators by
>  G. A. Marson and B. Poettering and
>  may be used to protect journal files
> diff --git a/man/machine-id.xml b/man/machine-id.xml
> index b037e47..4b4759e 100644
> --- a/man/machine-id.xml
> +++ b/man/machine-id.xml
> @@ -93,7 +93,7 @@
>  
>  Note that the machine ID historically is not an
>  OSF UUID as defined by  -url="http://tools.ietf.org/html/rfc4122";>RFC
> +url="https://tools.ietf.org/html/rfc4122";>RFC
>  4122, nor a Microsoft GUID; however, starting with
>  systemd v30, newly generated machine IDs do
>  qualify as v4 UUIDs.
> diff --git a/man/os-release.xml b/man/os-release.xml
> index d714b51..045dd08 100644
> --- a/man/os-release.xml
> +++ b/man/os-release.xml
> @@ -241,7 +241,7 @@
>  
>  A CPE name for the
>  operating system, following the  -
> url="http://cpe.mitre.org/specification/";>Common
> +
> url="https://cpe.mitre.org/specification/";>Common
>  Platform Enumeration
>  Specification as proposed by
>  the MITRE Corporation. This field
> diff --git a/man/sd-id128.xml b/man/sd-id128.xml
> index 02fb76b..3a5e133 100644
> --- a/man/sd-id128.xml
> +++ b/man/sd-id128.xml
> @@ -71,7 +71,7 @@
>  process and generate 128-bit ID values. The 128-bit ID
>  values processed and generated by these APIs are a
>  generalization of OSF UUIDs as defined by  -url="http://tools.ietf.org/html/rfc4122";>RFC
> +url="https://tools.ietf.org/html/rfc4122";>RFC
>  4122 but use a simpler string
>  format. These functions impose no structure on the
>  used IDs, much unlike OSF UUIDs or Microsoft GUIDs,
> diff --git a/man/systemd.cgroup.xml b/man/systemd.cgroup.xml
> index e31faf5..bb0cb1c 100644
> --- a/man/systemd.cgroup.xml
> +++ b/man/systemd.cgroup.xml
> @@ -127,7 +127,7 @@ along with systemd; If not, see 
> .
>controls the cpu.shares control group
>attribute, which defaults to 1024. For details about this
>control group attribute, see  -  
> url="http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt";>sched-design-CFS.txt.
> +  
> url="https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt";>sched-design-CFS.txt.
>  
>Implies CPUAccounting=true.
>  
> @@ -152,7 +152,7 @@ along with systemd; If not, see 
> .
>memory.soft_limit_in_bytes control group
>attributes. For details about these control group attributes,
>see  -  
> url="http://www.kernel.org/doc/Documentation/cgroups/memory.txt";>memory.txt.
> +  
> url="https://www.kernel.org/doc/Documentation/cgroups/memory.txt";>memory.txt.
>  
>Implies MemoryAccounting=true.
>  
> @@ -172,7 +172,7 @@ along with systemd; If not, see 
> 

Re: [systemd-devel] [PATCH] man: improve readability of --output options in journalctl(1)

[Lennart Poettering]

On Tue, 16.07.13 10:20, Jason St. John (jstj...@purdue.edu) wrote:

Thanks!

Applied!

> From: "Jason St. John" 
> 
> The list and descriptions of valid output options was difficult to read,
> so break up the long block of text into discrete man page list items to
> improve readability.
> ---
>  man/journalctl.xml| 166 
> --
>  man/systemd.scope.xml |   2 +-
>  2 files changed, 120 insertions(+), 48 deletions(-)
> 
> diff --git a/man/journalctl.xml b/man/journalctl.xml
> index 71b1bab..9cabda5 100644
> --- a/man/journalctl.xml
> +++ b/man/journalctl.xml
> @@ -219,53 +219,125 @@
>  
>  Controls the
>  formatting of the journal entries that
> -are shown. Takes one of
> -short,
> -short-monotonic,
> -verbose,
> -export,
> -json,
> -json-pretty,
> -json-sse,
> -cat. 
> short
> -is the default and generates an output
> -that is mostly identical to the
> -formatting of classic syslog
> -files, showing one line per journal
> -entry. short-monotonic
> -is very similar but shows monotonic
> -timestamps instead of wallclock
> -timestamps. verbose
> -shows the full structured entry items
> -with all
> -fields. export
> -serializes the journal into a binary
> -(but mostly text-based) stream
> -suitable for backups and network
> -transfer (see  -
> url="http://www.freedesktop.org/wiki/Software/systemd/export";>Journal
> -Export Format for more
> -information). json
> -formats entries as JSON data
> -structures, one per
> -line (see  -
> url="http://www.freedesktop.org/wiki/Software/systemd/json";>Journal
> -JSON Format for more
> -information). json-pretty
> -also formats entries as JSON data
> -structures, but formats them in
> -multiple lines in order to make them
> -more readable for
> -humans. json-sse
> -also formats entries as JSON data
> -structures, but wraps them in a format
> -suitable for  -
> url="https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events";>Server-Sent
> -Events. cat
> -generates a very terse output only
> -showing the actual message of each
> -journal entry with no meta data, not
> -even a timestamp.
> +are shown. Takes one of the following 
> options:
> +
> +
> +
> +
> +
> short
> +
> +
> +is the default
> +and generates an 
> output
> +that is mostly 
> identical
> +to the formatting of
> +classic syslog files,
> +showing one line per
> +journal entry.
> +
> +
> +
> +
> +
> +
> short-monotonic
> +

Re: [systemd-devel] [PATCH v5] journalctl: Add support for showing messages from a previous boot

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 16, 2013 at 05:39:54PM +0200, Lennart Poettering wrote:
> On Fri, 28.06.13 17:26, Jan Janssen (medhe...@web.de) wrote:
> Applied this one now. If people start complaining about its speed we can
> reinvestigate and do find some way for optimization...
We need to think about negative matches. Looking for previous boots
with negative matches should work nicely.

I'd like to complain about the : in the syntax though.

Zbyszek
-- 
they are not broken. they are refucktored
   -- alxchk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] test-tables failure

[Jan Janssen]

On 07/16/2013 04:33 PM, Lennart Poettering wrote:

On Tue, 16.07.13 14:57, Jan Janssen (medhe...@web.de) wrote:


Hi,

test-tables fails on my system. The one it's failing on is:
 syscall: 222 → (null) → -1

syscall_max() tells me that I have 351 syscalls, so I guess
there is a logic error in the test case?

This is on a pretty old x86 machine.


Hmm, on your system do you have a syscall 222 defined anywhere in
sys/syscall.h (or any of the headers that pulls in)?

Lennart



Nope, unistd_x32.h nor unistd_32.h (whichever one is included from
syscall.h on my system) has syscall 222.

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

Re: [systemd-devel] [PATCH v5] journalctl: Add support for showing messages from a previous boot

[Lennart Poettering]

On Fri, 28.06.13 17:26, Jan Janssen (medhe...@web.de) wrote:

> Unfortunately, order of sd_journal_enumerate_unique() is
> undefined, so we have to sort the boot IDs. For that we
> seach for any log entry with a specific boot ID and then
> use the realtime stamp to order everything.
> ---
> 
> Hi,
> 
> I redid the boot ID look up to use enumerate_unique.
> 
> This is quite fast if the cache is warm but painfully slow if
> it isn't. It has a slight chance of returning the wrong order if
> realtime clock jumps around.
> 
> This one has to do n searches for every boot ID there is plus
> a sort, so it depends heavily on cache hotness. This is in contrast
> to the other way of look-up through filtering by a MESSAGE_ID,
> which only needs about 1 seek + whatever amount of relative IDs
> you want to walk.
> 
> I also have a linked-list + (in-place) mergesort version of this
> patch, which has pretty much the same runtime. But since this one
> is using libc sorting and armortized allocation, I prefer this
> one.
> 
> To summarize: The MESSAGE_ID way is a *lot* faster but can be
> incomplete due to rotation, while the enumerate+sort will find
> every boot ID out there but will be painfully slow for large
> journals and cold caches.
> 
> You choose :P

Applied this one now. If people start complaining about its speed we can
reinvestigate and do find some way for optimization...

Thanks,

Lennart

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

Re: [systemd-devel] [RFC] Multiseat X sessions and Xorg configs

[Glen Gray]

On 16 Jul 2013, at 16:28, Lennart Poettering  wrote:

> On Tue, 16.07.13 16:09, Glen Gray (sla...@slaine.org) wrote:
> 
>> However, I also ran into a problem with Xorg configurations. 
>> 
>> The host system runs on an embedded PC and has an xorg.conf.d Device entry 
>> for the Intel driver to enable certain options. However, this is global and 
>> caused problems with the displays on the other seats. e.g. with the second 
>> seat starting Xorg and looking for the Intel device as described in the 
>> xorg.conf.d file, rather than using the appropriate Frame-buffer device. 
>> I've patched the systemd/login/multi-seat-x.c to also pass over a -configdir 
>> parameter to the Xorg it launches. e.g '-configdir 
>> /etc/X11/xorg.conf.d/multi-session-x/seat-usb-pci-
>> _00_1d_7-usb-0_3_1_4'. I'm not entirely confident that's the correct 
>> path I should be using.
> 
> I figure both of these issues are better discussed in the gdm and X11
> mailing lists rather than here.

Agreed, however, given that systemd is currently patching the launch of Xorg 
for this environment, I thought I'd pass on my update which solves my version 
of the problem.

> Note that the "multi-seat-x" tool is on its way, see this thread:
> 
> http://lists.x.org/archives/xorg-devel/2013-July/036866.html
> 
> In this same thread there are discussions about adding a MatchSeat
> option to X. This really looks like what you are looking for? With that
> in place you could have configuration fragments that only apply to
> specific seats rather than all of them?

Ok, probably best if I take this over the the xorg-devel list then. That looks 
like the conversation I'm interested in.

Thanks,
-- 
Glen Gray


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

Re: [systemd-devel] [RFC] Multiseat X sessions and Xorg configs

[Lennart Poettering]

On Tue, 16.07.13 17:28, Lennart Poettering (lenn...@poettering.net) wrote:

> 
> On Tue, 16.07.13 16:09, Glen Gray (sla...@slaine.org) wrote:
> 
> > Hey guys,
> > 
> > I'm currently working with a Plugable DisplayLink usb hub/adaptor for 
> > adding multi-seat support to an embedded PC formfactor.
> > 
> > I've been running into difficulties with the changes to GDM and systemd 
> > with regards to multiseat support.
> > 
> > For GDM, I've patched it to do the following...
> > 1) In daemon/gdm-display.c where it currently checks if the seat != seat0. 
> > Rather than doing "goto out;" immediately, it queries the username. If the 
> > username is utilising the script method then let the automated login 
> > proceed. The script method will parse the login name as a script path if it 
> > ends with | character.
> > 
> > 2) In daemon/gdm-simple-slave.c, rather than using a global level 
> > GDM_RAN_ONCE_FILE_MARKER, create one per seat. This allows the 
> > wants_autologin() to return True on a another seat rather than drop through 
> > to simply start_greeter().
> > 
> > 3) In daemon/gdm-slave.c, Export the GDM_SEAT_ID for the initial gdm slave 
> > display. This allows you to check the current seat in the script for item 
> > 1) above.
> > 
> > That solved my gdm automated login process on the different seats. I've 
> > emailed the patch to the gdm list.
> > 
> > However, I also ran into a problem with Xorg configurations. 
> > 
> > The host system runs on an embedded PC and has an xorg.conf.d Device entry 
> > for the Intel driver to enable certain options. However, this is global and 
> > caused problems with the displays on the other seats. e.g. with the second 
> > seat starting Xorg and looking for the Intel device as described in the 
> > xorg.conf.d file, rather than using the appropriate Frame-buffer device. 
> > I've patched the systemd/login/multi-seat-x.c to also pass over a 
> > -configdir parameter to the Xorg it launches. e.g '-configdir 
> > /etc/X11/xorg.conf.d/multi-session-x/seat-usb-pci-
> > _00_1d_7-usb-0_3_1_4'. I'm not entirely confident that's the correct 
> > path I should be using.
> 
> I figure both of these issues are better discussed in the gdm and X11
> mailing lists rather than here.
> 
> Note that the "multi-seat-x" tool is on its way, see this thread:

"on its way _out_" is what I wanted to write.

> 
> http://lists.x.org/archives/xorg-devel/2013-July/036866.html
> 
> In this same thread there are discussions about adding a MatchSeat
> option to X. This really looks like what you are looking for? With that
> in place you could have configuration fragments that only apply to
> specific seats rather than all of them?
> 
> Lennart
> 


Lennart

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

Re: [systemd-devel] update: udev keymaps are moving to hwdb

[Lennart Poettering]

On Tue, 16.07.13 17:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> 
> On Tue, Jul 16, 2013 at 05:01:17PM +0200, Martin Pitt wrote:
> > Kay Sievers [2013-07-16 16:25 +0200]:
> > > Committed it now. All the old udev keymap files are gone and only the 
> > > hwdb file:
> > >   http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-keyboard.hwdb
> > > is carrying all the data.
> > 
> > \o/
> Can we have some easy documentation what commands have to be invoked
> to extract the information to write the rules? The format is nice
> and simple, but which field goes where to get the values for the
> fields is nonobvious.

Indeed, some short introduction in the wiki would be grand...

Lennart

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

Re: [systemd-devel] [RFC] Multiseat X sessions and Xorg configs

[Lennart Poettering]

On Tue, 16.07.13 16:09, Glen Gray (sla...@slaine.org) wrote:

> Hey guys,
> 
> I'm currently working with a Plugable DisplayLink usb hub/adaptor for adding 
> multi-seat support to an embedded PC formfactor.
> 
> I've been running into difficulties with the changes to GDM and systemd with 
> regards to multiseat support.
> 
> For GDM, I've patched it to do the following...
> 1) In daemon/gdm-display.c where it currently checks if the seat != seat0. 
> Rather than doing "goto out;" immediately, it queries the username. If the 
> username is utilising the script method then let the automated login proceed. 
> The script method will parse the login name as a script path if it ends with 
> | character.
> 
> 2) In daemon/gdm-simple-slave.c, rather than using a global level 
> GDM_RAN_ONCE_FILE_MARKER, create one per seat. This allows the 
> wants_autologin() to return True on a another seat rather than drop through 
> to simply start_greeter().
> 
> 3) In daemon/gdm-slave.c, Export the GDM_SEAT_ID for the initial gdm slave 
> display. This allows you to check the current seat in the script for item 1) 
> above.
> 
> That solved my gdm automated login process on the different seats. I've 
> emailed the patch to the gdm list.
> 
> However, I also ran into a problem with Xorg configurations. 
> 
> The host system runs on an embedded PC and has an xorg.conf.d Device entry 
> for the Intel driver to enable certain options. However, this is global and 
> caused problems with the displays on the other seats. e.g. with the second 
> seat starting Xorg and looking for the Intel device as described in the 
> xorg.conf.d file, rather than using the appropriate Frame-buffer device. I've 
> patched the systemd/login/multi-seat-x.c to also pass over a -configdir 
> parameter to the Xorg it launches. e.g '-configdir 
> /etc/X11/xorg.conf.d/multi-session-x/seat-usb-pci-
> _00_1d_7-usb-0_3_1_4'. I'm not entirely confident that's the correct path 
> I should be using.

I figure both of these issues are better discussed in the gdm and X11
mailing lists rather than here.

Note that the "multi-seat-x" tool is on its way, see this thread:

http://lists.x.org/archives/xorg-devel/2013-July/036866.html

In this same thread there are discussions about adding a MatchSeat
option to X. This really looks like what you are looking for? With that
in place you could have configuration fragments that only apply to
specific seats rather than all of them?

Lennart

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

Re: [systemd-devel] update: udev keymaps are moving to hwdb

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 16, 2013 at 05:01:17PM +0200, Martin Pitt wrote:
> Kay Sievers [2013-07-16 16:25 +0200]:
> > Committed it now. All the old udev keymap files are gone and only the hwdb 
> > file:
> >   http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-keyboard.hwdb
> > is carrying all the data.
> 
> \o/
Can we have some easy documentation what commands have to be invoked
to extract the information to write the rules? The format is nice
and simple, but which field goes where to get the values for the
fields is nonobvious.

Zbyszek
-- 
they are not broken. they are refucktored
   -- alxchk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [RFC] Multiseat X sessions and Xorg configs

[Glen Gray]

Hey guys,

I'm currently working with a Plugable DisplayLink usb hub/adaptor for adding 
multi-seat support to an embedded PC formfactor.

I've been running into difficulties with the changes to GDM and systemd with 
regards to multiseat support.

For GDM, I've patched it to do the following...
1) In daemon/gdm-display.c where it currently checks if the seat != seat0. 
Rather than doing "goto out;" immediately, it queries the username. If the 
username is utilising the script method then let the automated login proceed. 
The script method will parse the login name as a script path if it ends with | 
character.

2) In daemon/gdm-simple-slave.c, rather than using a global level 
GDM_RAN_ONCE_FILE_MARKER, create one per seat. This allows the 
wants_autologin() to return True on a another seat rather than drop through to 
simply start_greeter().

3) In daemon/gdm-slave.c, Export the GDM_SEAT_ID for the initial gdm slave 
display. This allows you to check the current seat in the script for item 1) 
above.

That solved my gdm automated login process on the different seats. I've emailed 
the patch to the gdm list.

However, I also ran into a problem with Xorg configurations. 

The host system runs on an embedded PC and has an xorg.conf.d Device entry for 
the Intel driver to enable certain options. However, this is global and caused 
problems with the displays on the other seats. e.g. with the second seat 
starting Xorg and looking for the Intel device as described in the xorg.conf.d 
file, rather than using the appropriate Frame-buffer device. I've patched the 
systemd/login/multi-seat-x.c to also pass over a -configdir parameter to the 
Xorg it launches. e.g '-configdir 
/etc/X11/xorg.conf.d/multi-session-x/seat-usb-pci-
_00_1d_7-usb-0_3_1_4'. I'm not entirely confident that's the correct path I 
should be using.

I've attached the patch for your comments/feedback.
Thanks in advance,
-- 
Glen Gray




multi-session-xorg-confdir.patch
Description: Binary data


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

Re: [systemd-devel] [PATCH] detect-virt: detect User-Mode Linux

[Lennart Poettering]

On Tue, 16.07.13 20:24, Ramkumar Ramachandra (artag...@gmail.com) wrote:

> 
> Lennart Poettering wrote:
> > /dev/tty0 only exists
> > on kernels with a VT subsystem
> 
> Yeah, but um Linux boots fine when I do
> 
>   $ mv
>   
> /etc/systemd/system/getty.target.wants/{getty@tty1.service,getty@tty0.service}

Bu that really just looks like a work-around around some weird bahaviour
of UML. I'd really prefer if UML could be fixed to either support a VC
or not support a VC, but please not "half support" it, by exposing
/dev/tty0 which is supposed to point to the foreground VC but in this
case actually points to some other place that isn't really clear what it
is.

Lennart

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

Re: [systemd-devel] [PATCH] console-getty.service: conflict with vconsole-setup

[Lennart Poettering]

On Tue, 16.07.13 20:19, Ramkumar Ramachandra (artag...@gmail.com) wrote:

> 
> Lennart Poettering wrote:
> > Similar story here. systemd-vconsole-setup is actually conditionalized
> > on ConditionPathExists=/dev/tty0, i.e. will only run on systems where
> > the VT is actually built into the kernel, and skipped on all others. If
> > UML has not useful VT I'd recommend compiling it out of the kernel.
> 
> A couple of questions:
> 
> 1. Doesn't /dev/tty0 correspond to the "current" terminal, whether
> it's a virtual console or /dev/console?  Or should /dev/tty0 only ever
> correspond to a virtual console, and is um Linux doing it wrong?
> Should this condition be changed to /dev/tty1?

/dev/tty0 always points to the foreground VC tty. Are you saying UML
provides /dev/tty0 but not /dev/tty1, /dev/tty2, ...? I am pretty sure
that UML should be fixed to provide neither or both, evertyhing else is
broken. 

Also the kernel docs on /dev/tty0 here:

https://www.kernel.org/doc/Documentation/devices.txt

> 2. What if I created /dev/tty0 using mknod?

We don't support that. There are only two ways how device nodes are
created these days: 

 A) by the kernel in devtmpfs/devpts/...
 B) by udev/kmod/tmpfiles based on the modalias data of kernel modules

(Well, and there's /dev/lp0 which is created without the modalias stuff
but that's just because nobody wants to fix that old parallel port
mess).

> I found this in Documentation/devices.txt, although I'm not sure what
> fb devices have to do with virtual consoles (there is no /dev/fb0 in
> um Linux though):
> 
>   /dev/tty0 is the device that should be used to access the system video
>   card on those architectures for which the frame buffer devices
>   (/dev/fb*) are not applicable. Do not use /dev/console
>   for this purpose.

/dev/console is an alias for the system console for whatever that
means. It could point to the VC system, and usually does, but it
frequently instead points to a serial TTY. /dev/tty0 however is always
the VC, and as the docs say if you have no fb device, then tty0 is how
you can access the video card -- and not /dev/console, as that might
point to a serial terminal.

Lennart

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

Re: [systemd-devel] update: udev keymaps are moving to hwdb

[Martin Pitt]

Kay Sievers [2013-07-16 16:25 +0200]:
> Committed it now. All the old udev keymap files are gone and only the hwdb 
> file:
>   http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-keyboard.hwdb
> is carrying all the data.

\o/

> Martin is looking into the missing USB Logitech maps at the moment.

I went through the original bug reports and usb.ids to salvage the
real product IDs, committed to
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=1b6bce89

That should cover most bits, other models need new bug reports now
(Logitech USB keyboards are a catastrophe..)

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] runtime directories for services vs. tmpfiles

[Lennart Poettering]

On Tue, 16.07.13 03:24, Michael Biebl (mbi...@gmail.com) wrote:

> Hi,
> 
> an interesting issue was raised as part of reviewing a patch for
> iodione [1], a system service which needs a runtime directory. We
> thought this might need further dicussion, so reposting the issue to
> systemd-devel:
> 
> For system services needing a runtime directory, we basically have two
> (three) options nowadays
> 1/ use ExecStartPre=/usr/bin/mkdir /var/run/foo
> 2/ use a tmpfile snippet
> (3/ let the daemon create the runtime directory itself)
> 
> In [1] we recommended the the usage of 2/ over 1/.
> The main reason for that were, that systemd-tmpfiles properly handles
> applying security policies, like SELinux labels, and it avoids
> spawning unnecessary processes (every ExecStartPre=/usr/bin/mkdir is a
> separate process)

I tend to agree with this.

> Zbyszek is arguing, that splitting the configuration over two files, a
> tmpfile and  a service file, complicates things for the administrator,
> as things are no longer in a single place.
> He also argues, that tmpfiles are active, independently of the
> service, which needs them. Which can lead to unused runtime
> directories.

I am not too concerned about unused runtime directories. After all this
is not something that would (or even could) grow without bounds. There
will never be more than O(n) runtime directores for n being the number
of packages you have installed (or had installed).

We will always need setting up of tmpfiles during boot, as many clients
expect certain directories to be existant in /run without any specific
daemon running. Thus, we couldn't move this stuff into service files ---
we could only allow both.

However, I am not convinced that allowing tmpfiles to be denoted in unit
files would be a good thing though, because it sounds unnecessary. It
really sounds as if the daemons which need that should rather create the
directories on their own before making use of them. This should
generally be the most robust solution. And in such a case there's no
need to denote anything about this in the unit files at all...

I mean, this is the general recommendation anyway: if possible just fix
the daemon to create the dirs as it needs it. Use tmpfiles only if
that's not feasible, maybe because the daemon never runs privileged code
or because the dirs need to exist at boot already.

Something I'd love to see though is if we could make it easier to apply
tmpfiles stuff automatically on package installation. More specifically,
I'd like an RPM macro to be added that handles this, and which is
sufficient for packagers to call for their tmpfiles. ALl in order to
ensure that the user can invoke the services right after package
installation without requiring a reboot.

> One suggestion that came up was, to specficy runtime directories in a
> declarative fashion in the .service file itself, which means it would
> be only be created if the service itself is enabled.

The way I see tmpfiles is that they don't actually do anything active,
they just reserve some space where something else then does something
active. It just sets up working areas, and doesn't actually play in
them. As such the impact, the cost of tmpfiles is minimal. It's like
installing a package and then not using it, i.e. you have stuff lying
around that is dead, but prepares everything for the time when you
actually want to run it, not more. If you want to get rid of the runtime
dirs (or the normal packaged files) you should just remove the package
in question...

I hope this makes some sense?

Lennart

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

Re: [systemd-devel] [PATCH] detect-virt: detect User-Mode Linux

[Ramkumar Ramachandra]

Lennart Poettering wrote:
> /dev/tty0 only exists
> on kernels with a VT subsystem

Yeah, but um Linux boots fine when I do

  $ mv 
/etc/systemd/system/getty.target.wants/{getty@tty1.service,getty@tty0.service}

I'm reading arch/um/drivers/tty.c, but I'm not sure I understand what
exactly is going on.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] console-getty.service: conflict with vconsole-setup

[Ramkumar Ramachandra]

Lennart Poettering wrote:
> Similar story here. systemd-vconsole-setup is actually conditionalized
> on ConditionPathExists=/dev/tty0, i.e. will only run on systems where
> the VT is actually built into the kernel, and skipped on all others. If
> UML has not useful VT I'd recommend compiling it out of the kernel.

A couple of questions:

1. Doesn't /dev/tty0 correspond to the "current" terminal, whether
it's a virtual console or /dev/console?  Or should /dev/tty0 only ever
correspond to a virtual console, and is um Linux doing it wrong?
Should this condition be changed to /dev/tty1?

2. What if I created /dev/tty0 using mknod?

I found this in Documentation/devices.txt, although I'm not sure what
fb devices have to do with virtual consoles (there is no /dev/fb0 in
um Linux though):

  /dev/tty0 is the device that should be used to access the system video
  card on those architectures for which the frame buffer devices
  (/dev/fb*) are not applicable. Do not use /dev/console
  for this purpose.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] test-tables failure

[Lennart Poettering]

On Tue, 16.07.13 14:57, Jan Janssen (medhe...@web.de) wrote:

> Hi,
> 
> test-tables fails on my system. The one it's failing on is:
> syscall: 222 → (null) → -1
> 
> syscall_max() tells me that I have 351 syscalls, so I guess
> there is a logic error in the test case?
> 
> This is on a pretty old x86 machine.

Hmm, on your system do you have a syscall 222 defined anywhere in
sys/syscall.h (or any of the headers that pulls in)?

Lennart

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

Re: [systemd-devel] [PATCH] configure: add -Wno-cast-align to CFLAGS

[Lennart Poettering]

On Mon, 15.07.13 19:55, Shawn (shawnland...@gmail.com) wrote:

> On Mon, Jul 15, 2013 at 7:26 PM, Lennart Poettering
> wrote:
> 
> > On Mon, 15.07.13 18:22, Shawn Landden (shawnland...@gmail.com) wrote:
> >
> > > these warnings on !x86 arches for good code are annoying, and
> > > there is no way to mark the offending code safe, so I guess we are
> > > just going to have to deal with the resulting problems as we
> > > come across them. Also, these warnings are present for armv6+armv7,
> > > when they moreso effect armv5.
> >
> > Hmm, can you elaborate on the particular places where this happens? I
> > have not been aware of any issues regarding this (not surprising since I
> > am a boring x86 user...)
> >
> Here is the full build log on armhf. I looked at the source for some of
> these about a year ago, after the udev merge. Basically, you allocate
> some type to 1-byte aligned, and then you cast it to a type that requries
> 4-bytes aligned, and on arches that do
> not support unaligned accesses, Bad Things (tm) happen. I ran systemd on
> armv5 for quite some time and never had problems, however, but fewer people
> are probably testing that now. (I don't have the hardware anymore)

Hmm, malloc() is guaranteed to pointers that are aligned to the maximum
alignment, so that part should safe.

I figure most of these gcc warnings are indeed non-issues, but I am
pretty sure we should individually fix or suppress them rather than just
turn off the warnings globally.

Usually issues like these can be fixed by replacing casts by unions, or
by decorating variables with alignment attributes. I am not sure what
the official way is to tell the compiler that a specific cast is
verified to be OK and that the compiler should shut up about it
though...

Lennart

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

Re: [systemd-devel] [PATCH] console-getty.service: conflict with vconsole-setup

[Lennart Poettering]

On Tue, 16.07.13 18:51, Ramkumar Ramachandra (artag...@gmail.com) wrote:

> system-vconsole-setup.service runs systemd-vconsole-setup to set up
> virtual consoles, but console-getty.service implies that virtual
> consoles aren't present, and that we're falling back to /dev/console.

Similar story here. systemd-vconsole-setup is actually conditionalized
on ConditionPathExists=/dev/tty0, i.e. will only run on systems where
the VT is actually built into the kernel, and skipped on all others. If
UML has not useful VT I'd recommend compiling it out of the kernel.

Lennart

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

Re: [systemd-devel] [PATCH] detect-virt: detect User-Mode Linux

[Lennart Poettering]

On Tue, 16.07.13 18:28, Ramkumar Ramachandra (artag...@gmail.com) wrote:

> 
> Ramkumar Ramachandra wrote:
> >  It seems that UM does not have a proper tty system; I force
> >  systemd to use the /dev/console by doing:
> >
> >  $ mv 
> > /etc/systemd/system/getty.target.wants/{getty@tty1.service,getty@console.service}
> 
> Where should the exception for um linux go?  When does the code in
> getty-generator get executed exactly (installation?).  The same rootfs
> can be used in a chroot, or with a vm, so I think the override should
> be done at runtime.  There's already an exception for containers: when
> detect_container(), install console-getty.service.  Should we add one
> for detect_virtualization() when id = "uml"?
> 
> Also, um linux does not seem to respect the console=tty0 kernel
> parameter (or I'm missing something).

Generators are run at early boot time. Note however that the
getty@tty1.service symlink is not controlled by generators, it is instead
generated at installation time.

Note that getty@.service is conditionalized on
"ConditionPathExists=/dev/tty0", which is a used as a check whether the
VT subsystem is compiled into the kernel or not. (/dev/tty0 only exists
on kernels with a VT subsystem)

How is UML actually set up? You have a VT subsystem, but you don't want
to use it? If so, may I recommend to disable the VT subsystem at
build-time? That sounds like a much better approach.

Lennart

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

Re: [systemd-devel] update: udev keymaps are moving to hwdb

[Kay Sievers]

On Fri, Jul 12, 2013 at 12:39 PM, Kay Sievers  wrote:
> On Wed, Jul 10, 2013 at 11:38 PM, Kay Sievers  wrote:
>
>> The systemd git source tree has now all the pieces to prepare the move
>> from the current keymap handling to the hardware database. None of it
>> will take any action at the moment, the hwdb file is not committed.
>
> The hand-edited:
>   /usr/lib/udev/hwdb.d/60-keyboard.hwdb
>
> is in the systemd source tree now:
>   http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-keyboard.hwdb?
>
> It should contain almost all data from the keymaps. The Logitech too
> broad matches for USB devices, which use the textual string instead of
> the usual USB IDs have been dropped, they need to be resurrected when
> someone can supply the USB IDs.

Committed it now. All the old udev keymap files are gone and only the hwdb file:
  http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-keyboard.hwdb
is carrying all the data.

Martin is looking into the missing USB Logitech maps at the moment.

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

[systemd-devel] [PATCH] console-getty.service: conflict with vconsole-setup

[Ramkumar Ramachandra]

system-vconsole-setup.service runs systemd-vconsole-setup to set up
virtual consoles, but console-getty.service implies that virtual
consoles aren't present, and that we're falling back to /dev/console.

Cc: Lennart Poettering 
Signed-off-by: Ramkumar Ramachandra 
---
 Noticed on um linux.  Tested.

 units/console-getty.service.m4.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/units/console-getty.service.m4.in 
b/units/console-getty.service.m4.in
index 0426050..95d8b7c 100644
--- a/units/console-getty.service.m4.in
+++ b/units/console-getty.service.m4.in
@@ -13,6 +13,7 @@ m4_ifdef(`HAVE_SYSV_COMPAT',
 After=rc-local.service
 )m4_dnl
 Before=getty.target
+Conflicts=systemd-vconsole-setup.service
 
 [Service]
 ExecStart=-/sbin/agetty --noclear -s console 115200,38400,9600
-- 
1.8.3.3.754.g9c3c367

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

Re: [systemd-devel] [PATCH] detect-virt: detect User-Mode Linux

[Thomas Bächler]

Am 16.07.2013 14:58, schrieb Ramkumar Ramachandra:
> Ramkumar Ramachandra wrote:
>>  It seems that UM does not have a proper tty system; I force
>>  systemd to use the /dev/console by doing:
>>
>>  $ mv 
>> /etc/systemd/system/getty.target.wants/{getty@tty1.service,getty@console.service}
> 
> Where should the exception for um linux go?  When does the code in
> getty-generator get executed exactly (installation?).

The getty@tty1.service is symlinked during package installation only.
Since UM doesn't have a working tty1, that service remains unused and
could be disabled on UM.

This is not generated from getty-generator.

> The same rootfs
> can be used in a chroot, or with a vm, so I think the override should
> be done at runtime.  There's already an exception for containers: when
> detect_container(), install console-getty.service.  Should we add one
> for detect_virtualization() when id = "uml"?

IMO that's a good idea since UML behaves more like a container than a VM
in this context. This would probably make UML work out of the box.




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] detect-virt: detect User-Mode Linux

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
>  It seems that UM does not have a proper tty system; I force
>  systemd to use the /dev/console by doing:
>
>  $ mv 
> /etc/systemd/system/getty.target.wants/{getty@tty1.service,getty@console.service}

Where should the exception for um linux go?  When does the code in
getty-generator get executed exactly (installation?).  The same rootfs
can be used in a chroot, or with a vm, so I think the override should
be done at runtime.  There's already an exception for containers: when
detect_container(), install console-getty.service.  Should we add one
for detect_virtualization() when id = "uml"?

Also, um linux does not seem to respect the console=tty0 kernel
parameter (or I'm missing something).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] test-tables failure

[Jan Janssen]

Hi,

test-tables fails on my system. The one it's failing on is:
syscall: 222 → (null) → -1

syscall_max() tells me that I have 351 syscalls, so I guess
there is a logic error in the test case?

This is on a pretty old x86 machine.

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

Re: [systemd-devel] [PATCH v3] detect-virt: detect User-Mode Linux

[Lennart Poettering]

On Tue, 16.07.13 16:44, Ramkumar Ramachandra (artag...@gmail.com) wrote:

> In a User-Mode Linux session:
> 
>   $ systemd-detect-virt
>   none
> 
> Although it is possible to reliably detect virtualization:
> 
>   $ cat /proc/cpuinfo
>   processor   : 0
>   vendor_id   : User Mode Linux
>   model name  : UML
>   mode: skas
>   host: Linux kytes 3.11.0-rc1-9-ge5fd680 (...)
>   bogomips: 7007.43
> 
> So, grep for the string "\nvendor_id\t: User Mode Linux\n" in
> /proc/cpuinfo, and say "uml" when asked.

Thanks! Applied!

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Tom Gundersen]

Hi Michael,

On Tue, Jul 16, 2013 at 3:24 AM, Michael Biebl  wrote:
> an interesting issue was raised as part of reviewing a patch for
> iodione [1], a system service which needs a runtime directory. We
> thought this might need further dicussion, so reposting the issue to
> systemd-devel:
>
> For system services needing a runtime directory, we basically have two
> (three) options nowadays
> 1/ use ExecStartPre=/usr/bin/mkdir /var/run/foo
> 2/ use a tmpfile snippet
> (3/ let the daemon create the runtime directory itself)
>
> In [1] we recommended the the usage of 1/ over 2/.
> The main reason for that were, that systemd-tmpfiles properly handles
> applying security policies, like SELinux labels, and it avoids
> spawning unnecessary processes (every ExecStartPre=/usr/bin/mkdir is a
> separate process)

I think the current way of doing this (letting tmpfiles or the daemon
itself handle it) is for the best, for the reasons you mention. Also
because it means we only have one tool to create folders during early
boot.

> Zbyszek is arguing, that splitting the configuration over two files, a
> tmpfile and  a service file, complicates things for the administrator,
> as things are no longer in a single place.

Hm, that is a fair point, but we also have the dual argument: if we
add a new place to configure runtime dirs without removing the old
(which I suppose we can't), the admin will anyway have to look in both
places to figure out what is going on...

> He also argues, that tmpfiles are active, independently of the
> service, which needs them. Which can lead to unused runtime
> directories.

I suppose the concern here is speed? If it can be shown that there is
a real speed advantage of not creating unneeded directories I guess
that's something worth discussing (I must admit that would surprise me
though).

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

Re: [systemd-devel] Unbuffered stderr for my systemd service?

[Kay Sievers]

On Tue, Jul 16, 2013 at 5:30 AM, WANG Chao  wrote:
> On 07/15/13 at 10:46pm, Lennart Poettering wrote:
>> On Mon, 15.07.13 17:56, WANG Chao (chaow...@redhat.com) wrote:
>>
>> > I have a service (a script) running under systemd and need its stderr to
>> > be output'd immediately, not line buffered. I tried serveral ways but
>> > didn't work out. I hope to get some feedback here :)
>>
>> This is not supported. Logging doesn't deal in individual
>> characters, really, but in log lines. Syslog doesn't do that, and
>> neither does the Journal.
>>
>> And we will never support that, as allowing this would require us to
>> always store the context a character was printed in so that lines could
>> later be reassembled. But we cannot really do that.
>>
>> So, I fear I have to tell you that this is not supported and never
>> will...
>
> I understand that. Record the context of a character is printed would
> never be a good idea. But still, I feel pity about line buffered stderr
> stream in Journal :(

It is the right thing to buffer just buffer them to full lines.

For the kernel counterpart, we added unbuffered console magic to the
kernel. It is really nasty and broken hack and really makes not much
sense in th eend. The code does work in the most common case, but just
does stupid things as soon as things start to compete about the log.

 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=084681d14e429cb6192262ac7437f00e2c02f26a
 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eab072609e11a357181806ab5a5c309ef6eb76f5

Pretending to support pushing "animations" through a log system is a
pretty bad idea and relies on technical promises nobody can really
hold without inventing something that isn't logging anymore. But we
have that already, it's the console. :)

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

Re: [systemd-devel] Unbuffered stderr for my systemd service?

[Kay Sievers]

On Tue, Jul 16, 2013 at 5:30 AM, WANG Chao  wrote:

>> (Humm, please do not use "--" on a single line in the middle of an
>> email, that's indication for many MUAs that this is where the signature
>> starts, and they chop this off when replying...)
>
> Sorry about "--", never thought that would be an issue. Thanks for
> telling!

It would only happen on _really_ broken mail programs, because the
convention includes a trailing space character which you didn't add.
The delimiter line is defined as "-- ".

  http://tools.ietf.org/html/rfc3676#section-4.3

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

[systemd-devel] [PATCH v3] detect-virt: detect User-Mode Linux

[Ramkumar Ramachandra]

In a User-Mode Linux session:

  $ systemd-detect-virt
  none

Although it is possible to reliably detect virtualization:

  $ cat /proc/cpuinfo
  processor   : 0
  vendor_id   : User Mode Linux
  model name  : UML
  mode: skas
  host: Linux kytes 3.11.0-rc1-9-ge5fd680 (...)
  bogomips: 7007.43

So, grep for the string "\nvendor_id\t: User Mode Linux\n" in
/proc/cpuinfo, and say "uml" when asked.

Cc: Lennart Poettering 
Signed-off-by: Ramkumar Ramachandra 
---
 Minor tweaks suggested by Lennart.  Tested.

 man/systemd-detect-virt.xml |  1 +
 man/systemd.unit.xml|  1 +
 src/shared/virt.c   | 11 +++
 3 files changed, 13 insertions(+)

diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml
index 762b6ab..f21493df 100644
--- a/man/systemd-detect-virt.xml
+++ b/man/systemd-detect-virt.xml
@@ -70,6 +70,7 @@
 microsoft,
 oracle, xen,
 bochs, chroot,
+uml,
 openvz, lxc,
 lxc-libvirt,
 systemd-nspawn.
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index a14e452..f45632a 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -969,6 +969,7 @@
 xen,
 bochs,
 chroot,
+uml,
 openvz,
 lxc,
 lxc-libvirt,
diff --git a/src/shared/virt.c b/src/shared/virt.c
index 1c86a3d..1abd686 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -67,6 +67,7 @@ int detect_vm(const char **id) {
 const char *j, *k;
 bool hypervisor;
 _cleanup_free_ char *hvtype = NULL;
+_cleanup_free_ char *cpuinfo_contents = NULL;
 int r;
 
 /* Try high-level hypervisor sysfs file first:
@@ -164,6 +165,16 @@ int detect_vm(const char **id) {
 }
 
 #endif
+
+/* Detect User-Mode Linux by reading /proc/cpuinfo */
+r = read_full_file("/proc/cpuinfo", &cpuinfo_contents, NULL);
+if (r < 0)
+return r;
+if (strstr(cpuinfo_contents, "\nvendor_id\t: User Mode Linux\n")) {
+*id = "uml";
+return 1;
+}
+
 return 0;
 }
 
-- 
1.8.3.3.754.g9c3c367

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

Re: [systemd-devel] [PATCH v2] detect-virt: detect User-Mode Linux

[Lennart Poettering]

On Tue, 16.07.13 12:50, Ramkumar Ramachandra (artag...@gmail.com) wrote:

> --- a/man/systemd-detect-virt.xml
> +++ b/man/systemd-detect-virt.xml
> @@ -70,6 +70,7 @@
>  microsoft,
>  oracle, xen,
>  bochs, chroot,
> +uml,
>  openvz, lxc,
>  lxc-libvirt,
>  systemd-nspawn.

Please also update the docs in systemd.unit(5), for ConditionVirtualization.

> +r = read_full_file("/proc/cpuinfo", &cpuinfo_contents, NULL);
> +if (r < 0)
> +return r;
> +if (strstr(cpuinfo_contents, "vendor_id\t: User Mode Linux\n")) {
> +*id = "uml";
> +return 1;
> +}

Could you also look for the \n before the line? I'd really like to make
sure this detects this on a separate line only:

   strstr(cpuinfo_contents, "\nvendor_id\t: User Mode Linux\n")

(I'd just make the change myself and commit it, but I don't want to
commit this without testing, and I have no UML machine around, so I can
test this.)

Lennart

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

Re: [systemd-devel] runtime directories for services vs. tmpfiles

[Colin Guthrie]

'Twas brillig, and Michael Biebl at 16/07/13 02:24 did gyre and gimble:
> Hi,
> 
> an interesting issue was raised as part of reviewing a patch for
> iodione [1], a system service which needs a runtime directory. We
> thought this might need further dicussion, so reposting the issue to
> systemd-devel:
> 
> For system services needing a runtime directory, we basically have two
> (three) options nowadays
> 1/ use ExecStartPre=/usr/bin/mkdir /var/run/foo
> 2/ use a tmpfile snippet
> (3/ let the daemon create the runtime directory itself)
> 
> In [1] we recommended the the usage of 2/ over 1/.
> The main reason for that were, that systemd-tmpfiles properly handles
> applying security policies, like SELinux labels, and it avoids
> spawning unnecessary processes (every ExecStartPre=/usr/bin/mkdir is a
> separate process)
> 
> Zbyszek is arguing, that splitting the configuration over two files, a
> tmpfile and  a service file, complicates things for the administrator,
> as things are no longer in a single place.
> He also argues, that tmpfiles are active, independently of the
> service, which needs them. Which can lead to unused runtime
> directories.
> 
> One suggestion that came up was, to specficy runtime directories in a
> declarative fashion in the .service file itself, which means it would
> be only be created if the service itself is enabled.
> 
> I think this idea warrants further discussion, so I'm posting it here.

Hmmm, I can certainly see the argument, but it would be a shame to have
multiple ways to achieve the same goal through different places too (it
makes the documentation case much more confusing).

There is also an argument that on first install, one has to call
"systemd-tmpfiles --create $BASENAME" in a %post script to ensure the
necessary dirs are created. If it was all "built in" to the service this
would be fine.

So I see a few options.

1. Bake it into systemd unit syntax and handle it internally.
2. Bake it in as a noop directive and have a generator parse it out and
then write out /run/tmpfiles.d/ snippets and let systemd-tmpfiles work
with that.
3. Keep the status quo.

I don't really like option 2 there - seems unnecessary overhead. But
then option one (which presumably would see the tmpfiles code being
libified and linked to from systemd itself) doesn't seem amazing too.

I guess I don't really have a major problem with either 1 or 3 to be
honest. I can see arguments for both.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
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

[systemd-devel] [PATCH] man: improve readability of --output options in journalctl(1)

[Jason St. John]

From: "Jason St. John" 

The list and descriptions of valid output options was difficult to read,
so break up the long block of text into discrete man page list items to
improve readability.
---
 man/journalctl.xml| 166 --
 man/systemd.scope.xml |   2 +-
 2 files changed, 120 insertions(+), 48 deletions(-)

diff --git a/man/journalctl.xml b/man/journalctl.xml
index 71b1bab..9cabda5 100644
--- a/man/journalctl.xml
+++ b/man/journalctl.xml
@@ -219,53 +219,125 @@
 
 Controls the
 formatting of the journal entries that
-are shown. Takes one of
-short,
-short-monotonic,
-verbose,
-export,
-json,
-json-pretty,
-json-sse,
-cat. 
short
-is the default and generates an output
-that is mostly identical to the
-formatting of classic syslog
-files, showing one line per journal
-entry. short-monotonic
-is very similar but shows monotonic
-timestamps instead of wallclock
-timestamps. verbose
-shows the full structured entry items
-with all
-fields. export
-serializes the journal into a binary
-(but mostly text-based) stream
-suitable for backups and network
-transfer (see http://www.freedesktop.org/wiki/Software/systemd/export";>Journal
-Export Format for more
-information). json
-formats entries as JSON data
-structures, one per
-line (see http://www.freedesktop.org/wiki/Software/systemd/json";>Journal
-JSON Format for more
-information). json-pretty
-also formats entries as JSON data
-structures, but formats them in
-multiple lines in order to make them
-more readable for
-humans. json-sse
-also formats entries as JSON data
-structures, but wraps them in a format
-suitable for https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events";>Server-Sent
-Events. cat
-generates a very terse output only
-showing the actual message of each
-journal entry with no meta data, not
-even a timestamp.
+are shown. Takes one of the following options:
+
+
+
+
+short
+
+
+is the default
+and generates an output
+that is mostly 
identical
+to the formatting of
+classic syslog files,
+showing one line per
+journal entry.
+
+
+
+
+
+
short-monotonic
+
+
+is very similar
+but shows monotonic
+timestamps instead of
+wallclock timestamps.
+   

[systemd-devel] [PATCH] man: use HTTPS links for links that support it

[Jason St. John]

From: "Jason St. John" 

---
 man/binfmt.d.xml   |  2 +-
 man/journald.conf.xml  |  2 +-
 man/machine-id.xml |  2 +-
 man/os-release.xml |  2 +-
 man/sd-id128.xml   |  2 +-
 man/systemd.cgroup.xml | 20 ++--
 man/systemd.exec.xml   |  6 +++---
 man/systemd.xml|  2 +-
 8 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml
index 7f31b76..f4f4195 100644
--- a/man/binfmt.d.xml
+++ b/man/binfmt.d.xml
@@ -67,7 +67,7 @@
 
 Each file contains a list of binfmt_misc kernel
 binary format rules. Consult http://www.kernel.org/doc/Documentation/binfmt_misc.txt";>binfmt_misc.txt
+
url="https://www.kernel.org/doc/Documentation/binfmt_misc.txt";>binfmt_misc.txt
 for more information on registration of additional
 binary formats and how to write rules.
 
diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index 5986d61..487e8d6 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -133,7 +133,7 @@
 command), forward secure sealing (FSS)
 for all persistent journal files is
 enabled. FSS is based on http://eprint.iacr.org/2013/397";>Seekable
+url="https://eprint.iacr.org/2013/397";>Seekable
 Sequential Key Generators by
 G. A. Marson and B. Poettering and
 may be used to protect journal files
diff --git a/man/machine-id.xml b/man/machine-id.xml
index b037e47..4b4759e 100644
--- a/man/machine-id.xml
+++ b/man/machine-id.xml
@@ -93,7 +93,7 @@
 
 Note that the machine ID historically is not an
 OSF UUID as defined by http://tools.ietf.org/html/rfc4122";>RFC
+url="https://tools.ietf.org/html/rfc4122";>RFC
 4122, nor a Microsoft GUID; however, starting with
 systemd v30, newly generated machine IDs do
 qualify as v4 UUIDs.
diff --git a/man/os-release.xml b/man/os-release.xml
index d714b51..045dd08 100644
--- a/man/os-release.xml
+++ b/man/os-release.xml
@@ -241,7 +241,7 @@
 
 A CPE name for the
 operating system, following the http://cpe.mitre.org/specification/";>Common
+
url="https://cpe.mitre.org/specification/";>Common
 Platform Enumeration
 Specification as proposed by
 the MITRE Corporation. This field
diff --git a/man/sd-id128.xml b/man/sd-id128.xml
index 02fb76b..3a5e133 100644
--- a/man/sd-id128.xml
+++ b/man/sd-id128.xml
@@ -71,7 +71,7 @@
 process and generate 128-bit ID values. The 128-bit ID
 values processed and generated by these APIs are a
 generalization of OSF UUIDs as defined by http://tools.ietf.org/html/rfc4122";>RFC
+url="https://tools.ietf.org/html/rfc4122";>RFC
 4122 but use a simpler string
 format. These functions impose no structure on the
 used IDs, much unlike OSF UUIDs or Microsoft GUIDs,
diff --git a/man/systemd.cgroup.xml b/man/systemd.cgroup.xml
index e31faf5..bb0cb1c 100644
--- a/man/systemd.cgroup.xml
+++ b/man/systemd.cgroup.xml
@@ -127,7 +127,7 @@ along with systemd; If not, see 
.
   controls the cpu.shares control group
   attribute, which defaults to 1024. For details about this
   control group attribute, see http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt";>sched-design-CFS.txt.
+  
url="https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt";>sched-design-CFS.txt.
 
   Implies CPUAccounting=true.
 
@@ -152,7 +152,7 @@ along with systemd; If not, see 
.
   memory.soft_limit_in_bytes control group
   attributes. For details about these control group attributes,
   see http://www.kernel.org/doc/Documentation/cgroups/memory.txt";>memory.txt.
+  
url="https://www.kernel.org/doc/Documentation/cgroups/memory.txt";>memory.txt.
 
   Implies MemoryAccounting=true.
 
@@ -172,7 +172,7 @@ along with systemd; If not, see 
.
 defaults to 1000. For details about
 this control group attribute, see
 http://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt";>blkio-controller.txt.
+
url="https://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt";>blkio-controller.txt.
   
 
   
@@ -191,7 +191,7 @@ along with systemd; If not, see 
.
   attribute, which defaults to 1000. Use this option mul

[systemd-devel] [PATCH v2] detect-virt: detect User-Mode Linux

[Ramkumar Ramachandra]

In a User-Mode Linux session:

  $ systemd-detect-virt
  none

Although it is possible to reliably detect virtualization:

  $ cat /proc/cpuinfo
  processor   : 0
  vendor_id   : User Mode Linux
  model name  : UML
  mode: skas
  host: Linux kytes 3.11.0-rc1-9-ge5fd680 (...)
  bogomips: 7007.43

So, grep for the string "vendor_id\t: User Mode Linux\n" in
/proc/cpuinfo, and say "uml" when asked.

Cc: Lennart Poettering 
Signed-off-by: Ramkumar Ramachandra 
---
 See arch/um/kernel/um_arch.c:75, where it writes the hard-coded
 string "vendor_id\t: User Mode Linux\n".  No variable-width padding,
 so it should be safe to grep for this exact string.

 Also tweaked documentation.

 man/systemd-detect-virt.xml |  1 +
 src/shared/virt.c   | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml
index 762b6ab..f21493df 100644
--- a/man/systemd-detect-virt.xml
+++ b/man/systemd-detect-virt.xml
@@ -70,6 +70,7 @@
 microsoft,
 oracle, xen,
 bochs, chroot,
+uml,
 openvz, lxc,
 lxc-libvirt,
 systemd-nspawn.
diff --git a/src/shared/virt.c b/src/shared/virt.c
index 1c86a3d..6114b6c 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -67,6 +67,7 @@ int detect_vm(const char **id) {
 const char *j, *k;
 bool hypervisor;
 _cleanup_free_ char *hvtype = NULL;
+_cleanup_free_ char *cpuinfo_contents = NULL;
 int r;
 
 /* Try high-level hypervisor sysfs file first:
@@ -164,6 +165,16 @@ int detect_vm(const char **id) {
 }
 
 #endif
+
+/* Detect User-Mode Linux by reading /proc/cpuinfo */
+r = read_full_file("/proc/cpuinfo", &cpuinfo_contents, NULL);
+if (r < 0)
+return r;
+if (strstr(cpuinfo_contents, "vendor_id\t: User Mode Linux\n")) {
+*id = "uml";
+return 1;
+}
+
 return 0;
 }
 
-- 
1.8.3.2.736.g869de25

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