Re: [systemd-devel] SyslogIdentifier does not work for messages printed with sd_journal_print
On Tue, 02.06.15 20:31, Martin Belanger (martin.belan...@cyaninc.com) wrote: I'm using systemd 219 (Ubuntu 15.04). I have three instances of a daemon running. I use SyslogIdentifier to give each of them a unique identifier (e.g. myproc-1, myproc-2, myproc-3). I also redirect stdout/stderr to the journal using StandardOutput=journal and StandardError=journal. I noticed that messages sent to the journal with printf (i.e. stdout) get the proper SYSLOG_IDENTIFIER. However, messages send to the journal with sd_journal_print() get the default SYSLOG_IDENTIFIER (i.e. the process name). I also tried sd_journal_send() and get the same result. Any thoughts as to why this is happening? SyslogIdentifier only really applies to stdout/stderr messages, not to native journal messages, which will not carry that id at all. The only reason the setting exists is because it's useful to set something there because stdout/stderr doesn't carry enough information for this, and because the same stdout/stderr stream can be shared among multiple processes it's difficult and misleading to automatically derive the identifier from them... Hence: I'd really prefer fi we didn't have that option at all, we justed added it, because it was difficult to do without... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] In what case will debugfs be mounted multi-times?
On Thu, 04.06.15 23:41, cee1 (fykc...@gmail.com) wrote: Hi all, I'm running systemd v219 on a ARM board, and find following suspicious log message: Jan 01 08:00:01 localhost unknown: c3 1 (systemd) systemd[1]: Mounting Debug File System... Jan 01 08:00:01 localhost unknown: c3 1 (systemd) systemd[1]: Starting Remount Root and Kernel File Systems... Jan 01 08:00:01 localhost unknown: c3 1 (systemd) systemd[1]: Starting Foo Service... Jan 01 08:00:01 localhost unknown: c3 1 (systemd) systemd[1]: Mounted Debug File System. Jan 01 08:00:01 localhost systemd[1]: foo.service: main process exited, code=exited, status=127/n/a Jan 01 08:00:02 localhost systemd[1]: foo.service holdoff time over, scheduling restart. Jan 01 08:00:02 localhost systemd[1]: Started Remount Root and Kernel File Systems. Jan 01 08:00:02 localhost systemd[1]: Reached target Local File Systems (Pre). Jan 01 08:00:02 localhost systemd[1]: Starting Local File Systems (Pre). Jan 01 08:00:02 localhost systemd[1]: sys-kernel-debug.mount: Directory /sys/kernel/debug to mount over is not empty, mounting anyway. Jan 01 08:00:02 localhost systemd[1]: Mounting Debug File System... Jan 01 08:00:02 localhost systemd[1]: sys-kernel-debug.mount mount process exited, code=exited status=32 Jan 01 08:00:02 localhost systemd[1]: Failed to mount Debug File System. foo.service is a service with DefaultDependencies=no and Conflicts and Before shutdown.target So why the Debug File System is mounted multi-times here? Any idea? Hmm, my suspicion is that the file system might actually already be mounted by the kernel the second time we look at it, but systemd is doesn't notice that or so. Is it possible that your kernel has been built without name_to_handle_at() or so? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 06/09/2015 11:02 AM, Lennart Poettering wrote: On Mon, 01.06.15 22:43, Michael Biebl (mbi...@gmail.com) wrote: 2015-06-01 20:12 GMT+02:00 David Herrmann dh.herrm...@gmail.com: Hi As of today we've disabled git-push to fd.o. The official development git repository is now at github [1]. What about the bug tracker? Will it remain at fdo's bugzilla. I have to admit I'm not a huge fan of github's bug tracker. I am not a fan of bz either... I think for now we prefer github, but will leave bz open, and we will not migrate bugs. I would like to see us move and migrated the bugs to jira ( which is without doubt the best and friendliest bug tracker I have found ) which integrates nicely with github as well as move the community wiki to confluence to strengthen collaboration in the community. I had secured the systemd.community domain for just that work a while back and I have been working on it in my spare time to design and implement workflows for that in Jira. I would be the one that would overseeing and handling the migration and I was hoping David Strauss might be willing to host that infrastructure for us and or some other place for that matter ( mini pc in systemd's HQ in German maybe ?) I had plans on discussing all of this at one of the hackfest but due to lack of time and money I have been stuck on this rock here on top of the world. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nss-myhostname: why don't loopback interfaces appear?
On Wed, 03.06.15 16:31, Daurnimator (q...@daurnimator.com) wrote: On 3 June 2015 at 16:01, Lennart Poettering lenn...@poettering.net wrote: On Wed, 03.06.15 15:40, Daurnimator (q...@daurnimator.com) wrote: I was playing around with nss, and found that my loopback interface ip doesn't appear from nss-myhostname. Rather, my other ones do. Furthermore, unless I request IPv4, link-local IPv6 addresses are returned. Is this expected? We order the returned addresses by scope. Global addresses are placed first, local ones last. Then why are link local IPv6 addresses returned first? If this was the case, I would expect to see: 192.168.2.229 192.168.2.21 fe80::aed1:b8ff:fec0:d113 fe80::9eeb:e8ff:fe1b:f42d 127.0.0.1 ::1 Currently the first ordering key is the address family (ipv4 before ipv6), the second ordering key is the scope (global before link-local). Are you suggesting we should turn this around, and sort by scope first, and by address family then? I might be open to such a change. We return addresses on the loopback device only when there's no other address known. What's the rationale for this? (i.e. why not always just include 127.0.0.1 and ::1 last?) Because they are an implementation detail I think. If something wants to know the local IP address, then returning that information is really useless... 127.0.0.x is really an address we should never present to the user ever, unless there#s no better way... I mean, I am pretty sure I could explain a non-technical person off the streat what an IP address is, but I am pretty sure I'd had quite some trouble explaining what the purpose of 127.0.0.1 is on top of that... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] random-util: guard including sys/auxv.h with the corresponding ifdef check
On Tue, 02.06.15 11:07, Michael Olbrich (m.olbr...@pengutronix.de) wrote: --- src/shared/random-util.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/shared/random-util.c b/src/shared/random-util.c index 88f5182508e7..b230044f5099 100644 --- a/src/shared/random-util.c +++ b/src/shared/random-util.c @@ -23,7 +23,9 @@ #include sys/stat.h #include fcntl.h #include time.h +#ifdef HAVE_SYS_AUXV_H #include sys/auxv.h +#endif #include linux/random.h #include random-util.h For the sake of the archives: This was merged as https://github.com/systemd/systemd/pull/8. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] zsh-completion: a more style/tag aware _systemctl
On Fri, 29.05.15 10:40, Eric Cook (l...@gmx.com) wrote:
using _wanted instead of calling compadd directly. this allows the user to
customize
possible matches.
An example being, grouping units by type:
autoload -Uz compinit; compinit
zstyle ':completion:*' menu select
zstyle ':completion:*' group-name ''
zstyle ':completion:*' format 'Completing %d'
zstyle -e
':completion:*:*:systemctl-(((re|)en|dis)able|(*re|)start|reload*):*' \
tag-order 'local type; for type in service template target socket;
reply+=( systemd-units:-${type}:${type} ); reply=( $reply
systemd-units:-misc:misc )'
zstyle ':completion:*:systemd-units-template' ignored-patterns '^*@'
zstyle ':completion:*:systemd-units-target' ignored-patterns '^*.target'
zstyle ':completion:*:systemd-units-socket' ignored-patterns '^*.socket'
zstyle ':completion:*:systemd-units-service' ignored-patterns '^*.service'
zstyle ':completion:*:systemd-units-misc' ignored-patterns
'*(@|.(service|socket|target))'
For the sake of the archives. This was merged as:
https://github.com/systemd/systemd/pull/5
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Is SystemCallFilter working for you?
Hello all, I was about to (re-)enable seccomp support in our systemd packages, and to write an integration test for it. However, it seems that this currently does not seem to work at all. config.h has HAVE_SECCOMP==1, and systemctl --version shows +SECCOMP, kernel has CONFIG_SECCOMP=y, CONFIG_HAVE_ARCH_SECCOMP_FILTER=y, and CONFIG_SECCOMP_FILTER=y, and I'm running on x86-64, so that all seems fine. But if I have a unit like | [Unit] | Description=seccomp test | | [Service] | ExecStart=/bin/cat /etc/machine-id | SystemCallFilter=access (which really ought to fail) it just succeeds. Also, running ./test-execute as root fails in test_exec_systemcallfilter(): | exec-systemcallfilter-failing.service | UMask: 0022 | WorkingDirectory: /home/martin | RootDirectory: / | NonBlocking: no | PrivateTmp: no | PrivateNetwork: no | PrivateDevices: no | ProtectHome: no | ProtectSystem: no | IgnoreSIGPIPE: yes | StandardInput: null | StandardOutput: inherit | StandardError: inherit | This should not be seen | PID: 16439 | Start Timestamp: Tue 2015-06-09 12:56:51 CEST | Exit Timestamp: Tue 2015-06-09 12:56:51 CEST | Exit Code: exited | Exit Status: 0 | Assertion 'service-main_exec_status.status == status_expected' failed at src/test/test-execute.c:57, function check(). Aborting. This is with libseccomp 2.2.1, I tested kernel 3.19 and 4.0. Is that working for anyone else? In particular, could you check if you have HAVE_SECCOMP and test-execute succeeds (as root) for you? 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] [ANNOUNCE] Git development moved to github
On 06/09/2015 02:30 PM, Jóhann B. Guðmundsson wrote: As of today we've disabled git-push to fd.o. The official development git repository is now at github [1]. What about the bug tracker? Will it remain at fdo's bugzilla. I have to admit I'm not a huge fan of github's bug tracker. I am not a fan of bz either... I think for now we prefer github, but will leave bz open, and we will not migrate bugs. I would like to see us move and migrated the bugs to jira ( which is without doubt the best and friendliest bug tracker I have found ) which integrates nicely with github as well as move the community wiki to confluence to strengthen collaboration in the community. I use Jira everyday but it will be overkill for our use. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Mon, 01.06.15 22:43, Michael Biebl (mbi...@gmail.com) wrote: 2015-06-01 20:12 GMT+02:00 David Herrmann dh.herrm...@gmail.com: Hi As of today we've disabled git-push to fd.o. The official development git repository is now at github [1]. What about the bug tracker? Will it remain at fdo's bugzilla. I have to admit I'm not a huge fan of github's bug tracker. I am not a fan of bz either... I think for now we prefer github, but will leave bz open, and we will not migrate bugs. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] selinux: fix missing SELinux unit access check
Development has moved to github.com/systemd It is probably better to submit a Github Push Request there if you have not done so already. Thanks -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpLns3mVGvdM.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Use a specific device ?
On Fri, 2015-06-05 at 16:16 +0200, Jean-Christian de Rivaz wrote: Le 05. 06. 15 15:51, poma a écrit : On 05.06.2015 15:37, Jean-Christian de Rivaz wrote: Le 05. 06. 15 15:09, poma a écrit : On 05.06.2015 14:14, Jean-Christian de Rivaz wrote: Le 05. 06. 15 13:18, Aleksander Morgado a écrit : On Tue, May 26, 2015 at 12:19 AM, Jean-Christian de Rivaz j...@eclis.ch wrote: I have a system where the modem have multiple /dev/ttyACMx ports where x is not constant because of the dynamic nature of others serial devices. It may be worth noting that a very similar issue with the one faced here is the one with network interface names, where interface names were created as kernel drivers probed the different interfaces, ending up with eth0, eth1 and so on. Then, there would be network interface configurations for each network interface based on the name, but no one really ensured that the name was the same upon reboots. The solution provided by systemd to ensure that the proper configuration is applied always to the proper interface is to make the device names predictable, see: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ This solution avoids the need of any other udev rules to e.g. create network interface names containing the device MAC address or what not. I'm wondering whether the same could be applied not only to network interfaces, but also to ttyACMs, ttyUSBs and cdc-wdms, and end up having predictable tty names like e.g. /dev/ttyACMp0s20u4i0. Sure, those names are a nightmare to type, but they are predictable (e.g. in this case by including the physical location of the connector of the hardware). This would be a wonderful solution. The only problem is when will this feature be available in a stable Linux kernel widely used by all majors distributions? Until this dream happens (probably not before severals years I guess), an other option must be implemented. Jean-Christian Face your broadband modem, live your dreams? Kay, when this would happen - Predictable Broadband Modem Interface Names? I must emphasis that this solution will still not solve the ModemManager problem of automatically probing any added serial devices, requiring all non-modem serial device to add the ID_MM_IGNORE hack in udev rules. This must change as soon as possible. Jean-Christian MM probing various hardware, not much of a news. But still a problem. The lack of proper use of udev by ModemManager What is proper use of udev here? Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: fix missing SELinux unit access check
On Tue, 09.06.15 17:01, Dominick Grift (dac.overr...@gmail.com) wrote: Development has moved to github.com/systemd It is probably better to submit a Github Push Request there if you have not done so already. Well, we still accept patches by mails to the mailing list. However we prefer gihub, especially for larger patch series. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Creating units using D-Bus
On Tue, 2015-06-09 at 19:33 +0200, Jakub Skořepa wrote:
Hello,
My name is Jakub Skořepa and I'm working on Cockpit UI for Systemd
Timers.
For that I need to create and modify systemd unit files. Cockpit uses
D
-Bus for everything so I need D-Bus API for that. I think that it
would
be beneficial if systemd was able to create unit files on-the-fly
using
through D-Bus method call.
I plan creating simple server for doing this task but long-term it
woul
d be better if systemd was capable of doing this.
I propose methods with following signatures:
# CreateUnit:
Creates specified unit
sa{sa{ss}}
| | ||
Name | |Value
Section name |
Key
# ModifyUnit: (same signature)
If section/key is not then section/key is left intact.
If Value= then key is erased.
# CreateUnits:
Creates multiple units. Same as CreateUnit called for each top-level
array element.
a{sa{sa{ss}}}
| | ||
Name | |Value
Section name |
Key
# ModifyUnits: (same signature as CreateUnits)
Modifies multiple units. Same as ModifyUnit called for each top
-level
array element.
In order for ModifyUnit() to work, there also needs to be a way to
retrieve the current definition of the unit on the system. (And,
ideally, a way to retrieve this for any unit currently loaded into
systemd).
signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
Oh please Jira no, it is too much and the user friendliness is highly arguable. On Tue, Jun 9, 2015 at 8:46 AM Jóhann B. Guðmundsson johan...@gmail.com wrote: On 06/09/2015 11:57 AM, Mihamina Rakotomandimby wrote: On 06/09/2015 02:30 PM, Jóhann B. Guðmundsson wrote: As of today we've disabled git-push to fd.o. The official development git repository is now at github [1]. What about the bug tracker? Will it remain at fdo's bugzilla. I have to admit I'm not a huge fan of github's bug tracker. I am not a fan of bz either... I think for now we prefer github, but will leave bz open, and we will not migrate bugs. I would like to see us move and migrated the bugs to jira ( which is without doubt the best and friendliest bug tracker I have found ) which integrates nicely with github as well as move the community wiki to confluence to strengthen collaboration in the community. I use Jira everyday but it will be overkill for our use. As do I and am maintaining over 700 projects of different nature, with 400.000 issue in such instance and it's not overkill, it is scalable which is precisely what we need and provides the necessary oversight that is required to health monitor the project(s) and the community as well as providing the modern collaboration infrastructure we need to, to sustain ourselves as a community on the 21 century. It is the perfect bug tracker, be it single project or more ( we require atleast three different project in that instance as in one for systemd itself and atleast two for the community, which be following completely different workflow than systemd project will ) for this and it is as very scalable ( and extendable via plugins ) for the future, for the direction the building block of modern OS ( systemd ) can take. I spent eight years working in mozilla bugzilla as well as various tracker instances and I can tell you here and now that they are insufficient for the task at hand since one of the goal here is to reduce time developers spend in bug trackers not increase it. On top of that the bugzilla mozilla and tracker UI is crap to use and lacks all mobile/tablet interface as far as I know. Which bug tracker would you propose? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 06/09/2015 06:42 PM, David Timothy Strauss wrote: Let's just try the GitHub tracker. I like how it associates issues with pull requests and supports auto-linking for commit IDs, user names, and other issue numbers. Is there any serious use case for systemd upstream it doesn't support? What do you define as serious use case? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 06/09/2015 06:53 PM, Camilo Aguilar wrote: Oh please Jira no, it is too much and the user friendliness is highly arguable. Please do not top post and compared to bugzilla and the lack of proper oversight github and other issue tracker provide it's much better. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
Let's just try the GitHub tracker. I like how it associates issues with pull requests and supports auto-linking for commit IDs, user names, and other issue numbers. Is there any serious use case for systemd upstream it doesn't support? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Creating units using D-Bus
Hello,
My name is Jakub Skořepa and I'm working on Cockpit UI for Systemd
Timers.
For that I need to create and modify systemd unit files. Cockpit uses D
-Bus for everything so I need D-Bus API for that. I think that it would
be beneficial if systemd was able to create unit files on-the-fly using
through D-Bus method call.
I plan creating simple server for doing this task but long-term it woul
d be better if systemd was capable of doing this.
I propose methods with following signatures:
# CreateUnit:
Creates specified unit
sa{sa{ss}}
| | ||
Name | |Value
Section name |
Key
# ModifyUnit: (same signature)
If section/key is not then section/key is left intact.
If Value= then key is erased.
# CreateUnits:
Creates multiple units. Same as CreateUnit called for each top-level
array element.
a{sa{sa{ss}}}
| | ||
Name | |Value
Section name |
Key
# ModifyUnits: (same signature as CreateUnits)
Modifies multiple units. Same as ModifyUnit called for each top-level
array element.
Regards,
Jakub
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Use a specific device ?
On Tue, 2015-06-09 at 19:34 +0200, Jean-Christian de Rivaz wrote: Le 09. 06. 15 17:43, Dan Williams a écrit : On Fri, 2015-06-05 at 16:16 +0200, Jean-Christian de Rivaz wrote: Le 05. 06. 15 15:51, poma a écrit : On 05.06.2015 15:37, Jean-Christian de Rivaz wrote: Le 05. 06. 15 15:09, poma a écrit : On 05.06.2015 14:14, Jean-Christian de Rivaz wrote: Le 05. 06. 15 13:18, Aleksander Morgado a écrit : On Tue, May 26, 2015 at 12:19 AM, Jean-Christian de Rivaz j...@eclis.ch wrote: I have a system where the modem have multiple /dev/ttyACMx ports where x is not constant because of the dynamic nature of others serial devices. It may be worth noting that a very similar issue with the one faced here is the one with network interface names, where interface names were created as kernel drivers probed the different interfaces, ending up with eth0, eth1 and so on. Then, there would be network interface configurations for each network interface based on the name, but no one really ensured that the name was the same upon reboots. The solution provided by systemd to ensure that the proper configuration is applied always to the proper interface is to make the device names predictable, see: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ This solution avoids the need of any other udev rules to e.g. create network interface names containing the device MAC address or what not. I'm wondering whether the same could be applied not only to network interfaces, but also to ttyACMs, ttyUSBs and cdc-wdms, and end up having predictable tty names like e.g. /dev/ttyACMp0s20u4i0. Sure, those names are a nightmare to type, but they are predictable (e.g. in this case by including the physical location of the connector of the hardware). This would be a wonderful solution. The only problem is when will this feature be available in a stable Linux kernel widely used by all majors distributions? Until this dream happens (probably not before severals years I guess), an other option must be implemented. Jean-Christian Face your broadband modem, live your dreams? Kay, when this would happen - Predictable Broadband Modem Interface Names? I must emphasis that this solution will still not solve the ModemManager problem of automatically probing any added serial devices, requiring all non-modem serial device to add the ID_MM_IGNORE hack in udev rules. This must change as soon as possible. Jean-Christian MM probing various hardware, not much of a news. But still a problem. The lack of proper use of udev by ModemManager What is proper use of udev here? Dan By looking on how others types of device are handled, udev should be used to detect the type of a device in a way to let the relevant application manage it if the kernel did not have already a way to detect the type of the device (by using USB HID for example). The goal in this case is to have modem devices handled by a modem application like ModemManager or Ofono. The most comfortable way for the users is to have a list of know devices type, usually based on some vendor and product id. This work generally very well for PCI and USB devices. The documentation should provide an easy way for a user to add and to submit to the project a new udev rule in case the product he use is not already in the list. The rules could be plain text udev rules under /lib/udev/rules.d/ (see for example 40-libgphoto2-2.rules or 40-libsane.rules) or directly coded into the application like Ofono do for example, see http://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/udevng.c#n1065. I personally much like the plain udev rule because it allow easy experiment without changing the source code of the application. For example the last new modem I use on a embedded system is working good enough for me with the generic ModemManager plugin so it would be nice to let support it by just add a line in a udev rules file. There are some cases where this is not enough, typically for the plain old ttyS* serial port and when the reported vendor and product id is just a generic serial port that can be connected physically to any serial device, not necessary a modem. In this case the distribution or the user should provides a udev rule to specify that there is a modem device connected to this particular serial port or to probe if there is a modem connected to it. Maybe he know the exact type of the modem, maybe he want to let the application probe the modem type, maybe he want to let the application detect if there is a modem or not. I have no strong opinion on how the distribution should set the default for this kind of ports, but I think this is important to let the choice to the distributions and to the users on how the serial ports are acceded by the application. ModemManager ships defaults that
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, 09.06.15 11:30, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: I would like to see us move and migrated the bugs to jira ( which is without doubt the best and friendliest bug tracker I have found ) which integrates nicely with github as well as move the community wiki to confluence to strengthen collaboration in the community. Well, I already feel uncomfortable with moving things to one closed source platform in github, but given the advantages I accept it. However, moving things to *two* closed source platforms sounds even worse to me. If we bind our project to closed source companies I much prefer sticking to one, instead of two. Also, while I see quite a few shortcomings in github model, pure bug tracking certainly isn't where the shortcomings are, it's more about tracking patches where I am not convinced, but I doubt JIRA will fix that part for us... or will it? I would be the one that would overseeing and handling the migration and I was hoping David Strauss might be willing to host that infrastructure for us and or some other place for that matter ( mini pc in systemd's HQ in German maybe ?) I am very much of the opinion that we should be very careful when commiting to maintain our own infrastructure. You know how undermaintained fdo was, and if we do it on our own it's even worse. Administrating our own servers is a huge amount of work especially given you have to do this over a long long time continously, and our workforce is already too limited for the amount of work we have to do. One of the major benefits of github I think is that it's their very business to administer the site for us, and they'll do it as well as they possibly can. That gets substantially more difficult if we roll that all on our own, given that most of us have little desire to become administrators oursevles and we have no budget for paying one over years. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
Moving from #88 to this thread: On Tue, Jun 9, 2015 at 12:41 PM, Lennart Poettering lenn...@poettering.net wrote: So I think updating the PR (by force-pushing) is really nasty, and we shouldn't do it. Instead, please push a new PR, mention that it obsoletes the old one. (of course, I wished that github would know a concept of PR obsoletion natively...) Also, I think in this case we really should require an issue being created for the entire thing that groups the various PRs together. (In fact, I am pretty sure we should *enforce* that all PRs have an issue attached to them. Maybe with a bot or so that creates issues for all PRs that reference no issue). I don't think it's very practical to require opening multiple pull requests for the several revisions and requiring that authors do not use git push -f, particularly since most users of GitHub are already used to that... Also, requiring an open issue to keep track of the multiple PRs will probably quickly produce a sea of ids that will be really hard to keep track of. I think a more productive advice would be for reviewers to avoid using line comments for anything that is wanted for posterity and instead only use them to say typo or comment here or to point out what exactly in the code the comment on the main thread is making reference to. Wouldn't you think that would be preferrable? Cheers, Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Wed, 03.06.15 10:39, Krzesimir Nowak (krzesi...@endocode.com) wrote: Hi, I see that some patches from mailing list were imported as issues to github.com (like this one - https://github.com/systemd/systemd/pull/16). There's a problem with that - I can't update the PR anymore with followup fixes and whatnot. What's the workflow in this case? File a new PR and ask nicely for old one to be deleted? So I think updating the PR (by force-pushing) is really nasty, and we shouldn't do it. Instead, please push a new PR, mention that it obsoletes the old one. (of course, I wished that github would know a concept of PR obsoletion natively...) Also, I think in this case we really should require an issue being created for the entire thing that groups the various PRs together. (In fact, I am pretty sure we should *enforce* that all PRs have an issue attached to them. Maybe with a bot or so that creates issues for all PRs that reference no issue). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
Usually, when a PR needs fixing, it is done in the same PR, and there may be need to rebase so that commit history is not polluted, hence git push -f On Tue, Jun 9, 2015 at 3:59 PM Lennart Poettering lenn...@poettering.net wrote: On Tue, 09.06.15 18:42, David Timothy Strauss (da...@davidstrauss.net) wrote: Let's just try the GitHub tracker. I like how it associates issues with pull requests and supports auto-linking for commit IDs, user names, and other issue numbers. Is there any serious use case for systemd upstream it doesn't support? Here's one issue I have with the github bug tracker. Or maybe it's more an issue with the github PR tracker... Anyway, if somebody finds a bug in systemd two things might happen: a) if he's a user/admin without C skills, he'll just file an issue and that's it. that's great. b) if he's a hacker with C skills he'll likely send us a PR instead. But this is where the problems now start: Most likely the first patch iteration will not be right, so we comment and ask for a new PR, and close the old one. The two PRs will not be closely related to each other then. In the best case they will reference each other, but that's it. However what's worse is that the bug is not tracked at all in the the time between the old PR got closed and the new is opened. Now, we could require that in the meantime a new issue has to be created, but this is a manual process, and it will not inherit labels and stuff, unless the user does so manually. And that's nasty. And of course, the issue that in case of a) we only end up in an issue, and in case of b) when the first patch is actually good we only end up in a PR is a major issue too. I am not sure what to do about this yet. Maybe we can enforce that PRs have to have an issue, or so. Maybe anyone has an idea? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, Jun 9, 2015 at 12:59 PM, Lennart Poettering lenn...@poettering.net wrote: [...] so we comment and ask for a new PR, and close the old one. See my previous comment, I think this cure is worse than the disease :-) Instead, just reuse the same PR and use `git push -f` to ship new versions of the commits to the same branch... Yes it's awful but unfortunately that's how GitHub works... To work around the problem of line comments being lost, just ask *reviewers* to make most of the relevant comments in the PR thread and keep line comments to simple comments that are probably not going to be relevant when they're obliterated... Cheers, Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] missing: add more btrfs defines
On Tue, 02.06.15 11:08, Michael Olbrich (m.olbr...@pengutronix.de) wrote:
For the sake of the archives, this got merged as:
https://github.com/systemd/systemd/pull/12
---
src/shared/missing.h | 28
1 file changed, 28 insertions(+)
diff --git a/src/shared/missing.h b/src/shared/missing.h
index 919400949138..be7f6186fcfb 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -269,6 +269,11 @@ struct btrfs_qgroup_inherit {
__u64 qgroups[0];
};
+struct btrfs_ioctl_qgroup_limit_args {
+__u64 qgroupid;
+struct btrfs_qgroup_limit lim;
+};
+
struct btrfs_ioctl_vol_args_v2 {
__s64 fd;
__u64 transid;
@@ -360,6 +365,14 @@ struct btrfs_ioctl_clone_range_args {
__u64 src_offset, src_length;
__u64 dest_offset;
};
+
+#define BTRFS_QUOTA_CTL_ENABLE 1
+#define BTRFS_QUOTA_CTL_DISABLE 2
+#define BTRFS_QUOTA_CTL_RESCAN__NOTUSED 3
+struct btrfs_ioctl_quota_ctl_args {
+__u64 cmd;
+__u64 status;
+};
#endif
#ifndef BTRFS_IOC_DEFRAG
@@ -367,6 +380,11 @@ struct btrfs_ioctl_clone_range_args {
struct btrfs_ioctl_vol_args)
#endif
+#ifndef BTRFS_IOC_RESIZE
+#define BTRFS_IOC_RESIZE _IOW(BTRFS_IOCTL_MAGIC, 3, \
+ struct btrfs_ioctl_vol_args)
+#endif
+
#ifndef BTRFS_IOC_CLONE
#define BTRFS_IOC_CLONE _IOW(BTRFS_IOCTL_MAGIC, 9, int)
#endif
@@ -424,6 +442,16 @@ struct btrfs_ioctl_clone_range_args {
struct btrfs_ioctl_vol_args)
#endif
+#ifndef BTRFS_IOC_QUOTA_CTL
+#define BTRFS_IOC_QUOTA_CTL _IOWR(BTRFS_IOCTL_MAGIC, 40, \
+ struct btrfs_ioctl_quota_ctl_args)
+#endif
+
+#ifndef BTRFS_IOC_QGROUP_LIMIT
+#define BTRFS_IOC_QGROUP_LIMIT _IOR(BTRFS_IOCTL_MAGIC, 43, \
+ struct btrfs_ioctl_qgroup_limit_args)
+#endif
+
#ifndef BTRFS_FIRST_FREE_OBJECTID
#define BTRFS_FIRST_FREE_OBJECTID 256
#endif
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, 09.06.15 18:42, David Timothy Strauss (da...@davidstrauss.net) wrote: Let's just try the GitHub tracker. I like how it associates issues with pull requests and supports auto-linking for commit IDs, user names, and other issue numbers. Is there any serious use case for systemd upstream it doesn't support? Here's one issue I have with the github bug tracker. Or maybe it's more an issue with the github PR tracker... Anyway, if somebody finds a bug in systemd two things might happen: a) if he's a user/admin without C skills, he'll just file an issue and that's it. that's great. b) if he's a hacker with C skills he'll likely send us a PR instead. But this is where the problems now start: Most likely the first patch iteration will not be right, so we comment and ask for a new PR, and close the old one. The two PRs will not be closely related to each other then. In the best case they will reference each other, but that's it. However what's worse is that the bug is not tracked at all in the the time between the old PR got closed and the new is opened. Now, we could require that in the meantime a new issue has to be created, but this is a manual process, and it will not inherit labels and stuff, unless the user does so manually. And that's nasty. And of course, the issue that in case of a) we only end up in an issue, and in case of b) when the first patch is actually good we only end up in a PR is a major issue too. I am not sure what to do about this yet. Maybe we can enforce that PRs have to have an issue, or so. Maybe anyone has an idea? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 06/09/2015 07:50 PM, Lennart Poettering wrote: On Tue, 09.06.15 11:30, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: I would like to see us move and migrated the bugs to jira ( which is without doubt the best and friendliest bug tracker I have found ) which integrates nicely with github as well as move the community wiki to confluence to strengthen collaboration in the community. Well, I already feel uncomfortable with moving things to one closed source platform in github, but given the advantages I accept it. However, moving things to *two* closed source platforms sounds even worse to me. If we bind our project to closed source companies I much prefer sticking to one, instead of two. There is no difference between one or many closed source since you decided to head down this road et all and I have yet to see the problem you sought out to alleviate will be solved with that change or that change alone for that matter. Personally I'm not foreseeing us ever hacking on Atlassian source code directly but rather extend it via plugins ( locally written or otherwise ) if the need arise ( which afaik would be only needed for QA related stuff ) so I dont see how you really can call this closed source however the source code for Atlassian products is available to license holders and they offer free licenses for official open source projects [¹] which covers all the plugins on the market place as well. Also, while I see quite a few shortcomings in github model, pure bug tracking certainly isn't where the shortcomings are, it's more about tracking patches where I am not convinced, but I doubt JIRA will fix that part for us... or will it? I beg the differ for pure bug tracking it is quite limited. The fact is we are long overdue building a proper infrastructure to sustain the building block of modern OS. We need to do proper QA to properly support and backup our downstream consumers ( distributions, embedded and otherwise) and that means tagging bugs by distributions, vendors, releases. Once bug has been validated, write test cases to prevent them from happening again. provide them with prebuild packages to test ( and or only provide it as btrfs snapshots to avoid having to deal with plethora of packaging formats ) write proper release notes, provide proper documentation etc. means to correctly identify and allocate resources as needed. The better work we do here is, the less is the work downstream consumers have do to downstream. I would be the one that would overseeing and handling the migration and I was hoping David Strauss might be willing to host that infrastructure for us and or some other place for that matter ( mini pc in systemd's HQ in German maybe ?) I am very much of the opinion that we should be very careful when commiting to maintain our own infrastructure. You know how undermaintained fdo was, and if we do it on our own it's even worse. Administrating our own servers is a huge amount of work especially given you have to do this over a long long time continously, and our workforce is already too limited for the amount of work we have to do. This is not as high maintenance as you let it out to be or resource intensive for that matter. ( I design this with mini pc in mind, intel nuc and the like so this could be hosted here at home if necessary and or relocated to Germany if requested ) The infrastructure for this is well maintainable by a single individual in his spare time however four ( or more ) individuals providing their free time would be optimal. Your workforce is limited to what you make it out to be and you seemed to be fixating on development resources alone which arguably is wrong on two accounts. First development resource are small ( but important ) part of a successful project. Secondly the success to systemd is thanks to collaborated effort between individuals residing in downstream consumer community's and this is where that collaboration effort would continue to grow since this is where the contributed time is best spent ( and least time I checked the community was far greater then what ca 20 committed developers ) That said I was designing my work to reduce work on direct development resources not increase it ( which infrastructure resources are supposed to do ) so if you have to spent 10 minutes more once implemented than you did before this effort will have become a failure.. One of the major benefits of github I think is that it's their very business to administer the site for us, and they'll do it as well as they possibly can. That gets substantially more difficult if we roll that all on our own, given that most of us have little desire to become administrators oursevles and we have no budget for paying one over years. I had already taken money issue into account ( and even built a project within jira to handle that process ) since I did not expect nor want Red Hat to fund this effort. ( The
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 06/09/2015 06:42 PM, David Timothy Strauss wrote: Let's just try the GitHub tracker. I like how it associates issues with pull requests and supports auto-linking for commit IDs, user names, and other issue numbers. Is there any serious use case for systemd upstream it doesn't support? I can setup an instance which hooks up to the github for people to tried it out and test + people that prefer reporting in github can just continue to do so, Jira imports those issues anyway.. We can also skip hosting it with you since you oppose this and having it there was just an idea anyway, I'll just find another place to host the instance for jira and confluence, I'm paying for the domain as is anyway. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SyslogIdentifier does not work for messages printed with sd_journal_print
Hi Lennart, I found a workaround. When looking at the source code for sd_journal_print(), I saw that SYSLOG_IDENTIFIER defaults to the string pointed to by program_invocation_short_name (defined in errno.h). So I simply create a new string with the text that I want to assign to SYSLOG_IDENTIFIER and I make program_invocation_short_name point to it. It may not be the prettiest fix, but it works for the daemons I'm instantiating. Thanks, Martin Martin Belanger Sr. Software Engineer[image: Cyan]1383 North McDowell Blvd. Petaluma, CA 94954M(707) 481-3392emartin.belan...@cyaninc.comwww.cyaninc.com[image: Facebook] http://www.facebook.com/CyanInc [image: LinkedIn] http://www.linkedin.com/company/cyan-inc?trk=hb_tab_compy_id_2171992 [image: Twitter] http://twitter.com/CyanNews On Tue, Jun 9, 2015 at 3:16 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 02.06.15 20:31, Martin Belanger (martin.belan...@cyaninc.com) wrote: I'm using systemd 219 (Ubuntu 15.04). I have three instances of a daemon running. I use SyslogIdentifier to give each of them a unique identifier (e.g. myproc-1, myproc-2, myproc-3). I also redirect stdout/stderr to the journal using StandardOutput=journal and StandardError=journal. I noticed that messages sent to the journal with printf (i.e. stdout) get the proper SYSLOG_IDENTIFIER. However, messages send to the journal with sd_journal_print() get the default SYSLOG_IDENTIFIER (i.e. the process name). I also tried sd_journal_send() and get the same result. Any thoughts as to why this is happening? SyslogIdentifier only really applies to stdout/stderr messages, not to native journal messages, which will not carry that id at all. The only reason the setting exists is because it's useful to set something there because stdout/stderr doesn't carry enough information for this, and because the same stdout/stderr stream can be shared among multiple processes it's difficult and misleading to automatically derive the identifier from them... Hence: I'd really prefer fi we didn't have that option at all, we justed added it, because it was difficult to do without... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is SystemCallFilter working for you?
On Tue, 09.06.15 13:00, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello all, I was about to (re-)enable seccomp support in our systemd packages, and to write an integration test for it. However, it seems that this currently does not seem to work at all. Works fine here. config.h has HAVE_SECCOMP==1, and systemctl --version shows +SECCOMP, kernel has CONFIG_SECCOMP=y, CONFIG_HAVE_ARCH_SECCOMP_FILTER=y, and CONFIG_SECCOMP_FILTER=y, and I'm running on x86-64, so that all seems fine. Same settings here, on Fedora. All works fine. But if I have a unit like | [Unit] | Description=seccomp test | | [Service] | ExecStart=/bin/cat /etc/machine-id | SystemCallFilter=access (which really ought to fail) it just succeeds. Also, running This fails here, as it should. ./test-execute as root fails in test_exec_systemcallfilter(): | exec-systemcallfilter-failing.service | UMask: 0022 | WorkingDirectory: /home/martin | RootDirectory: / | NonBlocking: no | PrivateTmp: no | PrivateNetwork: no | PrivateDevices: no | ProtectHome: no | ProtectSystem: no | IgnoreSIGPIPE: yes | StandardInput: null | StandardOutput: inherit | StandardError: inherit | This should not be seen | PID: 16439 | Start Timestamp: Tue 2015-06-09 12:56:51 CEST | Exit Timestamp: Tue 2015-06-09 12:56:51 CEST | Exit Code: exited | Exit Status: 0 | Assertion 'service-main_exec_status.status == status_expected' failed at src/test/test-execute.c:57, function check(). Aborting. This is with libseccomp 2.2.1, I tested kernel 3.19 and 4.0. Is that working for anyone else? In particular, could you check if you have HAVE_SECCOMP and test-execute succeeds (as root) for you? The test works fine here too. Seems to be specific to your distro/setup? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 06/09/2015 09:34 PM, Lennart Poettering wrote: On Tue, 09.06.15 19:19, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 06/09/2015 06:42 PM, David Timothy Strauss wrote: Let's just try the GitHub tracker. I like how it associates issues with pull requests and supports auto-linking for commit IDs, user names, and other issue numbers. Is there any serious use case for systemd upstream it doesn't support? I can setup an instance which hooks up to the github for people to tried it out and test + people that prefer reporting in github can just continue to do so, Jira imports those issues anyway.. I am pretty sure we should *at least* first get some experience with github's own tools before we start jumping ship for some facets of it. We need to understand where the shortcomings are before we look for something else. As I mentioned in my other reply Jira would be an addon to github not a replacement. Atlassian has an product called stash [1] which is competing against github. If people are looking into alternatives for an web-based git repository solutions to github some comparison can be found here [2] I myself however is more invested in other aspects of the community than which web-based git repository solutions should be used ( what mattered only to me in that area was the move to pull requests since it was an key component for things to work in the long run and voila we have that with github ). My area of interest is the infrastructure, qa documentation and such is where I see the necessity of laying the correct foundation so we have the room for growth, collaboration as well as it being the place which results in better utilization of individuals contributed time ( developers and others, for example we need to start offloading some work of developers at this point in time by my account ) . 1. https://www.atlassian.com/software/stash 2. http://www.slant.co/topics/1440/compare/~gitlab_vs_stash_vs_github-enterprise ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'Failed at step NAMESPACE spawning' when using ReadOnlyDirectories in multi-instance service file
On Thu, 04.06.15 18:22, nusenu (nus...@openmailbox.org) wrote: Error message: Failed at step NAMESPACE spawning /usr/bin/tor: No such file or directory service: main process exited, code=exited, status=226/NAMESPACE Any chance you can retry to reproduce this with strace -p1 -o /tmp/log -f -s500 so that we can see what precisely is failing there? Looks like this happens on Debian 8 systems that have been upgraded from Debian 7, but it doesn't happen on fresh Debian 8 installations. Will file this bug in Debian's BTS. Please get me the strace output I asked for when this happens, so that we can track this down, otherwise there's little we can do. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Calling shutdown while executing a service
On Tue, 02.06.15 16:19, Christoph Pleger (christoph.ple...@cs.tu-dortmund.de)
wrote:
Hello,
I created a new target, defined by this target file:
[Unit]
Description=LOCAL
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
AllowIsolate=yes
The new target only depends on one new service. The service is defined by:
[Unit]
Description=LOCAL
Requires=multi-user.target
Before=getty@tty1.service local.target
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/local
StandardOutput=tty
TTYPath=/dev/tty1
/usr/local/sbin/local is a bash script which calls several functions. When
one of these functions fails, i.e. returns another value than zero, the
script calls this function:
die() {
STRING=$1
echo 2 Error occured in function ${STRING}
echo Press any key to reboot (sorry for your inconvenience)
read -n 1
shutdown -r now
}
Now I have the case that one of the functions fails. But after pressing a
key, the computer does not reboot immediately, but schedules the reboot
for approximately two minutes in the future and then continues to execute
functions, till the two minutes are over.
Most likely systemd is waiting for your service (or some other
service) to finish before it proceeds with shutting down.
Consider issuing systemd-analyze set-log-level debug before you try
this. This turns on debug output which might tell you what precisely
systemd is waiting for.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHi V4] cryptsetup: craft a unique ID with the source device
On Mon, 01.06.15 17:26, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com If cryptsetup is called with a source device as argv[3], then craft the ID for the password agent with a unique device path. If possible /dev/block/maj:min is used, otherwise the original argv[3] is used. This enables password agents like petera [1] to provide a password according to the source device. The original ID did not carry enough information and was more targeted for a human readable string, which is specified in the Message field anyway. With this patch the ID of the ask.XXX ini file looks like this: ID=cryptsetup:/dev/block/maj:min For the sake of the archives: this was now merged with github PR #77. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 06/09/2015 09:44 PM, Lennart Poettering wrote: On Tue, 09.06.15 21:11, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: We need to do proper QA to properly support and backup our downstream consumers ( distributions, embedded and otherwise) and that means tagging bugs by distributions, vendors, releases. I'd be very careful with starting to track downstream issues upstream. I explicitly want to avoid that. It's a good thing that the bug kingdoms there are seperate, and that we aren't flooded with all kinds of downstream bugs all the time upstream. The pre-filtering done by downstream is absolutely important to keep things managable for us upstream. If anything I would be more strict here, and systematically refuse bug reports upstream for any package version older than the newest two, unless escalated by the downstream maintainers. Agreed In the long run I was thinking about a built in reporting tool that would report only the information we need, directly to our issue tracker ( anonymously without the need for an login account, what I dubbed drive by reporting ) and label bugs based on information from os-release that would be sent with that report and minimize any communication from upstream to downstream bug trackers since it wastes time ( #1228909 on bz.rh.com is prime example of unwanted, unneeded distraction from downstream, what I call contributors time waster which is why I stepped in and try to close that report to no prevail. ). I expected downstream package maintainers to have their own account and be part of this community and participating with us ( as is to be expected of downstream maintainers ) anyway first we need the infrastructure for that in place so I was keeping that information to myself ( as I'm doing with few other ideas ) until we have had sorted that out. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How many times is the root mounted in boot up?
On Mon, 01.06.15 20:43, Mantas Mikulėnas (graw...@gmail.com) wrote: I find: 1. systemd will generate a -.mount unit from /proc/self/mountsinfo 2. systemd will generate a -.mount unit by systemd-fstab-generator Q: * Which one takes priority? The latter, because it's a real unit, not just an in-memory representation of the current state. Well, not quite. It's actually more complex. We will actually merge information from both, but for the parts of it that are conflicting the current one from /proc will win over the one from disk. Specifically this means that systemctl status /home will show in the What: line what is currenty *actually* mounted on /home, and not what /etc/fstab says that *should* be mounted there... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, 09.06.15 12:55, Filipe Brandenburger (filbran...@google.com) wrote: Moving from #88 to this thread: On Tue, Jun 9, 2015 at 12:41 PM, Lennart Poettering lenn...@poettering.net wrote: So I think updating the PR (by force-pushing) is really nasty, and we shouldn't do it. Instead, please push a new PR, mention that it obsoletes the old one. (of course, I wished that github would know a concept of PR obsoletion natively...) Also, I think in this case we really should require an issue being created for the entire thing that groups the various PRs together. (In fact, I am pretty sure we should *enforce* that all PRs have an issue attached to them. Maybe with a bot or so that creates issues for all PRs that reference no issue). I don't think it's very practical to require opening multiple pull requests for the several revisions and requiring that authors do not use git push -f, particularly since most users of GitHub are already used to that... Also, requiring an open issue to keep track of the multiple PRs will probably quickly produce a sea of ids that will be really hard to keep track of. Well, the idea would be to consider PRs little more than attachments to the issues. And the issues would be only thing we'd really care about and where coneptional discussions would held. I think a more productive advice would be for reviewers to avoid using line comments for anything that is wanted for posterity and instead only use them to say typo or comment here or to point out what exactly in the code the comment on the main thread is making reference to. Wouldn't you think that would be preferrable? As mentioned in the other mail, nope, this is not preferrable: we *really* want to take benefit of the better review tool set. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, 09.06.15 21:11, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: We need to do proper QA to properly support and backup our downstream consumers ( distributions, embedded and otherwise) and that means tagging bugs by distributions, vendors, releases. I'd be very careful with starting to track downstream issues upstream. I explicitly want to avoid that. It's a good thing that the bug kingdoms there are seperate, and that we aren't flooded with all kinds of downstream bugs all the time upstream. The pre-filtering done by downstream is absolutely important to keep things managable for us upstream. If anything I would be more strict here, and systematically refuse bug reports upstream for any package version older than the newest two, unless escalated by the downstream maintainers. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SyslogIdentifier does not work for messages printed with sd_journal_print
On Tue, 09.06.15 13:50, Martin Belanger (martin.belan...@cyaninc.com) wrote: Hi Lennart, I found a workaround. When looking at the source code for sd_journal_print(), I saw that SYSLOG_IDENTIFIER defaults to the string pointed to by program_invocation_short_name (defined in errno.h). So I simply create a new string with the text that I want to assign to SYSLOG_IDENTIFIER and I make program_invocation_short_name point to it. It may not be the prettiest fix, but it works for the daemons I'm instantiating. Ah, yes, if you want to set this from your process internally, then setting program_invocation_short_name is actually completely OK. I don't even think it's ugly in any way. It's the short identifier for the program used on GNU, and it's initialized by argv[0] but you can set it to anything you like. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, Jun 9, 2015 at 2:37 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 09.06.15 13:04, Filipe Brandenburger (filbran...@google.com) wrote: On Tue, Jun 9, 2015 at 12:59 PM, Lennart Poettering lenn...@poettering.net wrote: [...] so we comment and ask for a new PR, and close the old one. See my previous comment, I think this cure is worse than the disease :-) Why would you say this? Why are multiple sequencial PR, where the old obsoleted ones are closed and locked that bad? - Too much administrivia - Threads get split up (did I comment on the origina PR or on this one?) - Hard to follow the references around - E-mail notifications get split into separate threads (not that GitHub does a stellar job of e-mail notifications anyways...) - ... I actually think the fact that in GitHub you'll use a PR *or* and Issue is actually good, so you mainly have a single thread to discuss the same item... I just think that working around the GitHub bug of losing comments by creating a convoluted workflow around it (which is hard to enforce, as you can't really block PR authors from using `git push -f`) is the wrong approach... Maybe someone should complain to GitHub about this issue with losing track of the comments on the previous versions of the code instead? If that was fixed in GitHub, would you be happy not splitting multiple PRs for multiple versions of the same feature/issue? Cheers, Filipe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, 09.06.15 14:54, Filipe Brandenburger (filbran...@google.com) wrote: On Tue, Jun 9, 2015 at 2:37 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 09.06.15 13:04, Filipe Brandenburger (filbran...@google.com) wrote: On Tue, Jun 9, 2015 at 12:59 PM, Lennart Poettering lenn...@poettering.net wrote: [...] so we comment and ask for a new PR, and close the old one. See my previous comment, I think this cure is worse than the disease :-) Why would you say this? Why are multiple sequencial PR, where the old obsoleted ones are closed and locked that bad? - Too much administrivia Yes, I with this was easier to do. But I figure it's OK to do if you have the git shell helper stuff in place. - Threads get split up (did I comment on the origina PR or on this one?) Yeah, it generally requires a regime for everybody to stick to code disccusions in the PR comments, and conceptional discussions in the issue comments. Also, when we obsolete a PR we should lock it to ensure people stop commenting there. - Hard to follow the references around Yupp. I actually think the fact that in GitHub you'll use a PR *or* and Issue is actually good, so you mainly have a single thread to discuss the same item... Well, but it's really weird... If you start out with a patch things are tracked as PR. If you start out without a patch things are tracked as an issue. And they have quite different workflows, as PRs cannot be reopened and issues can, for example. I am pretty sure issues should be at the core of things... WHat really surprises me about the whole discussion is that we cannot be the first ones running into this. Given the success of github this must be a common issue. And if it is, then either github is actually prety bad, or I am too stuck in my bugzilla mindset and haven't really grokked the github way of doing things yet. I just think that working around the GitHub bug of losing comments by creating a convoluted workflow around it (which is hard to enforce, as you can't really block PR authors from using `git push -f`) is the wrong approach... Well, I can actually enforce it by closing the PR and locking it. Maybe someone should complain to GitHub about this issue with losing track of the comments on the previous versions of the code instead? Well, that's not sufficient at all, see above. If that was fixed in GitHub, would you be happy not splitting multiple PRs for multiple versions of the same feature/issue? I would prefer if we'd have immutable history. i.e. each issue that is raised should keep its comments, its patches, its reviews forever, but just get them marked obsolete but not vanished. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Creating units using D-Bus
On Tue, 09.06.15 14:47, Stephen Gallagher (sgall...@redhat.com) wrote: In order for ModifyUnit() to work, there also needs to be a way to retrieve the current definition of the unit on the system. (And, ideally, a way to retrieve this for any unit currently loaded into systemd). systemctl cat gives you the current definition of a unit. systemctl show will give you the full list of settings in effect for a unit (which is considerably more than the former). We have a nice API for the latter (since all those setting are exposed as simply bus props), but the former involves opening the text files on the client side. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, 09.06.15 19:19, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 06/09/2015 06:42 PM, David Timothy Strauss wrote: Let's just try the GitHub tracker. I like how it associates issues with pull requests and supports auto-linking for commit IDs, user names, and other issue numbers. Is there any serious use case for systemd upstream it doesn't support? I can setup an instance which hooks up to the github for people to tried it out and test + people that prefer reporting in github can just continue to do so, Jira imports those issues anyway.. I am pretty sure we should *at least* first get some experience with github's own tools before we start jumping ship for some facets of it. We need to understand where the shortcomings are before we look for something else. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, 09.06.15 13:04, Filipe Brandenburger (filbran...@google.com) wrote: On Tue, Jun 9, 2015 at 12:59 PM, Lennart Poettering lenn...@poettering.net wrote: [...] so we comment and ask for a new PR, and close the old one. See my previous comment, I think this cure is worse than the disease :-) Why would you say this? Why are multiple sequencial PR, where the old obsoleted ones are closed and locked that bad? Instead, just reuse the same PR and use `git push -f` to ship new versions of the commits to the same branch... Yes it's awful but unfortunately that's how GitHub works... Yeah, it is awful, and loses all the comments, as well is incompatible with having multiple people making patch suggestions for the same issue. To work around the problem of line comments being lost, just ask *reviewers* to make most of the relevant comments in the PR thread and keep line comments to simple comments that are probably not going to be relevant when they're obliterated... Well, *the* major reason we switched to github is actually taking benefit of the much more powerful inline review tool that's a pleasure to work with. Reviews by mail are just awful, and reviews out-of-line are even worse. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] siphash24 gives unmatched bloom_mask and bloom_filter?
Hi, David,
I think I've found the reason for my problem. That is , with
arg0path=/p1/p2/p3,
The sent signal should be sent with arg0=/p1/p2/p3/, but not arg0=/p1/p2/p3.
Then Another question is, with arg0path=/p1/p2, the signal sent with
arg0=/p1/p2/p3
should be received and the callback be executed.
But following the execution path: proces_message()== process_match()
==bus_match_run()
== value_node_test() == path_complex_pattern()== complex_pattern_check('/',
pattern, value)
== if (*a != *b) return (separator (*a == 0 || *b == 0)) || (*a == 0 *b
== c b[1] == 0) || (*b == 0 *a == c a[1] == 0);
This will return false, which caused the callback cannot be executed.
Should this comply with the DBus Spec?
Thank you!
David Herrmann Mon, 08 Jun 2015 09:44:25 -0700
Hi
On Mon, Jun 8, 2015 at 3:26 PM, eshar...@163.com wrote:
Hi, David
I just modified the src/libsystemd/sd-bus/test-bus-match.c.
And you could add the following two lines in the bloom_add_data() in
bus-bloom.c
for (i = 0; i size/sizeof(uint64_t); i++)
log_info(bloom: filter[%d] = 0x%llx,i, filter[i]);
Can you please try with systemd-220? The diff against 220 is 83 lines
and it doesn't even compile. If there is a bloom-bug, it should be
possible to show this with a much shorter example. I'm having a hard
time understanding what you changed there, sorry.
Thanks
David___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 06/09/2015 11:57 AM, Mihamina Rakotomandimby wrote: On 06/09/2015 02:30 PM, Jóhann B. Guðmundsson wrote: As of today we've disabled git-push to fd.o. The official development git repository is now at github [1]. What about the bug tracker? Will it remain at fdo's bugzilla. I have to admit I'm not a huge fan of github's bug tracker. I am not a fan of bz either... I think for now we prefer github, but will leave bz open, and we will not migrate bugs. I would like to see us move and migrated the bugs to jira ( which is without doubt the best and friendliest bug tracker I have found ) which integrates nicely with github as well as move the community wiki to confluence to strengthen collaboration in the community. I use Jira everyday but it will be overkill for our use. As do I and am maintaining over 700 projects of different nature, with 400.000 issue in such instance and it's not overkill, it is scalable which is precisely what we need and provides the necessary oversight that is required to health monitor the project(s) and the community as well as providing the modern collaboration infrastructure we need to, to sustain ourselves as a community on the 21 century. It is the perfect bug tracker, be it single project or more ( we require atleast three different project in that instance as in one for systemd itself and atleast two for the community, which be following completely different workflow than systemd project will ) for this and it is as very scalable ( and extendable via plugins ) for the future, for the direction the building block of modern OS ( systemd ) can take. I spent eight years working in mozilla bugzilla as well as various tracker instances and I can tell you here and now that they are insufficient for the task at hand since one of the goal here is to reduce time developers spend in bug trackers not increase it. On top of that the bugzilla mozilla and tracker UI is crap to use and lacks all mobile/tablet interface as far as I know. Which bug tracker would you propose? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nss-myhostname: why don't loopback interfaces appear?
On 9 June 2015 at 20:36, Lennart Poettering lenn...@poettering.net wrote: On Wed, 03.06.15 16:31, Daurnimator (q...@daurnimator.com) wrote: On 3 June 2015 at 16:01, Lennart Poettering lenn...@poettering.net wrote: On Wed, 03.06.15 15:40, Daurnimator (q...@daurnimator.com) wrote: I was playing around with nss, and found that my loopback interface ip doesn't appear from nss-myhostname. Rather, my other ones do. Furthermore, unless I request IPv4, link-local IPv6 addresses are returned. Is this expected? We order the returned addresses by scope. Global addresses are placed first, local ones last. Then why are link local IPv6 addresses returned first? If this was the case, I would expect to see: 192.168.2.229 192.168.2.21 fe80::aed1:b8ff:fec0:d113 fe80::9eeb:e8ff:fe1b:f42d 127.0.0.1 ::1 Currently the first ordering key is the address family (ipv4 before ipv6), the second ordering key is the scope (global before link-local). Are you suggesting we should turn this around, and sort by scope first, and by address family then? I might be open to such a change. Here I was just observing that in my mind, a scope local ipv6 address is less global than an ipv4 address; and hence doubting your statement that things are ordered most global to least global We return addresses on the loopback device only when there's no other address known. What's the rationale for this? (i.e. why not always just include 127.0.0.1 and ::1 last?) Because they are an implementation detail I think. If something wants to know the local IP address, then returning that information is really useless... 127.0.0.x is really an address we should never present to the user ever, unless there#s no better way... I mean, I am pretty sure I could explain a non-technical person off the streat what an IP address is, but I am pretty sure I'd had quite some trouble explaining what the purpose of 127.0.0.1 is on top of that... example use case, I'm testing a client/server protocol: - the server is running locally; and because it shouldn't be exposed to the internet, it is bound to localhost. - I start the client and tell it to connect to $HOSTNAME - This should find it's way to the loopback interface. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is SystemCallFilter working for you?
On Tue, Jun 9, 2015 at 1:00 PM, Martin Pitt martin.p...@ubuntu.com wrote: Hello all, I was about to (re-)enable seccomp support in our systemd packages, and to write an integration test for it. However, it seems that this currently does not seem to work at all. config.h has HAVE_SECCOMP==1, and systemctl --version shows +SECCOMP, kernel has CONFIG_SECCOMP=y, CONFIG_HAVE_ARCH_SECCOMP_FILTER=y, and CONFIG_SECCOMP_FILTER=y, and I'm running on x86-64, so that all seems fine. But if I have a unit like | [Unit] | Description=seccomp test | | [Service] | ExecStart=/bin/cat /etc/machine-id | SystemCallFilter=access (which really ought to fail) it just succeeds. Also, running ./test-execute as root fails in test_exec_systemcallfilter(): | exec-systemcallfilter-failing.service | UMask: 0022 | WorkingDirectory: /home/martin | RootDirectory: / | NonBlocking: no | PrivateTmp: no | PrivateNetwork: no | PrivateDevices: no | ProtectHome: no | ProtectSystem: no | IgnoreSIGPIPE: yes | StandardInput: null | StandardOutput: inherit | StandardError: inherit | This should not be seen | PID: 16439 | Start Timestamp: Tue 2015-06-09 12:56:51 CEST | Exit Timestamp: Tue 2015-06-09 12:56:51 CEST | Exit Code: exited | Exit Status: 0 | Assertion 'service-main_exec_status.status == status_expected' failed at src/test/test-execute.c:57, function check(). Aborting. This is with libseccomp 2.2.1, I tested kernel 3.19 and 4.0. Is that working for anyone else? In particular, could you check if you have HAVE_SECCOMP and test-execute succeeds (as root) for you? Hi, It works for me. I tested on my machine with Linux 4.0.5 (archlinux) and libseccomp 2.2.0 and test-execute passed. But by looking at your output, there is something weird, you should have a line like this for this test: SystemCallFilter: exit exit_group rt_sigreturn ioperm execve Just after StandardError: inherit and just before PID: 16439. Because in exec_context_dump() it prints the SystemCallFilter line if it isn't empty. Since test-execute launched the seccomp tests, HAVE_SECCOMP is set, but it seems that syscall_filter == NULL in your case? 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On 06/09/2015 10:50 PM, Lennart Poettering wrote: I would like to see us move and migrated the bugs to jira ( which is without doubt the best and friendliest bug tracker I have found ) which integrates nicely with github as well as move the community wiki to confluence to strengthen collaboration in the community. Well, I already feel uncomfortable with moving things to one closed source platform in github, but given the advantages I accept it. However, moving things to*two* closed source platforms sounds even worse to me. If we bind our project to closed source companies I much prefer sticking to one, instead of two. We should have switched to Gitlab then: https://about.gitlab.com/2015/03/03/gitlab-acquires-gitorious/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] selinux: fix missing SELinux unit access check
I found an oversight in the previous v1 patch, found at
http://lists.freedesktop.org/archives/systemd-devel/2015-June/032796.html,
that u-load_state == UNIT_ERROR in the error path of unit_load(),
that is:
int unit_load(Unit *u) {
int r;
...cut...
fail:
u-load_state = u-load_state == UNIT_STUB ? UNIT_NOT_FOUND :
UNIT_ERROR;
u-load_error = r;
unit_add_to_dbus_queue(u);
unit_add_to_gc_queue(u);
log_unit_debug_errno(u, r, Failed to load configuration: %m);
return r;
}
To fix this, this v2 version looks at u-load_error to check error
status instead of u-load_state.
How to reproduce
Assume that test.service has not been loaded (even tried to get
loaded) in this boot. Then,
~]# cat ./foo.sh
#! /bin/sh
mv test.service /etc/systemd/system
systemctl daemon-reload
systemctl enable test.service
~]# ./foo.sh
Test
I used selinux-context branch of
https://github.com/keszybz/systemd.git in this test to avoid the issue
in https://bugzilla.redhat.com/show_bug.cgi?id=1224211.
--
Thanks.
HATAYAMA, Daisuke
From 398deee74edb06b54b8a74c25697cd6d977d8f2d Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Date: Wed, 10 Jun 2015 14:10:31 +0900
Subject: [PATCH] selinux: fix missing SELinux unit access check
Currently, SELinux unit access check is not performed if a given unit
file has not been registered in a hash table. This is because function
manager_get_unit() only tries to pick up a Unit object from a Unit
hash table. Instead, we use function manager_load_unit() searching
Unit file pathes for the given Unit file.
---
src/core/selinux-access.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
v2:
- checking an error status by u-load_error to cover UNIT_ERROR case.
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index decd42f..ac52906 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -292,8 +292,12 @@ int mac_selinux_unit_access_check_strv(char **units,
int r;
STRV_FOREACH(i, units) {
-u = manager_get_unit(m, *i);
+r = manager_load_unit(m, *i, NULL, error, u);
+if (r 0)
+return r;
if (u) {
+if (u-load_error != 0)
+return u-load_error;
r = mac_selinux_unit_access_check(u, message,
permission, error);
if (r 0)
return r;
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: fix missing SELinux unit access check
From: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Subject: Re: [systemd-devel] [PATCH] selinux: fix missing SELinux unit access
check
Date: Wed, 10 Jun 2015 12:18:48 +0900 (JST)
From: Lennart Poettering lenn...@poettering.net
Subject: Re: [systemd-devel] [PATCH] selinux: fix missing SELinux unit access
check
Date: Mon, 8 Jun 2015 12:37:14 +0200
On Mon, 08.06.15 19:00, HATAYAMA Daisuke (d.hatay...@jp.fujitsu.com) wrote:
Currently, SELinux unit access check is not performed if a given unit
file has not been registered in a hash table. This is because function
manager_get_unit() only tries to pick up a Unit object from a Unit
hash table. Instead, we use function manager_load_unit() searching
Unit file pathes for the given Unit file.
Were precisely is this relevant? I mean, we generally invoke
operations on units that are already loaded?
The SELinux unit access check is performed in terms of the following rule:
~]# sesearch -A -s init_t | grep systemd_unit_file_type | grep service
allow init_t systemd_unit_file_type : service { start stop status reload
kill load enable disable } ;
where systemd_unit_file_type is the attribute that is assigned to
context types that unit files have, e.g. systemd_unit_file_t.
Because this SELinux unit access check uses context types that unit
files have, we need to be able to refer to given unit files when we
perform requested unit operations.
Here's how to reproduce this issue. Note that:
- the systemd used here is with the fixing patch, and
- test.service has not been loaded (even tried to get loaded)
throughout this boot to guarantee that test.service is not registered
in the unit hash table.
Then,
~]# cat ./test.service
[Unit]
Description=test
[Service]
Type=oneshot
ExecStart=/usr/bin/true
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
~]# cat ./foo.sh
#! /bin/sh
mv test.service /etc/systemd/system
systemctl daemon-reload
systemctl enable test.service
~]# ./foo.sh
Then, here is a gdb log:
break mac_selinux_unit_access_check_strv
Breakpoint 1 at 0x7f5339807a28: file src/core/selinux-access.c, line 288.
(gdb) continue
Continuing.
Detaching after fork from child process 2198.
Breakpoint 1, mac_selinux_unit_access_check_strv (units=0x7f533a1324f0,
message=0x7f533a166a10, m=0x7f533a07c680, permission=0x7f533992bdb6 enable,
error=0x7ffe80abaec0) at src/core/selinux-access.c:288
288 sd_bus_error *error) {
(gdb) l
283
284 int mac_selinux_unit_access_check_strv(char **units,
285 sd_bus_message *message,
286 Manager *m,
287 const char *permission,
288 sd_bus_error *error) {
289 #ifdef HAVE_SELINUX
290 char **i;
291 Unit *u;
292 int r;
(gdb) n
294 STRV_FOREACH(i, units) {
(gdb) n
295 r = manager_load_unit(m, *i, NULL, error, u);
(gdb) s
manager_load_unit (m=0x7f533a07c680, name=0x7f533a11ef30 test.service,
path=0x0, e=0x7ffe80abaec0, _ret=0x7ffe80abad80) at src/core/manager.c:1369
1369assert(m);
(gdb) n
1374r = manager_load_unit_prepare(m, name, path, e, _ret);
(gdb) n
1375if (r != 0)
(gdb) n
1378manager_dispatch_load_queue(m);
(gdb) p r
$1 = 0
Here variable r has a return value of manager_load_unit_prepare() and
its value is 0 here, meaning that now there's no unit file with the
requested unit file name in the unit hash table.
(gdb) p *_ret
$2 = (Unit *) 0x7f533a166ea0
(gdb) p *_ret-load_state
Attempt to take contents of a non-pointer value.
(gdb) p (*_ret)-load_state
$3 = UNIT_STUB
Actually, its load_state is still UNIT_STUB.
(gdb) n
1380if (_ret)
(gdb) p (*_ret)-load_state
$4 = UNIT_LOADED
After dipatching the load queue by manager_dispatch_load_queue(), the
given unit file has just been loaded and the load_state has been
changed into UNIT_LOADED.
(gdb) finish
Run till exit from #0 manager_load_unit (m=0x7f533a07c680,
name=0x7f533a11ef30 test.service, path=0x0, e=0x7ffe80abaec0,
_ret=0x7ffe80abad80) at src/core/manager.c:1380
0x7f5339807a6a in mac_selinux_unit_access_check_strv
(units=0x7f533a1324f0, message=0x7f533a166a10, m=0x7f533a07c680,
permission=0x7f533992bdb6 enable, error=0x7ffe80abaec0) at
src/core/selinux-access.c:295
295 r = manager_load_unit(m, *i, NULL, error, u);
(gdb) continue
Also, I used selinux-context branch of
https://github.com/keszybz/systemd.git in this test to avoid the issue
in https://bugzilla.redhat.com/show_bug.cgi?id=1224211.
--
Thanks.
HATAYAMA, Daisuke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: fix missing SELinux unit access check
From: Lennart Poettering lenn...@poettering.net
Subject: Re: [systemd-devel] [PATCH] selinux: fix missing SELinux unit access
check
Date: Mon, 8 Jun 2015 12:37:14 +0200
On Mon, 08.06.15 19:00, HATAYAMA Daisuke (d.hatay...@jp.fujitsu.com) wrote:
Currently, SELinux unit access check is not performed if a given unit
file has not been registered in a hash table. This is because function
manager_get_unit() only tries to pick up a Unit object from a Unit
hash table. Instead, we use function manager_load_unit() searching
Unit file pathes for the given Unit file.
Were precisely is this relevant? I mean, we generally invoke
operations on units that are already loaded?
The SELinux unit access check is performed in terms of the following rule:
~]# sesearch -A -s init_t | grep systemd_unit_file_type | grep service
allow init_t systemd_unit_file_type : service { start stop status reload
kill load enable disable } ;
where systemd_unit_file_type is the attribute that is assigned to
context types that unit files have, e.g. systemd_unit_file_t.
Because this SELinux unit access check uses context types that unit
files have, we need to be able to refer to given unit files when we
perform requested unit operations.
Here's how to reproduce this issue. Note that:
- the systemd used here is with the fixing patch, and
- test.service has not been loaded (even tried to get loaded)
throughout this boot to guarantee that test.service is not registered
in the unit hash table.
Then,
~]# cat ./test.service
[Unit]
Description=test
[Service]
Type=oneshot
ExecStart=/usr/bin/true
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
~]# cat ./foo.sh
#! /bin/sh
mv test.service /etc/systemd/system
systemctl daemon-reload
systemctl enable test.service
~]# ./foo.sh
Then, here is a gdb log:
break mac_selinux_unit_access_check_strv
Breakpoint 1 at 0x7f5339807a28: file src/core/selinux-access.c, line 288.
(gdb) continue
Continuing.
Detaching after fork from child process 2198.
Breakpoint 1, mac_selinux_unit_access_check_strv (units=0x7f533a1324f0,
message=0x7f533a166a10, m=0x7f533a07c680, permission=0x7f533992bdb6 enable,
error=0x7ffe80abaec0) at src/core/selinux-access.c:288
288 sd_bus_error *error) {
(gdb) l
283
284 int mac_selinux_unit_access_check_strv(char **units,
285 sd_bus_message *message,
286 Manager *m,
287 const char *permission,
288 sd_bus_error *error) {
289 #ifdef HAVE_SELINUX
290 char **i;
291 Unit *u;
292 int r;
(gdb) n
294 STRV_FOREACH(i, units) {
(gdb) n
295 r = manager_load_unit(m, *i, NULL, error, u);
(gdb) s
manager_load_unit (m=0x7f533a07c680, name=0x7f533a11ef30 test.service,
path=0x0, e=0x7ffe80abaec0, _ret=0x7ffe80abad80) at src/core/manager.c:1369
1369assert(m);
(gdb) n
1374r = manager_load_unit_prepare(m, name, path, e, _ret);
(gdb) n
1375if (r != 0)
(gdb) n
1378manager_dispatch_load_queue(m);
(gdb) p r
$1 = 0
Here variable r has a return value of manager_load_unit_prepare() and
its value is 0 here, meaning that now there's no unit file with the
requested unit file name in the unit hash table.
(gdb) p *_ret
$2 = (Unit *) 0x7f533a166ea0
(gdb) p *_ret-load_state
Attempt to take contents of a non-pointer value.
(gdb) p (*_ret)-load_state
$3 = UNIT_STUB
Actually, its load_state is still UNIT_STUB.
(gdb) n
1380if (_ret)
(gdb) p (*_ret)-load_state
$4 = UNIT_LOADED
After dipatching the load queue by manager_dispatch_load_queue(), the
given unit file has just been loaded and the load_state has been
changed into UNIT_LOADED.
(gdb) finish
Run till exit from #0 manager_load_unit (m=0x7f533a07c680, name=0x7f533a11ef30
test.service, path=0x0, e=0x7ffe80abaec0, _ret=0x7ffe80abad80) at
src/core/manager.c:1380
0x7f5339807a6a in mac_selinux_unit_access_check_strv (units=0x7f533a1324f0,
message=0x7f533a166a10, m=0x7f533a07c680, permission=0x7f533992bdb6 enable,
error=0x7ffe80abaec0) at src/core/selinux-access.c:295
295 r = manager_load_unit(m, *i, NULL, error, u);
(gdb) continue
Signed-off-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
We don't use S-o-b in systemd.
Sorry, I'll not use the tag next. I decided to use it becuase I found
commits with the tag in git log (of course, I found the commits
without the tag, too).
--
Thanks.
HATAYAMA, Daisuke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
Filipe Brandenburger [2015-06-09 12:55 -0700]: I think a more productive advice would be for reviewers to avoid using line comments for anything that is wanted for posterity and instead only use them to say typo or comment here or to point out what exactly in the code the comment on the main thread is making reference to. Wouldn't you think that would be preferrable? FWIW, I don't like it that much either, but so far I still find this the best compromise. Creating and keeping track of multiple PRs and issues even for simple patches where there's a typo or a small style bugs is more unwieldy than losing the line comments IMHO. That said, I'll abide to Lennart's final decision to that of course. 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
