Re: [systemd-devel] sdbus errors and their underlaying int value: unique?

2021-03-04 Thread Cristian Rodríguez
On Tue, Mar 2, 2021 at 7:55 AM Carlo Wood  wrote:

> On Tue, 2 Mar 2021 10:40:25 +0100
> Carlo Wood  wrote:
>
> > I'm not writing my own C++ wrappers around sbus.
>
> I'm now* writing my own C++ wrappers around sbus.
>
>
JUst curious..what is wrong with QTDbus.. ? I strongly suggest you against
the path of reinventing this particular wheel.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Looking for known memory leaks ... [ISOLATED?]

2021-02-25 Thread Cristian Rodríguez
>
>
>
>   $ systemctl status $$
>
>   They wrote a tight loop that just kept calling that command,
>

I just did and memory use remain constant, so whatever your problem is I
cannot reproduce or was fixed ages ago.

A noticeable memory leak should be easily reproducible and fixed building
systemd with asan and running your tests.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

2021-02-22 Thread Cristian Rodríguez
On Mon, Feb 22, 2021 at 8:22 AM Robert P. J. Day 
wrote:

> On Thu, 18 Feb 2021, Lennart Poettering wrote:
>
> > On Do, 18.02.21 11:48, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
> >
> > >   A colleague has reported the following apparent issue in a fairly
> > > old (v230) version of systemd -- this is in a Yocto Project Wind River
> > > Linux 9 build, hence the age of the package.
> > >
> > >   As reported to me (and I'm gathering more info), the system was
> > > being put through some "longevity testing" by repeatedly adding,
> > > removing, activating and de-activating network interfaces. According
> > > to the report, the result was heap space slowly but inexorably being
> > > consumed.
> > >
> > >   While waiting for more info, I'm going to examine the commit log for
> > > systemd from v230 moving forward to collect any commits that address
> > > memory leaks, then peruse them more carefully to see if they might
> > > resolve the problem.
> > >
> > >   I realize it's asking a bit for folks here to remember that far
> > > back, but does this issue sound at all familiar? Any pointers that
> > > might save me some time? Thanks.
> >
> > Note that our hash tables operate with an allocation cache: when
> > adding entries to them and then removing them again the memory
> > required for that is not returned to the OS but added to a local
> > cache. When the next entry is then added again, we recycle the
> > cached entry instead of asking for new memory again. This allocation
> > cache is a bit quicker then going to malloc() all the time, but
> > means if you just watch the heap you'll assume there's a leak even
> > though there isn't really, the memory is not lost after all, and
> > will be reused eventually if we need it.
> >
> > You may use the env var SYSTEMD_MEMPOOL=0 to turn this logic off,
> > but not sure v230 already knew that env var.
>
>   well, we seem to have isolated the issue, here it is in a nutshell
> based on a condensed note i got from someone who tracked it down this
> weekend. the memory leak is triggered by:
>
>   $ ssh root@ -p 830 -s netconf   [830 = netconf over SSH]
>
> long story short, according to jemalloc profiling, there is a massive
> memory leak in DBUS code,


Ok, give that data to whoever supports your system.. you are not giving us
anything useful..
Now.. Can it have memory leaks ? yeah, it could, however I have reviewed
the code (Admit a long time ago) and leaks on the systemd binaries are
usually limited to error paths not exercised often and frankly in the path
to extinction.

What you see most of time are not leaks in the code, but leaks in
understanding of memory management techniques.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Should services be able to run without /proc?

2021-02-10 Thread Cristian Rodríguez
Glibc needs /proc mounted so the answer is no.

El El mar, 9 de feb. de 2021 a la(s) 12:05, Antonius Frie <
antonius.f...@ruhr-uni-bochum.de> escribió:

> Hi!
>
> So this is kind of a follow-up to the thread in [1], and the
> corresponding PR in [2].
>
> In short, the PR made some changes to allow for cases where /proc was
> not available in the mount namespace of the service, and added a test
> [3] to make sure that this would work. This test was later removed and
> rewritten to block /sys instead [4], because it turned out that having
> /proc unavailable sometimes caused problems with close_all_fds(), which
> is called in exec_child() after namespaces have been set up.
>
> On current master, services that don't have /proc mounted don't work at
> all anymore, since find_executable_full() ends up opening the given path
> and calling access_fd() on the resulting fd, and access_fd uses
> /proc/self/fd/* to turn the fd back into a path it can call access() on.
> As far as I can tell, the reason for not using access on the path
> directly is that access_fd is more elegant since it avoids a potential
> race condition.
>
> In addition to this, setup_private_users() also needs access to
> /proc/$pid/{uid_map, gid_map, setgroups} to do its job.
>
> Given all this, I guess my question is whether it is still desirable to
> allow units to run without /proc, especially given that ProtectProc and
> ProcSubset exist now.* If not, it might be nice to just always mount
> /proc if it wouldn't otherwise be there (i.e. if RootImage/RootDirectory
> is used); currently, MountAPIVFS=yes is basically a required option
> because of this. (I guess you could mount proc manually, but then you
> can't use ProtectProc/ProcSubset.) I'm a bit unhappy about this, because
> MountAPIVFS also mounts /sys and /dev, and then you need separate
> options just to protect those again. Either way, maybe it would be good
> to explicitly state this requirement in the documentation?
>
> Anyway, I hope that this was okay to post here, I don't really know a
> lot about this and maybe there are good reasons for why things are the
> way they are. I'd be happy about feedback though.
>
> Cheers,
> Antonius
>
> * Using both ProtectProc=ptraceable and ProcSubset=pid really doesn't
> let a lot of things through, and I don't think those interfere with any
> of the functions described above. The only thing I'm unsure about is
> setup_private_users(), since that spawns off a child process which then
> goes and writes to /proc/$parent_pid/, but I guess children can ptrace
> their parents? At least it seemed to work when I just tested it.
>
> [1]:
> https://lists.freedesktop.org/archives/systemd-devel/2017-April/038634.html
> [2]: https://github.com/systemd/systemd/pull/5985
> [3]: https://github.com/systemd/systemd/pull/6017
> [4]:
>
> https://github.com/systemd/systemd/commit/054d871d41039fcfc1a4a661c979941b9660c9e6
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Is LTO worth it?

2021-01-20 Thread Cristian Rodríguez
On Mon, Jan 11, 2021 at 12:39 PM Lennart Poettering
 wrote:


> https://fedoraproject.org/wiki/LTOByDefault
>
> (I think Suse is even further ahead on this)

Yes. lto is already on by default, on worthiness of t..the jury is still out..
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-timesyncd - use unprivileged ports

2020-03-22 Thread Cristian Rodríguez
On Wed, Mar 11, 2020 at 4:17 PM Jędrzej Dudkiewicz
 wrote:

> Sorry, of course source port -

No, you really want UDP source port randomization using whatever
algorithm the kernel chooses to, due to security reasons.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] perform fsck on everyt boot

2019-12-06 Thread Cristian Rodríguez
On Mon, Nov 11, 2019 at 9:34 AM Belisko Marek  wrote:
>
Am I still
> missing something? Thanks.

Yes, what you are trying to do is the wrong thing(tm) to do, please
figure out why there is filesystem corruption in the first place,
while ext4 of course has bugs like any software around, it is not
known for being fragile. I'd bet money on the SD card being crappy.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] EXT: sdbus_event loop state mark as volatile?

2019-09-09 Thread Cristian Rodríguez
> >while (e->state != SD_EVENT_FINISHED) {
> >r = sd_event_run(e, (uint64_t) -1);
> >
> > But since e->state is changed by another thread it

Well..then the game is up because sd-bus does not claim to be thread
safe or even aspires to be..  accessing e from different threads will
cause unspecified behaviour.

In any case this patch is not quite what is needed to make it safe.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] MongoDB error after the changing the Path

2019-01-09 Thread Cristian Rodríguez



El 09-01-2019 a las 10:35, hemanthkuma...@vakilsearch.com escribió:

Hi All,

I am facing the problem in MongDB after the Path. So help me ti sort the 
issue


[root@ca-mongo mongo]# cat /etc/mongod.conf




Please ask in mongodb users list, this problem has nothing to do with 
systemd development.


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


Re: [systemd-devel] How to add a second bridge to a nspawn container?

2019-01-04 Thread Cristian Rodríguez



El 04-01-2019 a las 2:50, Mantas Mikulėnas escribió:


That's because the specified interface is not a bridge...



Yeah, that and it is a wireless interface..it may not work .. OP needs 
to use ipvlan instead.

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


Re: [systemd-devel] Systemd logging..

2018-11-22 Thread Cristian Rodríguez



El 21-11-2018 a las 11:08, deepan muthusamy escribió:


 > Can u please tell me what are all the things I have to add in .service

file to store all logs into a log file.


Some daemons provide an option to log to file, use that if available, 
otherwise make your program write debug or log messages to stderr and 
the journal will capture it.. then you can extract them to a text file.


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


Re: [systemd-devel] Environment-variable security?

2018-11-13 Thread Cristian Rodríguez



El 13-11-2018 a las 9:49, David Parsley escribió:
I disagree; privacy of environment variables to individual users on the 
system is as fundamental as Unix file permissions.


Please find us ONE reference to a relevant, current *nix standard that 
says environment variables are either secret, suitable for secrets, 
private or the system is expected to treat them as such.


Breaking news.. no such requirement or even suggestion exists, 
environment variables just work this way. No need to be so stubborn when 
the world does not work the way you want to..just find a different 
proper solution to fix the problem.








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


Re: [systemd-devel] Data flow is slow

2018-11-09 Thread Cristian Rodríguez



El 09-11-2018 a las 1:08, deepan muthusamy escribió:
I created a session bus as system service. And iam connecting to that 
session bus. My requirement is like this, that's why I'm doing this.@ Simon.


Well..considering that Simon literally wrote the dbus daemon I will 
certainly listen to what he is saying on the matter.. So I will repeat 
what he said once again.. system services are not part of a session.. 
when you "start them manually" your shell is.



There is no test program for this. App2 should return the data to app1 
and app1 should show Change in UI. this whole thing taking long time. @ 
Mantas


I do not know if there is a language barrier or what.. but your posts 
are not conductive to give you any help whatsoever.. you provide no hard 
data to look at, error messages, what exactly is taking a crapload of 
time..

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


Re: [systemd-devel] Systemd service taking huge memory

2018-11-08 Thread Cristian Rodríguez



El 08-11-2018 a las 11:02, deepan muthusamy escribió:
If I start my application as system service, it is consuming huge 
memory. This leads to my system getting slow down.

If I start manually, it's not consuming that much memory.

What can be the possible reasons?


Your application has a memory leak on a path that is only excercised 
when started as a permanently running application..hard to tell without 
a concrete example and memory usage data.. use


#pmap $(pidof yourprogram)
and see if the PSS size keeps growing or what.

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


Re: [systemd-devel] A question about the race condition between two service

2018-11-06 Thread Cristian Rodríguez



El 05-11-2018 a las 3:17, piliu escribió:


During this service, the power state can not be got from sysfs, neither
it can be got by systemd's utility. So is it acceptable to signal the
failure of service by a tmp file under /tmp ? I.e adding
FailureAction=touch /tmp/poweroff_fail in systemd-poweroff.service.


No, that will likely race too.. please focus on why you think you need 
this contrieved,hackish solution.


If as you say in your other message, if you start just one operation, 
either reboot or poweroff but not both it will be ok.





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


Re: [systemd-devel] A question about the race condition between two service

2018-11-05 Thread Cristian Rodríguez



El 01-11-2018 a las 5:34, piliu escribió:


Any suggestion?



Yeah. Don't..if poweroff fails reboot will too..please attack the root 
cause of this problem.. why the machine fails to poweroff, is it a 
service blocking poweroff ? is there a kernel bug ?

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


Re: [systemd-devel] Run OpenVPN unprivileged as systemd user service

2018-11-01 Thread Cristian Rodríguez



El 01-11-2018 a las 9:41, Paul Menzel escribió:



If yes, do you have any hints before I start to dig into that?


opening TUN/TAP interfaces and changing routing is a privileged operation.

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


Re: [systemd-devel] bpfilter blocks root unmount during shutdown

2018-09-25 Thread Cristian Rodríguez



El 24-09-2018 a las 13:30, Andrei Borzenkov escribió:


This process is spawned as special kernel thread, even though it is
otherwise normal user process.


WUT ? So how is this new kind of task supposed to be handled by 
userspace ? looks like a kernel bug to me.




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


Re: [systemd-devel] How to build only udev

2018-07-04 Thread Cristian Rodríguez



El 04-07-2018 a las 15:42, Kevin Greene escribió:
Thanks Simon. I have tried doing that actually, but the arm64 version 
doesn't seem to be available. I'm on Ubuntu 16.04 fwiw.


Are you entirely sure that's the case?.. I mean.. you do not go very far 
without libudev-dev in a modern binary distribution like Ubuntu..pretty 
sure it must be available..


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


Re: [systemd-devel] [ty...@mit.edu: Re: Linux messages full of `random: get_random_u32 called from`]

2018-05-02 Thread Cristian Rodríguez



El 02-05-2018 a las 6:25, Lennart Poettering escribió:

On Di, 01.05.18 18:08, Vito Caputo (vcap...@pengaru.com) wrote:



Or maybe this confusion is just another iteration of the stuff
dicussed here? https://github.com/systemd/systemd/issues/4167


On modern x86 hardware we could fallback to rdrand but only when 
getrandom returns EAGAIN.


For other non-cryptographic uses maybe implementing xoroshiro128+ or 
Mersenne Twister would suffice, until libc gets a sane random interface 
if ever.

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


Re: [systemd-devel] SSL handshake error from offlineimap when using systemd to initialize

2018-01-22 Thread Cristian Rodríguez



El 21-01-2018 a las 8:12, Yubin Ruan escribió:

Hi,

I use offlineimap to synchronize my emails. I want it to do a synchronization
at system startup so recently I add a systemd service for it. However I always
get error like this:

EOF occurred in violation of protocol (_ssl.c:590)


Socket was closed but not the SSL session.. not a systemd problem..


Currently I don't know what the problem is, but:

 1. usually (after system startup) the same service is invoked by a timer
 and it works well so there is no problem with the script.


It is racing against initial network setup.. once the network settles it 
works as expected.




 2. I believe the network is reachable, because the system will
 auto-connect WIFI after system startup. Maybe the initialization order is
 not configured properly? If so please see my mail service file below.


You may want to order your services after network-online and enable the 
systemd-network-online service.. however that may still race.


I heard that to perform a SSL handshake the system have to contain some
randomness (such that some random keys can be generated),


Correct, but any of the ssl libraries in linux will inmediately return 
or terminate the process in case of a entropy failure, because such 
failure is fatal and the whole security of the ssl session is screwed.




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


Re: [systemd-devel] Packagekit crashes

2017-09-08 Thread Cristian Rodríguez



El 08-09-2017 a las 16:58, Robert Washbourne escribió:

On systemctl start packagekit:

packagekitd[18300]: failed to setup context: metadata expire time too 
small, has to be at least one second




I'm sorry if this is the wrong place to post, please point me in the 
right direction




Polkit is not part of systemd, ask on: 
http://lists.freedesktop.org/mailman/listinfo/polkit-devel list.


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


[systemd-devel] [PATCH] shared: add statx(2) to @file-system syscall filter list

2017-09-02 Thread Cristian Rodríguez
---
 src/shared/seccomp-util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/shared/seccomp-util.c b/src/shared/seccomp-util.c
index 29eb2b17d..0857f5907 100644
--- a/src/shared/seccomp-util.c
+++ b/src/shared/seccomp-util.c
@@ -403,6 +403,7 @@ const SyscallFilterSet 
syscall_filter_sets[_SYSCALL_FILTER_SET_MAX] = {
 "stat64\0"
 "stat\0"
 "statfs\0"
+"statx\0"
 "symlink\0"
 "symlinkat\0"
 "truncate64\0"
-- 
2.14.1

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


Re: [systemd-devel] systemd-udevd invoked oom-killer

2017-07-11 Thread Cristian Rodríguez


El 11-07-2017 a las 18:23, WANG Siyuan escribió:
> Hi, all
> systemd-udevd invoked oom-killer during Linux boot. I open debug message
> of systemd-udevd. But I can't find where the problem is. Could anybody
> help me? Thanks very much.

The oom-killer should never be invoked on udev at boot.. either you are
working in very memory constrained device or there is a problem in your
kernel/toolchain/etc build.

At least tell use what distribution are you using if any and/or what
systemd version, you could also disable the oom-killer on
systemd-udev.service..




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


Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Cristian Rodríguez


El 20-03-2017 a las 10:26, D.S. Ljungmark escribió:
> I find your argument to be strange.
> 
> "The kernel has this functionality, please do not use it and rather
> reimplement it in every piece of userspace that ever needs it, because
> that's supposed to be more secure."
> 
> I simply don't buy your argument here.

I guess we can't please everyone.. next it will come the "systemd has
too many library dependencies" crowd :-|


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


Re: [systemd-devel] Systemctl causes Spark native thread creation issue

2017-02-20 Thread Cristian Rodríguez


El 20-02-2017 a las 18:44, Rao Vz escribió:
> Hi, Guys

> Any help is appreciated.
> 
Most likely you went over TasksMax.


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


Re: [systemd-devel] MYSQL SERVICE FAILED

2016-05-01 Thread Cristian Rodríguez
On Sat, Apr 30, 2016 at 3:32 PM, Alessandro Cellini  wrote:
> ***

> -- Unit mysql.service has failed.
> --
> -- The result is failed.


HI:

Neither the mysql package nor the mysql.service are provided by the
systemd project but by your distribution. please file a bug report if
one does not exists by the proper channels.

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


Re: [systemd-devel] about libmount

2015-11-05 Thread Cristian Rodríguez
On Thu, Nov 5, 2015 at 12:30 PM, Martin Pitt  wrote:
> Hello Yankun,
>
> yan...@iscas.ac.cn [2015-11-05 23:24 +0800]:
>> I can not find a available uri for systemd in china
>
> Sorry, but I don't understand at all what this means.

It may be blocked by internet censors..is that what you mean ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 3.7s for systemd-logind.service starting

2015-07-03 Thread Cristian Rodríguez
On Fri, Jul 3, 2015 at 5:00 AM, RayBloodworth k870818...@outlook.com wrote:

  From this boot chart, dbus.service starts after systemd-logind.service, but
 dbus.service takes littile time for launching.

This is a bug, fixed in v209.. commit
8f9c6fe5ff1d59001aecbf3fbf9ca0ed7ff28ba7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 3.7s for systemd-logind.service starting

2015-07-03 Thread Cristian Rodríguez
On Fri, Jul 3, 2015 at 2:05 AM, RayBloodworth k870818...@outlook.com wrote:
 Hi, everyone

 I'm optimizing booting performance of my system.

 systemd version: 208
 platform: freescale i.MX6D Cortex-A9

Please test again with a current release, I doubt anyone here will
help if you are using an older release.


 I found systemd-logind.service takes about 3.7s for starting.
 Then I added many logs about system time and found that method
 manager_connect_bus() in logind.c takes 2.4718s.

 Method dbus_bus_get_private() in  manager_connect_bus()  blocks 2.3s
 ...

 Could anyone help me with this issue?

Your system is most likely overwhelmed by I/O
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] SysVInit service migration to systemd

2015-06-29 Thread Cristian Rodríguez
On Mon, Jun 29, 2015 at 10:58 AM, Lesley Kimmel ljkimme...@hotmail.com wrote:
 Jonathan;

 Thanks for the background and information. Since you clearly seem to have a
 grasp of systemd please humour me with a few more questions (some of them
 slightly ignorant):

 a) Why are PID bad?

Because they pretend to work but they really don't.
This is because only a tiny portion of software implements pid file
creation correctly,
this is in part due to the lack of a FREEBSD-like pidfile_*()
interface that at least tries to be correct.

 b) Why are lock files bad?

Mostly because at least till the *very recent* advent of File-private
POSIX locks (un-POSIX locks)
the OS facilities were terrible.

 c) If a/b are so bad why did they persist for so many years in SysVInit?

Because sysvinit is unable to track processes, in that case you need
at least to know what is the PID of the deamon, in order to be able to
kill it:
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Weird udev issue: char device replaced by regular file on suspend

2015-06-25 Thread Cristian Rodríguez
On Thu, Jun 25, 2015 at 4:15 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote:
 Hi list,

 I'm seeing a very odd issue with udev and I'm not really sure which
 component could/would be responsible -- udev is pretty much my only hope.


Probably GregKH can assist you with this problem, udev is not at fault
because it does not create device nodes since the advent of devtmpfs
and this is therefore a kernel bug.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Why we need to read/save random seed?

2015-06-15 Thread Cristian Rodríguez
On Mon, Jun 15, 2015 at 12:33 PM, cee1 fykc...@gmail.com wrote:
 Hi,

 I maybe got confused.

 First, systemd-random-seed.service will save a seed from
 /dev/urandom when shutdown, and load that seed to /dev/urandom when
 next boot up.

 My questions are:
 1. Can we not save a seed, but load a seed that is read from **
 /dev/random ** to ** /dev/urandom **?

No, at boot you do not have enough entropy to begin with.

 2. Saving a seed on disk, and someone reads the content of it later,
 will this make the urandom predictable?

Yes, that's why the file is only readable by root.

 Talking about /dev/random, it consumes an internal entropy pool, some
 system events(disk reading/page fault, etc) enlarges this pool, am I
 right?

See this article http://www.2uo.de/myths-about-urandom/

 And write to /dev/random will mix the input data into the pool, but
 not enlarge it, right?

It is up to the kernel to credit the data written to it as entropy (or not)

  What benefits can it get when only mix data
 but not enlarge the entropy pool?

The data written to it may be predictable..

 3.16+ will mix data from HWRNG, does it also enlarges the entropy pool?

Yes but it might not be given credit depending what the source is.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Why we need to read/save random seed?

2015-06-14 Thread Cristian Rodríguez
El jun. 14, 2015 10:21, cee1 fykc...@gmail.com escribió:

 Hi all,

 Why we need to read/save random seed? Can it be read from /dev/random
each time?

Because the kernel is borked and still is needs to be fed of entropy at
system startup by user space. Please read the random man page.

I agree we shouldn't have to do this at all..

 --
 Regards,

 - cee1
 ___
 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] Why we need to read/save random seed?

2015-06-14 Thread Cristian Rodríguez
On Sun, Jun 14, 2015 at 1:43 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote:

 El jun. 14, 2015 10:21, cee1 fykc...@gmail.com escribió:
 
  Hi all,
 
  Why we need to read/save random seed? Can it be read from /dev/random each
 time?

 Because the kernel is borked and still is needs to be fed of entropy at 
 system
 startup by user space. Please read the random man page.

 I agree we shouldn't have to do this at all..

 Really?  And how do you suggest we fix the kernel when the hardware
 itself doesn't provide us with a proper random number seed in the
 first place?  What do you suggest we do instead?

Las time I checked , it required this userspace help even when the
machine has rdrand/rdseed or when a virtual machine is fed from the
host using the virtio-rng driver.. (may take up to 60 seconds to
report
random: nonblocking pool is initialized) Any other possible solution
that I imagined involves either blocking and/or changes in the
behaviour visible to userspace and that is probably unacceptable
.
The random-seed tool also does not increment the entropy count (It
writes to /dev/random instead of using the ioctls) so the ultimate
result is still a system with very little entropy to go on, only
starting rngd or haveged *very* early in the boot sequence seem to
help.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Why we need to read/save random seed?

2015-06-14 Thread Cristian Rodríguez
On Sun, Jun 14, 2015 at 6:45 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Sun, Jun 14, 2015 at 02:11:53PM -0300, Cristian Rodríguez wrote:
 On Sun, Jun 14, 2015 at 1:43 PM, Greg KH gre...@linuxfoundation.org wrote:
  On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote:
 
  El jun. 14, 2015 10:21, cee1 fykc...@gmail.com escribió:
  
   Hi all,
  
   Why we need to read/save random seed? Can it be read from /dev/random 
   each
  time?
 
  Because the kernel is borked and still is needs to be fed of entropy at 
  system
  startup by user space. Please read the random man page.
 
  I agree we shouldn't have to do this at all..
 
  Really?  And how do you suggest we fix the kernel when the hardware
  itself doesn't provide us with a proper random number seed in the
  first place?  What do you suggest we do instead?

 Las time I checked , it required this userspace help even when the
 machine has rdrand/rdseed or when a virtual machine is fed from the
 host using the virtio-rng driver.. (may take up to 60 seconds to
 report
 random: nonblocking pool is initialized) Any other possible solution
 that I imagined involves either blocking and/or changes in the
 behaviour visible to userspace and that is probably unacceptable
 .

 Really?

Yes, this is why for example you will find an haveged dracut module
that SUSE added during the SLE 12 development. to start entropy feed
from user-space as early as possible
this is not because folks are crazy but because it took  way too long
to initialize at that time..

A lot of changes went into seeding the initial random generator
 in the kernel in the past year, you might want to try it out again.

Sure, I will check it again..

 The random-seed tool also does not increment the entropy count (It
 writes to /dev/random instead of using the ioctls) so the ultimate
 result is still a system with very little entropy to go on, only
 starting rngd or haveged *very* early in the boot sequence seem to
 help.

 Then why not fix the random-seed tool to use the correct interface?

yeah, I think we should take a look on this too.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Performance of systemctl status tab completion

2015-06-02 Thread Cristian Rodríguez
On Tue, Jun 2, 2015 at 1:18 PM, Chris Morgan chmor...@gmail.com wrote:
 Hi all.

 systemd 216 here on an embedded arm system, 1ghz with a load of 60% or
 more. I enabled tab completion, because I really don't like to type,
 and quickly found out that something like:

 systemctl status xxtab tab

What shell are you using ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemctl as non-root

2015-05-28 Thread Cristian Rodríguez
On Thu, May 28, 2015 at 9:21 PM,  aaron_wri...@selinc.com wrote:
 Brandon Philips bran...@ifup.co wrote on 05/28/2015 05:10:33 PM:
 Access to the system dbus is controlled by dbus policies. You will
 need to write a policy for giving this user access to the systemd1 object.


 I compiled systemd without dbus support (--disable-dbus), and there is no
 dbus daemon or dbus lib on the system.

That's not what --disable-dbus means..please read the configure description..
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to wait for specific interface/IP?

2015-05-23 Thread Cristian Rodríguez
On Sat, May 23, 2015 at 1:03 PM, Ian Pilcher arequip...@gmail.com wrote:
 Is there a simple way to make a service require that a specific network
 interface/IP address be active?

You have to wait for the *link* to be active, not for the interface..

 I have a manually set up bridge and dnsmasq configuration for my VM
 traffic, but dnsmasq is getting started before NetworkManager has
 configured the bridge and failing because it cannot bind to the bridge's
 IP address.

This is problem has more than one face..

1) Enable the NetworkManager-wait-online service
2) order dnsmasq after the network-online target.

But this is all a workaround.. you could configure dnsmasq not to fail
to bind on interfaces that are not yet available at the point the
daemon is started.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] core: if PR_SET_CHILD_SUBREAPER fails, log_error instead of warning

2015-05-23 Thread Cristian Rodríguez
It was a warning when we still supported kernel  3.4. current
minimum version is 3.7.
---
 src/core/main.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/core/main.c b/src/core/main.c
index c39815b..3bebc98 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1608,9 +1608,7 @@ int main(int argc, char *argv[]) {
 if (arg_running_as == MANAGER_USER) {
 /* Become reaper of our children */
 if (prctl(PR_SET_CHILD_SUBREAPER, 1)  0) {
-log_warning_errno(errno, Failed to make us a 
subreaper: %m);
-if (errno == EINVAL)
-log_info(Perhaps the kernel version is too 
old ( 3.4?));
+log_error_errno(errno, Failed to make us a subreaper: 
%m);
 }
 }
 
-- 
2.4.1

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


Re: [systemd-devel] [PATCH] buildsys: remove always true autoconf checks

2015-05-21 Thread Cristian Rodríguez
On Thu, May 21, 2015 at 11:39 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 19.05.15 20:17, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

 All this checks are always true in any modernish linux system.
 ---
  configure.ac | 11 ---
  1 file changed, 11 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 3efee22..cd6375b 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1293,17 +1293,6 @@ AC_CHECK_HEADERS_ONCE([valgrind/memcheck.h 
 valgrind/valgrind.h])
  have_myhostname=no
  AC_ARG_ENABLE(myhostname, AS_HELP_STRING([--disable-myhostname], [disable 
 nss-myhostname support]))
  if test x$enable_myhostname != xno; then
 -AC_HEADER_STDC
 -AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h
 netinet/in.h stdlib.h string.h sys/socket.h sys/time.h unistd.h
 nss.h sys/ioctl.h sys/auxv.h])

 sys/auxv.h at least is a relatively recent addition to glibc, hence
 simply removing this all appears too broad...

Right.. that's an oversight..


 Not sure however why this is in the enable_myhostname part however, it
 should just be moved up. Could you prep a patch that does that?

Sure.. stay tuned ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] buildsys: remove always true autoconf checks

2015-05-19 Thread Cristian Rodríguez
All this checks are always true in any modernish linux system.
---
 configure.ac | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3efee22..cd6375b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1293,17 +1293,6 @@ AC_CHECK_HEADERS_ONCE([valgrind/memcheck.h 
valgrind/valgrind.h])
 have_myhostname=no
 AC_ARG_ENABLE(myhostname, AS_HELP_STRING([--disable-myhostname], [disable 
nss-myhostname support]))
 if test x$enable_myhostname != xno; then
-AC_HEADER_STDC
-AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h netinet/in.h 
stdlib.h string.h sys/socket.h sys/time.h unistd.h nss.h sys/ioctl.h 
sys/auxv.h])
-
-AC_C_CONST
-AC_TYPE_SIZE_T
-AC_HEADER_TIME
-
-AC_FUNC_MALLOC
-AC_FUNC_SELECT_ARGTYPES
-AC_CHECK_FUNCS([gethostbyaddr gethostbyname gettimeofday inet_ntoa 
memset select socket strcspn strdup strerror strncasecmp strcasecmp strspn])
-
 have_myhostname=yes
 fi
 AM_CONDITIONAL(HAVE_MYHOSTNAME, [test $have_myhostname = yes])
-- 
2.4.1

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


Re: [systemd-devel] Reduce unit-loading time

2015-05-19 Thread Cristian Rodríguez
On Mon, May 18, 2015 at 7:24 AM, cee1 fykc...@gmail.com wrote:
 2015-05-17 17:45 GMT+08:00 Martin Pitt martin.p...@ubuntu.com:
 Hello cee,

 cee1 [2015-05-16  0:46 +0800]:
 Thanks for the suggestion, it was other processes running in parallel
 which presumably consuming lots of IO, after sending SIGSTOP at the
 first (and SIGCONT later), the unit loading time is decreased to
 ~100ms.

 You probably want to use some readahead solution. We found that it
 makes a significant improvement on ARM boards with slow MMC cards.

You could also

posix_fadvise(fileno(f), 0, 0, POSIX_FADV_SEQUENTIAL);
in the bits that load the unit file..the kernel is free to ignore that
advice however.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Reduce unit-loading time

2015-05-19 Thread Cristian Rodríguez
On Tue, May 19, 2015 at 5:39 PM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
 On Mon, May 18, 2015 at 7:24 AM, cee1 fykc...@gmail.com wrote:
 2015-05-17 17:45 GMT+08:00 Martin Pitt martin.p...@ubuntu.com:
 Hello cee,

 cee1 [2015-05-16  0:46 +0800]:
 Thanks for the suggestion, it was other processes running in parallel
 which presumably consuming lots of IO, after sending SIGSTOP at the
 first (and SIGCONT later), the unit loading time is decreased to
 ~100ms.

 You probably want to use some readahead solution. We found that it
 makes a significant improvement on ARM boards with slow MMC cards.

 You could also

 posix_fadvise(fileno(f), 0, 0, POSIX_FADV_SEQUENTIAL);
 in the bits that load the unit file..the kernel is free to ignore that
 advice however.

This however.. won't be of any help, as the default readhead window is
128kb.. which is way bigger than any unit file.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] resolved crashes on SIGTERM

2015-05-18 Thread Cristian Rodríguez
On Mon, May 18, 2015 at 6:25 PM, Lennart Poettering
lenn...@poettering.net wrote:

 Fixed in git. Please verify.

It is OK now.. Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] buildsys: Remove X_SERVER from AM_CPPFLAGS

2015-05-16 Thread Cristian Rodríguez
It is a leftover from multi-seat-x wrapper which is long
gone.
---
 Makefile.am | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 211ce6a..4639b2f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -203,7 +203,6 @@ AM_CPPFLAGS = \
-DSYSTEM_SLEEP_PATH=\$(systemsleepdir)\ \
-DSYSTEMD_KBD_MODEL_MAP=\$(pkgdatadir)/kbd-model-map\ \
-DSYSTEMD_LANGUAGE_FALLBACK_MAP=\$(pkgdatadir)/language-fallback-map\ 
\
-   -DX_SERVER=\$(bindir)/X\ \
-DUDEVLIBEXECDIR=\$(udevlibexecdir)\ \
-DPOLKIT_AGENT_BINARY_PATH=\$(bindir)/pkttyagent\ \
-DQUOTACHECK=\$(QUOTACHECK)\ \
-- 
2.3.7

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


[systemd-devel] [PATCH] timedate: fix memory leak in timedated

2015-05-15 Thread Cristian Rodríguez
$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)

=
==396==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 928 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
#1 0x562a83ae60cf in bus_message_from_header 
src/libsystemd/sd-bus/bus-message.c:480
#2 0x562a83ae6f5a in bus_message_from_malloc 
src/libsystemd/sd-bus/bus-message.c:576
#3 0x562a83ad3cad in bus_socket_make_message 
src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message 
src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method 
src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)

Indirect leak of 77 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
#1 0x562a83ad418a in bus_socket_read_message 
src/libsystemd/sd-bus/bus-socket.c:963
#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#4 0x562a83b1f46d in sd_bus_call_method 
src/libsystemd/sd-bus/bus-convenience.c:94
#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#6 0x562a83aae1af in main src/timedate/timedated.c:730
#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)

Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
#1 0x562a83b0229b in bus_message_parse_fields 
src/libsystemd/sd-bus/bus-message.c:5382
#2 0x562a83ae7290 in bus_message_from_malloc 
src/libsystemd/sd-bus/bus-message.c:601
#3 0x562a83ad3cad in bus_socket_make_message 
src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message 
src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method 
src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)

SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).

This is due to missing  _cleanup_bus_message_unref_ in context_read_ntp()
---
 src/timedate/timedated.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index c5ebb4a..4e8ae94 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -182,7 +182,7 @@ static int context_write_data_local_rtc(Context *c) {
 
 static int context_read_ntp(Context *c, sd_bus *bus) {
 _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
-sd_bus_message *reply = NULL;
+_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
 const char *s;
 int r;
 
-- 
2.3.7

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


Re: [systemd-devel] [PATCH] sd-bus: fix memory leak in test-bus-chat

2015-05-13 Thread Cristian Rodríguez
On Wed, May 13, 2015 at 8:01 AM, Daniel Mack dan...@zonque.org wrote:

 We should still keep this flush, right?

 -sd_bus_unref(bus);
  }


The cleanup function already does :

static inline void sd_bus_close_unrefp(sd_bus **bus) {
   if (*bus) {
   sd_bus_flush(*bus);
   sd_bus_close(*bus);
   sd_bus_unref(*bus);
   }
}

Or I am missing something ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] modules-load: fix memory leak

2015-05-11 Thread Cristian Rodríguez
=
==64281==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f623c961c4a in malloc (/usr/lib64/libasan.so.2+0x96c4a)
#1 0x5651f79ad34e in malloc_multiply 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x2134e)
#2 0x5651f79b02d6 in strjoin 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x242d6)
#3 0x5651f79be1f5 in files_add 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x321f5)
#4 0x5651f79be6a3 in conf_files_list_strv_internal 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x326a3)
#5 0x5651f79bea24 in conf_files_list_nulstr 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x32a24)
#6 0x5651f79ad01a in main 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x2101a)
#7 0x7f623c11586f in __libc_start_main (/lib64/libc.so.6+0x2086f)

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).

This happens due to the wrong cleanup attribute is used (free vs strv_free)
---
 src/modules-load/modules-load.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/modules-load/modules-load.c b/src/modules-load/modules-load.c
index 76e9403..5bbe314 100644
--- a/src/modules-load/modules-load.c
+++ b/src/modules-load/modules-load.c
@@ -252,7 +252,7 @@ int main(int argc, char *argv[]) {
 }
 
 } else {
-_cleanup_free_ char **files = NULL;
+_cleanup_strv_free_ char **files = NULL;
 char **fn, **i;
 
 STRV_FOREACH(i, arg_proc_cmdline_modules) {
-- 
2.3.7

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


[systemd-devel] [PATCH] shared: Use O_EXCL with O_TMPFILE in open_tmpfile

2015-05-11 Thread Cristian Rodríguez
In this usecase, the file will never be materialized
with linkat().
---
 src/shared/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index c5c1b0c..f295edb 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -4838,7 +4838,7 @@ int open_tmpfile(const char *path, int flags) {
 
 #ifdef O_TMPFILE
 /* Try O_TMPFILE first, if it is supported */
-fd = open(path, flags|O_TMPFILE, S_IRUSR|S_IWUSR);
+fd = open(path, flags|O_TMPFILE|O_EXCL, S_IRUSR|S_IWUSR);
 if (fd = 0)
 return fd;
 #endif
-- 
2.3.7

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


[systemd-devel] resolved crashes on SIGTERM

2015-05-11 Thread Cristian Rodríguez
resolved crashes on SIGTERM with ...

=
==33557==ERROR: AddressSanitizer: heap-use-after-free on address
0x60c0bd60 at pc 0x556098c5 bp 0x7fffde70 sp
0x7fffde68
READ of size 8 at 0x60c0bd60 thread T0
   #0 0x556098c4 in dns_cache_flush src/resolve/resolved-dns-cache.c:88
   #1 0x555e123d in link_set_dns_server src/resolve/resolved-link.c:321
   #2 0x55608c7e in dns_server_free src/resolve/resolved-dns-server.c:96
   #3 0x555df543 in link_free src/resolve/resolved-link.c:76
   #4 0x555cf138 in manager_free src/resolve/resolved-manager.c:531
   #5 0x555cb5e7 in manager_freep src/resolve/resolved-manager.h:151
   #6 0x555cbd58 in main src/resolve/resolved.c:32
   #7 0x75d6586f in __libc_start_main (/lib64/libc.so.6+0x2086f)
   #8 0x555cb498 in _start
(/home/crrodriguez/scm/systemd/systemd-resolved+0x77498)

0x60c0bd60 is located 32 bytes inside of 128-byte region
[0x60c0bd40,0x60c0bdc0)
freed by thread T0 here:
   #0 0x76f049aa in __interceptor_free (/usr/lib64/libasan.so.2+0x969aa)
   #1 0x556021a9 in dns_scope_free src/resolve/resolved-dns-scope.c:97
   #2 0x555df4a2 in link_free src/resolve/resolved-link.c:71
   #3 0x555cf138 in manager_free src/resolve/resolved-manager.c:531
   #4 0x555cb5e7 in manager_freep src/resolve/resolved-manager.h:151
   #5 0x555cbd58 in main src/resolve/resolved.c:32
   #6 0x75d6586f in __libc_start_main (/lib64/libc.so.6+0x2086f)

previously allocated by thread T0 here:
   #0 0x76f04db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
   #1 0x55601785 in dns_scope_new src/resolve/resolved-dns-scope.c:41
   #2 0x555df67b in link_allocate_scopes src/resolve/resolved-link.c:89
   #3 0x555e0933 in link_update_monitor src/resolve/resolved-link.c:248
   #4 0x555cc591 in manager_process_link src/resolve/resolved-manager.c:78
   #5 0x555cd267 in manager_rtnl_listen src/resolve/resolved-manager.c:235
   #6 0x555cefbc in manager_new src/resolve/resolved-manager.c:498
   #7 0x555cba15 in main src/resolve/resolved.c:75
   #8 0x75d6586f in __libc_start_main (/lib64/libc.so.6+0x2086f)

SUMMARY: AddressSanitizer: heap-use-after-free
src/resolve/resolved-dns-cache.c:88 dns_cache_flush
Shadow bytes around the buggy address:
 0x0c187fff9750: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
 0x0c187fff9760: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
 0x0c187fff9770: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
 0x0c187fff9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
 0x0c187fff9790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=0x0c187fff97a0: fa fa fa fa fa fa fa fa fd fd fd fd[fd]fd fd fd
 0x0c187fff97b0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
 0x0c187fff97c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0c187fff97d0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
 0x0c187fff97e0: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
 0x0c187fff97f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
 Addressable:   00
 Partially addressable: 01 02 03 04 05 06 07
 Heap left redzone:   fa
 Heap right redzone:  fb
 Freed heap region:   fd
 Stack left redzone:  f1
 Stack mid redzone:   f2
 Stack right redzone: f3
 Stack partial redzone:   f4
 Stack after return:  f5
 Stack use after scope:   f8
 Global redzone:  f9
 Global init order:   f6
 Poisoned by user:f7
 Container overflow:  fc
 Array cookie:ac
 Intra object redzone:bb
 ASan internal:   fe
==33557==ABORTING

apparently, it crashes on

void dns_cache_flush(DnsCache *c) {
   DnsCacheItem *i;

   assert(c);

   while ((i = hashmap_first(c-by_key))) -- here, because
c-by_key was already free'd at this point.. can someone familiar thr
the code look at this ?


to reproduce, build with --enable-address-sanitizer , start resolved
in gdb .. then send SIGTERM to the running binary..
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] core: fix memory leak in manager_run_generators()

2015-05-11 Thread Cristian Rodríguez
If systemd is built with GCC address sanitizer or leak sanitizer
the following memory leak ocurs:

May 12 02:02:46 linux.site systemd[326]: 
=
May 12 02:02:46 linux.site systemd[326]: ==326==ERROR: LeakSanitizer: detected 
memory leaks
May 12 02:02:46 linux.site systemd[326]: Direct leak of 101 byte(s) in 3 
object(s) allocated from:
May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup 
(/usr/lib64/libasan.so.2+0x6293f)
May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5336 in strv_new_ap 
src/shared/strv.c:163
May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new 
src/shared/strv.c:185
May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths 
src/shared/path-lookup.c:223
May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in 
manager_run_generators src/core/manager.c:2828
May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup 
src/core/manager.c:1121
May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main 
src/core/main.c:1667
May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main 
(/lib64/libc.so.6+0x208c4)
May 12 02:02:46 linux.site systemd[326]: Direct leak of 29 byte(s) in 1 
object(s) allocated from:
May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup 
(/usr/lib64/libasan.so.2+0x6293f)
May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5288 in strv_new_ap 
src/shared/strv.c:152
May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new 
src/shared/strv.c:185
May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths 
src/shared/path-lookup.c:223
May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in 
manager_run_generators src/core/manager.c:2828
May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup 
src/core/manager.c:1121
May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main 
src/core/main.c:1667
May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main 
(/lib64/libc.so.6+0x208c4)
May 12 02:02:46 linux.site systemd[326]: SUMMARY: AddressSanitizer: 130 byte(s) 
leaked in 4 allocation(s).

There is a leak due to the the use of cleanup_free instead _cleanup_strv_free_
---
 src/core/manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/manager.c b/src/core/manager.c
index 28b9427..8254090 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2815,7 +2815,7 @@ static void trim_generator_dir(Manager *m, char 
**generator) {
 }
 
 static int manager_run_generators(Manager *m) {
-_cleanup_free_ char **paths = NULL;
+_cleanup_strv_free_ char **paths = NULL;
 const char *argv[5];
 char **path;
 int r;
-- 
2.3.7

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


[systemd-devel] [PATCH] sd-bus: fix memory leak in test-bus-chat

2015-05-09 Thread Cristian Rodríguez
Building with address sanitizer enabled on GCC 5.1.x a memory leak
is reported because we never close the bus, fix it by using
cleanup variable attribute.
---
 src/libsystemd/sd-bus/test-bus-chat.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/libsystemd/sd-bus/test-bus-chat.c 
b/src/libsystemd/sd-bus/test-bus-chat.c
index 99261fa..1e50dfc 100644
--- a/src/libsystemd/sd-bus/test-bus-chat.c
+++ b/src/libsystemd/sd-bus/test-bus-chat.c
@@ -262,7 +262,7 @@ fail:
 
 static void* client1(void*p) {
 _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
-sd_bus *bus = NULL;
+_cleanup_bus_close_unref_ sd_bus *bus = NULL;
 sd_bus_error error = SD_BUS_ERROR_NULL;
 const char *hello;
 int r;
@@ -345,8 +345,6 @@ finish:
 else
 sd_bus_send(bus, q, NULL);
 
-sd_bus_flush(bus);
-sd_bus_unref(bus);
 }
 
 sd_bus_error_free(error);
-- 
2.3.7

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


[systemd-devel] [PATCH] buildsys: *_la_CPPFLAGS takes $(AM_CPPFLAGS) not $(AM_CFLAGS)

2015-05-09 Thread Cristian Rodríguez
---
 Makefile.am | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 1ec1e77..e4d00a8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6333,7 +6333,7 @@ libsystemd_journal_la_SOURCES = \
src/compat-libs/libsystemd-journal.sym
 
 libsystemd_journal_la_CPPFLAGS = \
-   $(AM_CFLAGS) \
+   $(AM_CPPFLAGS) \
-imacros$(top_srcdir)/src/compat-libs/linkwarning.h
 
 libsystemd_journal_la_LDFLAGS = \
@@ -6351,7 +6351,7 @@ libsystemd_login_la_SOURCES = \
src/compat-libs/libsystemd-login.sym
 
 libsystemd_login_la_CPPFLAGS = \
-   $(AM_CFLAGS) \
+   $(AM_CPPFLAGS) \
-imacros$(top_srcdir)/src/compat-libs/linkwarning.h
 
 libsystemd_login_la_LDFLAGS = \
@@ -6368,7 +6368,7 @@ libsystemd_id128_la_SOURCES = \
src/compat-libs/libsystemd-id128.sym
 
 libsystemd_id128_la_CPPFLAGS = \
-   $(AM_CFLAGS) \
+   $(AM_CPPFLAGS) \
-imacros$(top_srcdir)/src/compat-libs/linkwarning.h
 
 libsystemd_id128_la_LDFLAGS = \
@@ -6385,7 +6385,7 @@ libsystemd_daemon_la_SOURCES = \
src/compat-libs/libsystemd-daemon.sym
 
 libsystemd_daemon_la_CPPFLAGS = \
-   $(AM_CFLAGS) \
+   $(AM_CPPFLAGS) \
-imacros$(top_srcdir)/src/compat-libs/linkwarning.h
 
 libsystemd_daemon_la_LDFLAGS = \
-- 
2.3.7

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


[systemd-devel] [PATCH] po: Remove src/fsckd/fsckd.c from filelist

2015-05-05 Thread Cristian Rodríguez
Otherwise make check ends in failed state.
---
 po/POTFILES.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index 70e7594..b4c1121 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -5,4 +5,3 @@ src/locale/org.freedesktop.locale1.policy.in
 src/login/org.freedesktop.login1.policy.in
 src/machine/org.freedesktop.machine1.policy.in
 src/timedate/org.freedesktop.timedate1.policy.in
-src/fsckd/fsckd.c
-- 
2.3.7

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


[systemd-devel] [PATCH] tree-wide: Introduce a dup_cloexec inline helper

2015-04-22 Thread Cristian Rodríguez
- Nicer  easier to remember than fcntl(fd, F_DUPFD_CLOEXEC, 3)
- Update CODING_STYLE
- Use it tree-wide
---
 CODING_STYLE | 6 +++---
 src/import/curl-util.c   | 2 +-
 src/import/importd.c | 4 ++--
 src/journal/cat.c| 2 +-
 src/libsystemd-terminal/grdev-drm.c  | 4 ++--
 src/libsystemd-terminal/idev-evdev.c | 4 ++--
 src/libsystemd/sd-bus/bus-message.c  | 6 +++---
 src/login/inhibit.c  | 2 +-
 src/login/pam_systemd.c  | 2 +-
 src/run/run.c| 2 +-
 src/shared/copy.c| 2 +-
 src/shared/fdset.c   | 2 +-
 src/shared/install.c | 2 +-
 src/shared/util.h| 5 +
 14 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/CODING_STYLE b/CODING_STYLE
index a295ca7..19891ce 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -233,12 +233,12 @@
   fork()ed off a child process, please use _exit() instead of exit(),
   so that the exit handlers are not run.
 
-- Please never use dup(). Use fcntl(fd, F_DUPFD_CLOEXEC, 3)
-  instead. For two reason: first, you want O_CLOEXEC set on the new fd
+- Please never use dup(). Use the dup_cloexec() helper instead.
+  For two reasons: first, you want O_CLOEXEC set on the new fd
   (see above). Second, dup() will happily duplicate your fd as 0, 1,
   2, i.e. stdin, stdout, stderr, should those fds be closed. Given the
   special semantics of those fds, it's probably a good idea to avoid
-  them. F_DUPFD_CLOEXEC with 3 as parameter avoids them.
+  them.
 
 - When you define a destructor or unref() call for an object, please
   accept a NULL object and simply treat this as NOP. This is similar
diff --git a/src/import/curl-util.c b/src/import/curl-util.c
index d390cfb..dfa5acc 100644
--- a/src/import/curl-util.c
+++ b/src/import/curl-util.c
@@ -131,7 +131,7 @@ static int curl_glue_socket_callback(CURLM *curl, 
curl_socket_t s, int action, v
  * anymore. Hence, duplicate the fds here, and keep a
  * copy for epoll which we control after use. */
 
-fd = fcntl(s, F_DUPFD_CLOEXEC, 3);
+fd = dup_cloexec(s);
 if (fd  0)
 return -1;
 
diff --git a/src/import/importd.c b/src/import/importd.c
index d4da4b2..416a43c 100644
--- a/src/import/importd.c
+++ b/src/import/importd.c
@@ -765,7 +765,7 @@ static int method_import_tar_or_raw(sd_bus *bus, 
sd_bus_message *msg, void *user
 if (!t-local)
 return -ENOMEM;
 
-t-stdin_fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+t-stdin_fd = dup_cloexec(fd);
 if (t-stdin_fd  0)
 return -errno;
 
@@ -826,7 +826,7 @@ static int method_export_tar_or_raw(sd_bus *bus, 
sd_bus_message *msg, void *user
 if (!t-local)
 return -ENOMEM;
 
-t-stdout_fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+t-stdout_fd = dup_cloexec(fd);
 if (t-stdout_fd  0)
 return -errno;
 
diff --git a/src/journal/cat.c b/src/journal/cat.c
index 2e236f0..9e26e7c 100644
--- a/src/journal/cat.c
+++ b/src/journal/cat.c
@@ -138,7 +138,7 @@ int main(int argc, char *argv[]) {
 goto finish;
 }
 
-saved_stderr = fcntl(STDERR_FILENO, F_DUPFD_CLOEXEC, 3);
+saved_stderr = dup_cloexec(STDERR_FILENO);
 
 if (dup3(fd, STDOUT_FILENO, 0)  0 ||
 dup3(fd, STDERR_FILENO, 0)  0) {
diff --git a/src/libsystemd-terminal/grdev-drm.c 
b/src/libsystemd-terminal/grdev-drm.c
index 066a4d8..deb7e94 100644
--- a/src/libsystemd-terminal/grdev-drm.c
+++ b/src/libsystemd-terminal/grdev-drm.c
@@ -2782,7 +2782,7 @@ static int managed_card_resume_device_fn(sd_bus *bus,
  * TakeDevice(). However, lets be safe and use this FD in case
  * we really don't have one. There is no harm in doing this
  * and our code works fine this way. */
-fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+fd = dup_cloexec(fd);
 if (fd  0) {
 log_debug_errno(errno, grdrm: %s/%s: cannot duplicate 
fd: %m,
 session-name, cm-card.base.name);
@@ -2874,7 +2874,7 @@ static int managed_card_take_device_fn(sd_bus *bus,
 return 0;
 }
 
-fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+fd = dup_cloexec(fd);
 if (fd  0) {
 log_debug_errno(errno, grdrm: %s/%s: cannot duplicate fd: %m,
 session-name, cm-card.base.name);
diff --git a/src/libsystemd-terminal/idev-evdev.c 
b/src/libsystemd-terminal/idev-evdev.c
index 91ae507..c49ba90 100644
--- a/src/libsystemd-terminal/idev-evdev.c
+++ b/src/libsystemd-terminal/idev-evdev.c
@@ -559,7 +559,7 @@ static int managed_evdev_take_device_fn(sd_bus *bus,
 if (paused)
 return 0;
 
-fd = fcntl(fd, 

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

2015-04-17 Thread Cristian Rodríguez
On Fri, Apr 17, 2015 at 7:51 AM, Lennart Poettering
lenn...@poettering.net wrote:

 Groups *suck* as authentication scheme. If you add one group for each
 privilege you want, then you'll have a huge number of groups, and
 that's hardly desirable. It's pretty close to being unmanagable with
 user/group editors. Also, you can never take group membership away,
 since users who once where members of group can create sgid binaries
 which allows them to always return into that group forever.

Not to mention, we are running out of system users and groups in
distributions (if we didn't already) and some people want us to
provide fixed UID/GID system users
across distributions for clustering applications...this is a totally
unworkable way forward.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

2015-04-17 Thread Cristian Rodríguez
On Fri, Apr 17, 2015 at 4:06 PM, Matt Hoosier matt.hoos...@gmail.com wrote:
 On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering
 lenn...@poettering.net wrote:

 On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@gmail.com) wrote:

  Hi,
 
  I'm writing to see whether there's a best way to allow systemd to
  inherit
  ownership of a process forked from a hand-crafted /sbin/init process
  before
  that hand-crafted process turns over the keys to systemd by doing
  exec(/lib/systemd/systemd) over the top of itself and allowing it to
  take
  over as PID 1.

 We support this only really for kernel-like processes that are
 started from the initrd, and basically run as long as the system is up
 without every being restarted in between, thus effectively appearing
 much like a kernel process and nothing systemd should
 manage. Processes like this should be marked with argv[0][0] = '@',
 see for details:

 https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/

  I know that sounds like an odd thing to ask about. The use-case has to
  do
  with being able to start some work extremely early during boot of
  embedded
  systems to achieve performance goals. I don't wish to subvert systemd,
  and
  in fact would love for systemd to be able to monitor the process, stop
  it,
  restart according to the normal [Service] configuration in a unit file
  describing the process.

 Hmm, are you sure that invoking the binary from systemd as first
 service is really that much slower than starting systemd only afterwards?


 The bootcharting that I do seems to show that about 1.2 - 1.5 sec are spent
 internal to systemd before any external processes get run for the particular
 embedded CPU I'm using. That gap is a killer at the moment.

Did you watch this presentation ?

https://www.youtube.com/watch?v=RFVlbaDqll8

what part of systemd is taking 1.5 seconds to start, on what CPU and
how much of RAM does the board has ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Check if systems is container in systemd-remount-fs.service

2015-04-08 Thread Cristian Rodríguez
On Wed, Apr 8, 2015 at 6:55 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 17.03.15 10:54, Peter Paule (systemd-de...@fedux.org) wrote:

 Hi,

 does it make sense to check if the system is started as a container in
 systemd-remount-fs.service and only start the service if the system is NOT
 a container?

 Why?
The service always fail when running in a container.. for example

systemd-nspawn -D / -xb

Apr 08 23:59:30 xps15z systemd-remount-fs[16]: /bin/mount for / exited
with exit status 1.
Apr 08 23:59:30 xps15z systemd-remount-fs[16]: mount: can't find
UUID=01a467ea-82ff-4d5a-a8a1-f2fb4e797ea0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd

2015-03-02 Thread Cristian Rodríguez
On Mon, Mar 2, 2015 at 12:48 PM, Jordan Hargrave jhar...@gmail.com wrote:
 It would be nice if systemd could discover and display enclosure/bay slot
 mappings for drives in the system.  The /dev/disk/by-path method doesn't
 quite work, for SAS drives the ID can change on hotplug.  The slot mapping
 also doesn't handle PCIe SSD devices as they are bare block devices and
 don't use SCSI midlayer.  Proposing to add support for something like
 /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices.

As far as I am aware, no new things dealing with storage naming rules
will be added to udev/systemd, it has to go to whatever other
project..(sg3_utils last time I checked)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] journal: fix Inappropriate ioctl for device on ext4

2015-03-01 Thread Cristian Rodríguez
Logs constantly show

systemd-journald[395]: Failed to set file attributes: Inappropriate
ioctl for device

This is because ext4 does not support FS_NOCOW_FL.
---
 src/journal/journal-file.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 9c9a548..ecabfd3 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -2610,7 +2610,8 @@ int journal_file_open(
  * checksumming). */
 r = chattr_fd(f-fd, true, FS_NOCOW_FL);
 if (r  0)
-log_warning_errno(errno, Failed to set file 
attributes: %m);
+if(r != -ENOTTY)
+log_warning_errno(errno, Failed to set file 
attributes: %m);
 
 /* Let's attach the creation time to the journal file,
  * so that the vacuuming code knows the age of this
-- 
2.3.0

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


Re: [systemd-devel] tmpfiles.d specifier support on argument when operating on files

2015-03-01 Thread Cristian Rodríguez
On Wed, Feb 18, 2015 at 6:17 PM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:

 Is the attached version cool for you ?

Ping ? Any comments about this one ? note that implementing the
specifier expansion in all cases for argument does not make sense to
me unless I am missing something .
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] feature request: dlopen

2015-02-22 Thread Cristian Rodríguez

El 22/02/15 a las 23:08, Luke Kenneth Casson Leighton escribió:


  the problem, zbigniew, is that the intended use of this silent noop
feature - to make it *possible* to have an alternative PID1 - *hasn't
happened*.  any upstream software developer who has added in support
for systemd has done so by *ripping out* the former alternative code.
not a single upstream system that i've seen has done *any* kind of
run-time detection *at all*.  it's all compile-time.


This is because software is written mostly by sane people who has at 
least a clue about what they are doing and talking, they are not doing 
what you wish, because what you are proposing is batshit insane.




  aside from getting the message across to upstream developers about
doing runtime detection, i feel that what you guys really need to do
is to set up conferences with everyone, to talk - urgently - about
ways to ensure that the alternative systems which the wholesale
adoption of systemd has excluded may be reinstated as *runtime*
choices (not compile-time).


Ha! that's a funny one.. why should we do that? the burden on doing that 
is on the people that want this theorical alternatives.


 that may mean discussing a set of APIs

that end up being DL'd (like PAM is, right now),


PAM is not dlopen'ed.. pam *modules* are.. and PAM is not something to 
cite as an example how to do things *today* in 2015..



the situation now is one where people believe that systemd is being
heavily promoted to the exclusion of all other PID1 alternatives,
developed with a focus on fedora / redhat to the exclusion of all
other distros, developed for desktop systems *only* to the exclusion
of servers and embedded systems... it's no wonder that there's a lot
of upset people in the software libre community!


You dropped your tinfoil hat now..


  i know it sounds weird to go backwards, but the situation is -
amongst other not very nice things - that the GNU/Linux world now has
a new monoculture attack vector at the PID1 level in code that's
being *actively developed and extended, dramatically*.



Please go and learn how and particulary *why* things work a certain way 
before telling people how to do it, in fact don't tell.. .post patches 
or experiment yourself.


You can dlopen systemd libraries at your own risk, if you know exactly 
what you are doing and why it will work..in most cases it will end in a 
terrible mess that we will get the blame for it.. I just wrote a patch 
to disallow dlopen of libsystemd alltogether..I hope it won't be needed 
because I still trust developers not to be that misguided.









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


Re: [systemd-devel] feature request: dlopen

2015-02-22 Thread Cristian Rodríguez

El 22/02/15 a las 22:37, Luke Kenneth Casson Leighton escribió:



  well, you could provide hints in the documentation (and force them to
be read by deliberately changing the API)


Wow.. so what you want is even nuttier than I thought..


that would be a good place to start, showing people how to begin the
process of dlopen()ing libsystemd0, documenting it well so that it was
easy to follow.


No, again. using dlopen with libsystemd is crazy, you will only turn 
software even more complex and ugly than already is. and with this 
little gem:


-- a/Makefile.am
+++ b/Makefile.am
@@ -3046,7 +3046,7 @@ libsystemd_la_CFLAGS = \
$(libsystemd_journal_internal_la_CFLAGS)

 libsystemd_la_LDFLAGS = \
-   $(AM_LDFLAGS) \
+   $(AM_LDFLAGS) -Wl,-z,nodlopen \

we can stop the madness from becoming reality :-)



  * distros are forced to follow suit on upstream decisions, without
consulting what any other distros do


No, distros are welcome to come here and influence the direction of the 
project and its components, before reality imposes itself. those who do 
the work, make decisions.




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


[systemd-devel] [PATCH] shared: fix wrong assertion in barrier_set_role()

2015-02-20 Thread Cristian Rodríguez
 assert(b-pipe[0] = 0  b-pipe[0] = 0);

Test the same condition twice, pretty sure we mean

 assert(b-pipe[0] = 0  b-pipe[1] = 0);
---
 src/shared/barrier.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/shared/barrier.c b/src/shared/barrier.c
index f65363a..b7dca75 100644
--- a/src/shared/barrier.c
+++ b/src/shared/barrier.c
@@ -178,7 +178,7 @@ void barrier_set_role(Barrier *b, unsigned int role) {
 assert(b);
 assert(role == BARRIER_PARENT || role == BARRIER_CHILD);
 /* make sure this is only called once */
-assert(b-pipe[1] = 0  b-pipe[1] = 0);
+assert(b-pipe[0] = 0  b-pipe[1] = 0);
 
 if (role == BARRIER_PARENT)
 b-pipe[1] = safe_close(b-pipe[1]);
-- 
2.3.0

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


[systemd-devel] [PATCH 8/9] shared: AFS is also a network filesystem

2015-02-20 Thread Cristian Rodríguez
---
 src/shared/util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/shared/util.c b/src/shared/util.c
index dc65280..6729461 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1692,6 +1692,7 @@ bool chars_intersect(const char *a, const char *b) {
 
 bool fstype_is_network(const char *fstype) {
 static const char table[] =
+afs\0
 cifs\0
 smbfs\0
 sshfs\0
-- 
2.3.0

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


Re: [systemd-devel] [PATCH] build-sys: add configure option to disable LTO/gold

2015-02-18 Thread Cristian Rodríguez

El 18/02/15 a las 15:58, Lennart Poettering escribió:

On Wed, 18.02.15 15:45, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:


LTO may be unreliable, does not work properly in several archs
It may crash or produce wrong code.


Well, that's something to fix in the LTO code.


Compiler developers also said we should not provide production
RPM packages with LTO enabled.


We have been doing that for a number of releases on Fedora. Seems to
work fine.


Yes, it works in x86_64, except we need to produce working -debuginfo 
packages and LTO produces unusable debug infos..


Anyway,,currently this is not suitable for us at all. let me explain a 
bit...


Building systemd is affected by this GCC bug (not in fread but *poll)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886

We can't just ignore the warnings like warning: call to ‘__*_chk_warn’ 
declared with attribute warning: poll called with fds buffer too small 
file nfds entries why ? The openSUSE buildsystem considers this 
warnings as security holes and the package is automatically marked as 
failed and is automatically rejected for inclusion.


So we currently disable LTO with a patch, not as nice as the one I posted.




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


Re: [systemd-devel] tmpfiles.d specifier support on argument when operating on files

2015-02-18 Thread Cristian Rodríguez

El 18/02/15 a las 07:10, Lennart Poettering escribió:

On Tue, 17.02.15 17:35, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

Please fix this for all arguments, not just symlinks.






Thanks for taking a look, I will post a complete version later. ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] /run conf_file_dirs are never created

2015-02-17 Thread Cristian Rodríguez

Hi:

It appears that with the exception of /run/tmpfiles.d , the rest of the 
volatile conf_file_dirs are never created at boot. Is this intentional ?

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


Re: [systemd-devel] tmpfiles.d specifier support on argument when operating on files

2015-02-17 Thread Cristian Rodríguez

El 17/02/15 a las 15:38, Cristian Rodríguez escribió:

HI:

In openSUSE, we have per *running kernel* sysctl snippets, currently
implemented as patch on systemd-sysctl.. I 'm currently attempting to
replace it for something sane..like

d /run/sysctl.d
L/run/sysctl.d/00-sysctl.conf-%v ----
/boot/sysctl.conf-%v

BUt argument does not support specifier expasion when dealing with
path names.. would you take patches for this ?

Thanks.




Ok, this patch works for my usecase..



From 10f9c96bb40834191765bd19f313ab17d18e3b31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?= crrodrig...@opensuse.org
Date: Tue, 17 Feb 2015 17:34:17 -0300
Subject: [PATCH] tmpfiles: add specifier support for the create symlink
 argument

---
 src/tmpfiles/tmpfiles.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index c948d4d..1b35b8e 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1590,6 +1590,12 @@ static int parse_line(const char *fname, unsigned line, const char *buffer) {
 i.argument = strappend(/usr/share/factory/, i.path);
 if (!i.argument)
 return log_oom();
+} else {
+r = specifier_printf(i.argument, specifier_table, NULL, i.argument);
+if (r  0) {
+log_error([%s:%u] Failed to replace specifiers: %s, fname, line, path);
+return r;
+}
 }
 break;
 
-- 
2.2.2

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


[systemd-devel] tmpfiles.d specifier support on argument when operating on files

2015-02-17 Thread Cristian Rodríguez

HI:

In openSUSE, we have per *running kernel* sysctl snippets, currently 
implemented as patch on systemd-sysctl.. I 'm currently attempting to 
replace it for something sane..like


d /run/sysctl.d
L/run/sysctl.d/00-sysctl.conf-%v ----   /boot/sysctl.conf-%v

BUt argument does not support specifier expasion when dealing with 
path names.. would you take patches for this ?


Thanks.


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


Re: [systemd-devel] [PATCH] build-sys: Lookup for the location of agetty

2015-02-16 Thread Cristian Rodríguez

El 16/02/15 a las 14:46, Jóhann B. Guðmundsson escribió:


On 02/16/2015 05:40 PM, Lennart Poettering wrote:

On Mon, 16.02.15 17:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:


On 02/16/2015 03:42 PM, Cristian Rodríguez wrote:

May be in /sbin or /usr/sbin

You might want to resubmit this to including the 57600 baud rate request
from Jeff in the process ( 115200,57600,38400,9600 )  ;)

Hmm, Details


57600 Baud Rate is commonly used ( and recommended from vendors even
used as failsafe baud rate ) so it should have been including in the
list from the get go

Did you just forget to include back in the day it or did deliberately
leave it out?


I deliberately left it out since the baud rate thing is a different problem.


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


[systemd-devel] [PATCH] units: add ConditionKernelCommandLine=resume

2015-02-16 Thread Cristian Rodríguez
If there is no resume= ..it is not possible to
hubrid-sleep or hibernate
---
 units/systemd-hibernate.service.in| 1 +
 units/systemd-hybrid-sleep.service.in | 1 +
 2 files changed, 2 insertions(+)

diff --git a/units/systemd-hibernate.service.in 
b/units/systemd-hibernate.service.in
index 29d9b69..2a21cfc 100644
--- a/units/systemd-hibernate.service.in
+++ b/units/systemd-hibernate.service.in
@@ -11,6 +11,7 @@ Documentation=man:systemd-suspend.service(8)
 DefaultDependencies=no
 Requires=sleep.target
 After=sleep.target
+ConditionKernelCommandLine=resume
 
 [Service]
 Type=oneshot
diff --git a/units/systemd-hybrid-sleep.service.in 
b/units/systemd-hybrid-sleep.service.in
index 914b686..b3039a0 100644
--- a/units/systemd-hybrid-sleep.service.in
+++ b/units/systemd-hybrid-sleep.service.in
@@ -11,6 +11,7 @@ Documentation=man:systemd-suspend.service(8)
 DefaultDependencies=no
 Requires=sleep.target
 After=sleep.target
+ConditionKernelCommandLine=resume
 
 [Service]
 Type=oneshot
-- 
2.2.2

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


[systemd-devel] [PATCH] build-sys: Lookup for the location of agetty

2015-02-16 Thread Cristian Rodríguez
May be in /sbin or /usr/sbin
---
 Makefile.am  | 1 +
 configure.ac | 2 ++
 units/console-getty.service.m4.in| 2 +-
 units/container-ge...@.service.m4.in | 2 +-
 units/getty@.service.m4  | 2 +-
 units/serial-getty@.service.m4   | 2 +-
 6 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index bf04d31..50da86c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6240,6 +6240,7 @@ substitutions = \
'|udevlibexecdir=$(udevlibexecdir)|' \
'|SUSHELL=$(SUSHELL)|' \
'|SULOGIN=$(SULOGIN)|' \
+   '|AGETTY=$(AGETTY)|' \
'|DEBUGTTY=$(DEBUGTTY)|' \
'|KILL=$(KILL)|' \
'|KMOD=$(KMOD)|' \
diff --git a/configure.ac b/configure.ac
index 97a29d6..8d434cf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -100,6 +100,8 @@ AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], 
[$PATH:/usr/sbin:/sbin])
 
 AC_PATH_PROG([SULOGIN], [sulogin], [/usr/sbin/sulogin], 
[$PATH:/usr/sbin:/sbin])
 
+AC_PATH_PROG([AGETTY], [agetty], [/usr/sbin/agetty], [$PATH:/usr/sbin:/sbin])
+
 AS_IF([! ln --relative --help  /dev/null 21], [AC_MSG_ERROR([*** ln doesn't 
support --relative ***])])
 
 M4_DEFINES=
diff --git a/units/console-getty.service.m4.in 
b/units/console-getty.service.m4.in
index 8ac51a4..b12810e 100644
--- a/units/console-getty.service.m4.in
+++ b/units/console-getty.service.m4.in
@@ -15,7 +15,7 @@ After=rc-local.service
 Before=getty.target
 
 [Service]
-ExecStart=-/sbin/agetty --noclear --keep-baud console 115200,38400,9600 $TERM
+ExecStart=-@AGETTY@ --noclear --keep-baud console 115200,38400,9600 $TERM
 Type=idle
 Restart=always
 RestartSec=0
diff --git a/units/container-ge...@.service.m4.in 
b/units/container-ge...@.service.m4.in
index e126f3a..127abaf 100644
--- a/units/container-ge...@.service.m4.in
+++ b/units/container-ge...@.service.m4.in
@@ -17,7 +17,7 @@ IgnoreOnIsolate=yes
 ConditionPathExists=/dev/pts/%I
 
 [Service]
-ExecStart=-/sbin/agetty --noclear --keep-baud pts/%I 115200,38400,9600 $TERM
+ExecStart=-@AGETTY@ --noclear --keep-baud pts/%I 115200,38400,9600 $TERM
 Type=idle
 Restart=always
 RestartSec=0
diff --git a/units/getty@.service.m4 b/units/getty@.service.m4
index 46164ab..e1a418a 100644
--- a/units/getty@.service.m4
+++ b/units/getty@.service.m4
@@ -27,7 +27,7 @@ ConditionPathExists=/dev/tty0
 
 [Service]
 # the VT is cleared by TTYVTDisallocate
-ExecStart=-/sbin/agetty --noclear %I $TERM
+ExecStart=-@AGETTY@ --noclear %I $TERM
 Type=idle
 Restart=always
 RestartSec=0
diff --git a/units/serial-getty@.service.m4 b/units/serial-getty@.service.m4
index 4522d0d..bafbbb2 100644
--- a/units/serial-getty@.service.m4
+++ b/units/serial-getty@.service.m4
@@ -22,7 +22,7 @@ Before=getty.target
 IgnoreOnIsolate=yes
 
 [Service]
-ExecStart=-/sbin/agetty --keep-baud 115200,38400,9600 %I $TERM
+ExecStart=-@AGETTY@ --keep-baud 115200,38400,9600 %I $TERM
 Type=idle
 Restart=always
 UtmpIdentifier=%I
-- 
2.2.2

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


[systemd-devel] [PATCH 5/5] sd-bus: add missing format attribute

2015-02-15 Thread Cristian Rodríguez
---
 src/systemd/sd-bus.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/systemd/sd-bus.h b/src/systemd/sd-bus.h
index 2420d0c..ca2d83e 100644
--- a/src/systemd/sd-bus.h
+++ b/src/systemd/sd-bus.h
@@ -371,7 +371,7 @@ int sd_bus_error_setf(sd_bus_error *e, const char *name, 
const char *format, ...
 int sd_bus_error_set_const(sd_bus_error *e, const char *name, const char 
*message);
 int sd_bus_error_set_errno(sd_bus_error *e, int error);
 int sd_bus_error_set_errnof(sd_bus_error *e, int error, const char *format, 
...) _sd_printf_(3, 4);
-int sd_bus_error_set_errnofv(sd_bus_error *e, int error, const char *format, 
va_list ap);
+int sd_bus_error_set_errnofv(sd_bus_error *e, int error, const char *format, 
va_list ap) _sd_printf_(3,0);
 int sd_bus_error_get_errno(const sd_bus_error *e);
 int sd_bus_error_copy(sd_bus_error *dest, const sd_bus_error *e);
 int sd_bus_error_is_set(const sd_bus_error *e);
-- 
2.2.2

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


Re: [systemd-devel] [PATCH 3/3] core: remove unneeded libgen.h include

2015-02-11 Thread Cristian Rodríguez

El 11/02/15 a las 14:26, Lennart Poettering escribió:

On Wed, 11.02.15 18:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:



So, hmm, so if I got this right:

a) The good basame() is in strings.h
b) The bad basename() is in libgen.h
c) The only other call in libgen.h is dirname()


There is another problem to keep an eye on.. dirname() may modify its 
argument.. only the GNU basename() version never does, no such warranty 
exists for dirname. so dirname callers must strdup(a) just in case the 
library does something stupid behind our backs..


I was tempted to post a patch vanishing all uses of dirname() replacing 
it by dirname_malloc() ...





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


[systemd-devel] [PATCH 4/4] Always use recvmsg with MSG_CMSG_CLOEXEC

2015-02-10 Thread Cristian Rodríguez
---
 src/libsystemd-network/sd-dhcp-client.c | 2 +-
 src/libsystemd-network/sd-dhcp-server.c | 2 +-
 src/libsystemd/sd-rtnl/rtnl-message.c   | 4 ++--
 src/libudev/libudev-monitor.c   | 2 +-
 src/machine/machine-dbus.c  | 2 +-
 src/resolve/resolved-manager.c  | 2 +-
 src/shutdownd/shutdownd.c   | 2 +-
 src/timesync/timesyncd-manager.c| 2 +-
 src/udev/udev-ctrl.c| 2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp-client.c 
b/src/libsystemd-network/sd-dhcp-client.c
index 5f90617..2f76e24 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -1582,7 +1582,7 @@ static int client_receive_message_raw(sd_event_source *s, 
int fd,
 iov.iov_base = packet;
 iov.iov_len = buflen;
 
-len = recvmsg(fd, msg, 0);
+len = recvmsg(fd, msg, MSG_CMSG_CLOEXEC);
 if (len  0) {
 log_dhcp_client(client, could not receive message from raw 
 socket: %m);
diff --git a/src/libsystemd-network/sd-dhcp-server.c 
b/src/libsystemd-network/sd-dhcp-server.c
index 3f89f34..1cb782f 100644
--- a/src/libsystemd-network/sd-dhcp-server.c
+++ b/src/libsystemd-network/sd-dhcp-server.c
@@ -897,7 +897,7 @@ static int server_receive_message(sd_event_source *s, int 
fd,
 iov.iov_base = message;
 iov.iov_len = buflen;
 
-len = recvmsg(fd, msg, 0);
+len = recvmsg(fd, msg, MSG_CMSG_CLOEXEC);
 if (len  buflen)
 return 0;
 else if ((size_t)len  sizeof(DHCPMessage))
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c 
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 276591f..e7e3799 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -1431,7 +1431,7 @@ static int socket_recv_message(int fd, struct iovec *iov, 
uint32_t *_group, bool
 assert(fd = 0);
 assert(iov);
 
-r = recvmsg(fd, msg, MSG_TRUNC | (peek ? MSG_PEEK : 0));
+r = recvmsg(fd, msg, MSG_TRUNC | MSG_CMSG_CLOEXEC | (peek ? MSG_PEEK 
: 0));
 if (r  0) {
 /* no data */
 if (errno == ENOBUFS)
@@ -1467,7 +1467,7 @@ static int socket_recv_message(int fd, struct iovec *iov, 
uint32_t *_group, bool
 /* not from the kernel, ignore */
 if (peek) {
 /* drop the message */
-r = recvmsg(fd, msg, 0);
+r = recvmsg(fd, msg, MSG_CMSG_CLOEXEC);
 if (r  0)
 return (errno == EAGAIN || errno == EINTR) ? 0 
: -errno;
 }
diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
index 08ddde8..82ce7f6 100644
--- a/src/libudev/libudev-monitor.c
+++ b/src/libudev/libudev-monitor.c
@@ -600,7 +600,7 @@ retry:
 smsg.msg_name = snl;
 smsg.msg_namelen = sizeof(snl);
 
-buflen = recvmsg(udev_monitor-sock, smsg, 0);
+buflen = recvmsg(udev_monitor-sock, smsg, MSG_CMSG_CLOEXEC);
 if (buflen  0) {
 if (errno != EINTR)
 log_debug(unable to receive message);
diff --git a/src/machine/machine-dbus.c b/src/machine/machine-dbus.c
index b46f0a8..da8e6c0 100644
--- a/src/machine/machine-dbus.c
+++ b/src/machine/machine-dbus.c
@@ -255,7 +255,7 @@ int bus_machine_method_get_addresses(sd_bus *bus, 
sd_bus_message *message, void
 iov[0] = (struct iovec) { .iov_base = family, .iov_len = 
sizeof(family) };
 iov[1] = (struct iovec) { .iov_base = in_addr, .iov_len = 
sizeof(in_addr) };
 
-n = recvmsg(pair[0], mh, 0);
+n = recvmsg(pair[0], mh, MSG_CMSG_CLOEXEC);
 if (n  0)
 return sd_bus_error_set_errno(error, -errno);
 if ((size_t) n  sizeof(family))
diff --git a/src/resolve/resolved-manager.c b/src/resolve/resolved-manager.c
index 890cc04..d5c1bf0 100644
--- a/src/resolve/resolved-manager.c
+++ b/src/resolve/resolved-manager.c
@@ -892,7 +892,7 @@ int manager_recv(Manager *m, int fd, DnsProtocol protocol, 
DnsPacket **ret) {
 mh.msg_control = control;
 mh.msg_controllen = sizeof(control);
 
-l = recvmsg(fd, mh, 0);
+l = recvmsg(fd, mh, MSG_CMSG_CLOEXEC);
 if (l  0) {
 if (errno == EAGAIN || errno == EINTR)
 return 0;
diff --git a/src/shutdownd/shutdownd.c b/src/shutdownd/shutdownd.c
index 826efbf..6eb522b 100644
--- a/src/shutdownd/shutdownd.c
+++ b/src/shutdownd/shutdownd.c
@@ -69,7 +69,7 @@ static int read_packet(int fd, union shutdown_buffer *_b) {
 assert(fd = 0);
 assert(_b);
 
-n = recvmsg(fd, msghdr, MSG_DONTWAIT);
+n = recvmsg(fd, msghdr, MSG_DONTWAIT|MSG_CMSG_CLOEXEC);
 if (n = 0) {
 if (n == 0) 

Re: [systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random

2015-02-02 Thread Cristian Rodríguez

El 02/02/15 a las 12:42, Lennart Poettering escribió:


I'd prefer if we'd change the check instead to only apply to
S_ISREG() files. This way we wouldn't have to list all RNG device
nodes.


Yeah.. the other version I had did a !S_ISCHR check but S_ISREG is more 
adequate in this case.



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


[systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random

2015-02-02 Thread Cristian Rodríguez
Using /dev/urandom as a key is valid for swap, do not
warn if this devices are world readable.
---
 src/cryptsetup/cryptsetup.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index e6b37ac..38930ae 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -624,8 +624,10 @@ int main(int argc, char *argv[]) {
 
 /* Ideally we'd do this on the open fd, but since this 
is just a
  * warning it's OK to do this in two steps. */
-if (stat(key_file, st) = 0  (st.st_mode  0005))
-log_warning(Key file %s is world-readable. 
This is not a good idea!, key_file);
+if (stat(key_file, st) = 0  (st.st_mode  0005)) {
+if(!STR_IN_SET(key_file, /dev/urandom, 
/dev/random, /dev/hw_random))
+log_warning(Key file %s is 
world-readable. This is not a good idea!, key_file);
+}
 }
 
 for (tries = 0; arg_tries == 0 || tries  arg_tries; tries++) {
-- 
2.2.2

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


Re: [systemd-devel] [PATCH] timesyncd: Make saving clock to disk on NTP fix optional

2015-02-01 Thread Cristian Rodríguez
El 01/02/2015 06:36, Kay Sievers k...@vrfy.org escribió:

 On Feb 1, 2015 5:34 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
wrote:
 
  Kay, Lennart,
  comments?

 Sounds like overkill to me for such an exotic requirement. Just link the
file to /dev/null and be done?

Yeah, I do not see the point on providing this option,  only the file
timestamp is updated. That causes very little io.
Symlink to null is the best solution IMHO.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] timesyncd: tighten unit file

2015-02-01 Thread Cristian Rodríguez

El 27/01/15 a las 21:18, Lennart Poettering escribió:

On Tue, 27.01.15 15:12, Cameron Norman (camerontnor...@gmail.com) wrote:


Lennart: if you really want to test the profile, you just need to spin
up an OpenSuSE, Ubuntu, or Debian VM (on debian you need to install
and enable apparmor, which takes a short while).


Well, I have no personal interest in AppArmor, and I really have
enough stuff to do. If AA shall be supported in systemd, then I am
happy to merge stuff for it, if it is reviewed properly, but I am not
the one to test it. Sorry...



Hi Lennart:

To make apparmor work, only the initial policy loading bits (like 
selinux, smack..etc) needs to be implemented..currently it is done by 
some really ugly init script.Appamor policies however, just like the 
case of selinux have to go somewhere else, namely the apparmor upstream 
repository.





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


[systemd-devel] crash after commit core: make setting the shutdown watchdog configuration via dbus work

2015-01-29 Thread Cristian Rodríguez

hi:


systemd crashes after that commit with

gdb --args ./systemd

Failed to create root cgroup hierarchy: Permission denied
Failed to allocate manager object: Permission denied

Program received signal SIGSEGV, Segmentation fault.
0x55574ec4 in main (argc=1, argv=0x7fffdac8) at 
src/core/main.c:1832

1832arg_shutdown_watchdog = m-shutdown_watchdog;


gdb) p m
$3 = (Manager *) 0x0

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


[systemd-devel] [PATCH] build-sys: use -fno-semantic-interposition if available

2015-01-25 Thread Cristian Rodríguez
GCC5 introduces -fno-semantic-interposition allowing
better code generation in shared libraries at the cost
of making interposition of exported symbols impossible
(i.e, a 3rd party shared library overriding sd_notify() will not work)
Using this particular feature with systemd is not supported
and crazy, so do not pay the cost of it.
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index 12e4ab2..e4d7c05 100644
--- a/configure.ac
+++ b/configure.ac
@@ -199,6 +199,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
 -fdata-sections \
 -fstack-protector \
 -fstack-protector-strong \
+-fno-semantic-interposition \
 -fPIE \
 --param=ssp-buffer-size=4])
 
-- 
2.2.2

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


[systemd-devel] [PATCH] build-sys: lookup for sulogin, it might not be in /sbin

2015-01-23 Thread Cristian Rodríguez
---
 Makefile.am   | 1 +
 configure.ac  | 2 ++
 units/console-shell.service.m4.in | 2 +-
 units/emergency.service.in| 2 +-
 units/rescue.service.in   | 2 +-
 5 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 45d7a34..c463f23 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6220,6 +6220,7 @@ substitutions = \
'|rootprefix=$(rootprefix)|' \
'|udevlibexecdir=$(udevlibexecdir)|' \
'|SUSHELL=$(SUSHELL)|' \
+   '|SULOGIN=$(SULOGIN)|' \
'|DEBUGTTY=$(DEBUGTTY)|' \
'|KILL=$(KILL)|' \
'|KMOD=$(KMOD)|' \
diff --git a/configure.ac b/configure.ac
index 6bd095c..12e4ab2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -98,6 +98,8 @@ AC_PATH_PROG([KMOD], [kmod], [/usr/bin/kmod], 
[$PATH:/usr/sbin:/sbin])
 
 AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], [$PATH:/usr/sbin:/sbin])
 
+AC_PATH_PROG([SULOGIN], [sulogin], [/usr/sbin/sulogin], 
[$PATH:/usr/sbin:/sbin])
+
 AS_IF([! ln --relative --help  /dev/null 21], [AC_MSG_ERROR([*** ln doesn't 
support --relative ***])])
 
 M4_DEFINES=
diff --git a/units/console-shell.service.m4.in 
b/units/console-shell.service.m4.in
index 3f4904a..5c80722 100644
--- a/units/console-shell.service.m4.in
+++ b/units/console-shell.service.m4.in
@@ -17,7 +17,7 @@ Before=getty.target
 [Service]
 Environment=HOME=/root
 WorkingDirectory=/root
-ExecStart=-/sbin/sulogin
+ExecStart=-@SULOGIN@
 ExecStopPost=-@SYSTEMCTL@ poweroff
 Type=idle
 StandardInput=tty-force
diff --git a/units/emergency.service.in b/units/emergency.service.in
index 18973e7..2695d7b 100644
--- a/units/emergency.service.in
+++ b/units/emergency.service.in
@@ -18,7 +18,7 @@ Environment=HOME=/root
 WorkingDirectory=/root
 ExecStartPre=-/bin/plymouth quit
 ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, type 
journalctl -xb to view\\nsystem logs, systemctl reboot to reboot, 
systemctl default or ^D to\\ntry again to boot into default mode.'
-ExecStart=-/bin/sh -c /sbin/sulogin; @SYSTEMCTL@ --fail --no-block default
+ExecStart=-/bin/sh -c @SULOGIN@; @SYSTEMCTL@ --fail --no-block default
 Type=idle
 StandardInput=tty-force
 StandardOutput=inherit
diff --git a/units/rescue.service.in b/units/rescue.service.in
index fc93f1e..de73fee 100644
--- a/units/rescue.service.in
+++ b/units/rescue.service.in
@@ -18,7 +18,7 @@ Environment=HOME=/root
 WorkingDirectory=/root
 ExecStartPre=-/bin/plymouth quit
 ExecStartPre=-/bin/echo -e 'Welcome to emergency mode! After logging in, type 
journalctl -xb to view\\nsystem logs, systemctl reboot to reboot, 
systemctl default or ^D to\\nboot into default mode.'
-ExecStart=-/bin/sh -c /sbin/sulogin; @SYSTEMCTL@ --fail --no-block default
+ExecStart=-/bin/sh -c @SULOGIN@; @SYSTEMCTL@ --fail --no-block default
 Type=idle
 StandardInput=tty-force
 StandardOutput=inherit
-- 
2.2.2

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


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Cristian Rodríguez

El 23/01/15 a las 14:52, Lennart Poettering escribió:

On Fri, 23.01.15 12:27, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:


El 23/01/15 a las 10:31, Lennart Poettering escribió:


The rc-local generator only exists to add compat support for those
systems where it never was a sysvinit script anyway...



They are not init scripts though. but plain shell scripts with no dependency
information. they are installed in /etc/init.d, therefore we end with units
generated by both the sysv-generator and the rc-local generator.


Hmm? Are you talking about Debian or Suse now? I kinda assumed that if
Debian places it in /etc/init.d, that it is a proper sysvinit script...


SUSE has this scripts..

Extra start script: /etc/init.d/boot.local
Extra stop script:   /etc/init.d/halt.local

The are not init scripts, but legacy shell scripts that naive people 
insist on wanting to use.

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


Re: [systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-23 Thread Cristian Rodríguez

El 23/01/15 a las 10:31, Lennart Poettering escribió:


The rc-local generator only exists to add compat support for those
systems where it never was a sysvinit script anyway...



They are not init scripts though. but plain shell scripts with no 
dependency information. they are installed in /etc/init.d, therefore we 
end with units generated by both the sysv-generator and the rc-local 
generator.


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


[systemd-devel] [PATCH] mount-setup: Do not bother with /proc/bus/usb

2015-01-23 Thread Cristian Rodríguez
Current systemd requires kernel = 3.7 per the README file
but CONFIG_USB_DEVICEFS disappeared from the kernel in
upstream commit fb28d58b72aa9215b26f1d5478462af394a4d253
(kernel 3.5-rc1)
---
 src/core/mount-setup.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index 5919f77..521545e 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -120,8 +120,6 @@ static const MountPoint mount_table[] = {
 static const char ignore_paths[] =
 /* SELinux file systems */
 /sys/fs/selinux\0
-/* Legacy kernel file system */
-/proc/bus/usb\0
 /* Container bind mounts */
 /proc/sys\0
 /dev/console\0
-- 
2.2.2

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


[systemd-devel] [PATCH] sysv-generator: Do not generate units for files handled by rc-local generator

2015-01-22 Thread Cristian Rodríguez
---
 src/sysv-generator/sysv-generator.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/sysv-generator/sysv-generator.c 
b/src/sysv-generator/sysv-generator.c
index b8b77aa..d6e4dfa 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -775,6 +775,14 @@ static int enumerate_sysv(LookupPaths lp, Hashmap 
*all_services) {
 fpath = strjoin(*path, /, de-d_name, NULL);
 if (!fpath)
 return log_oom();
+#ifdef RC_LOCAL_SCRIPT_PATH_START
+if(streq(fpath, RC_LOCAL_SCRIPT_PATH_START))
+continue;
+#endif
+#ifdef RC_LOCAL_SCRIPT_PATH_STOP
+if(streq(fpath, RC_LOCAL_SCRIPT_PATH_STOP))
+continue;
+#endif
 
 if (hashmap_contains(all_services, name))
 continue;
-- 
2.2.1

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


Re: [systemd-devel] systemd build process, stripped ELF flags (MIPS)

2015-01-19 Thread Cristian Rodríguez

El 19/01/15 a las 05:47, Manuel Lauss escribió:


The systemd build process manages to create binaries without this
.MIPS.abiflags section, and this leads the 3.18 kernel to refuse to load it:


Nope, the build process does no such thing, your toolchain is buggy, 
wild guess is that --gc-sections does not know that section is mandatory 
and removes it.


Please talk about this with binutils developers ;-)


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


Re: [systemd-devel] Readahead collect - root filesystem only?

2015-01-15 Thread Cristian Rodríguez

El 15/01/15 a las 09:38, Nikolai Zhubr escribió:

Hi all,

Is it true that readahead collector defaults to only collect files
within root filesystem?

If so, is it possible to instruct it to also collect for e.g. /home
(mounted on a separate media)?

This is not mentioned anywhere in the docs. It probably should be?


The readahead collector is no longer included in systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Readahead collect - root filesystem only?

2015-01-15 Thread Cristian Rodríguez

El 15/01/15 a las 10:40, Nikolai Zhubr escribió:

Hi,
15.01.2015 16:07, Cristian Rodríguez:

The readahead collector is no longer included in systemd.



Hm. It is still there in not-very-old opensuse 13.2 ...


for whatever reason, current openSUSE releases have systemd 210.. that's 
old.



Anyway. Where has it gone then? Is it a separate tool now or got
obsoleted by something else?


It is gone, has no replacement.


I actually just started to like it... Quite a usefull thing...


Not very useful unfortunately,


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


[systemd-devel] [PATCH 3/3] remove RUN_WITH_LOCALE et all, use extended locale functions instead

2015-01-14 Thread Cristian Rodríguez
There were two callers, one can use strtod_l() and the other strptime_l()
---
 src/import/curl-util.c | 38 +++---
 src/shared/util.c  | 18 +-
 src/shared/util.h  | 26 --
 3 files changed, 36 insertions(+), 46 deletions(-)

diff --git a/src/import/curl-util.c b/src/import/curl-util.c
index 0c6c867..bbb68f7 100644
--- a/src/import/curl-util.c
+++ b/src/import/curl-util.c
@@ -418,27 +418,35 @@ int curl_header_strdup(const void *contents, size_t sz, 
const char *field, char
 int curl_parse_http_time(const char *t, usec_t *ret) {
 struct tm tm;
 time_t v;
+const char *e;
+locale_t loc;
 
 assert(t);
 assert(ret);
 
-RUN_WITH_LOCALE(LC_TIME, C) {
-const char *e;
-
-/* RFC822 */
-e = strptime(t, %a, %d %b %Y %H:%M:%S %Z, tm);
-if (!e || *e != 0)
-/* RFC 850 */
-e = strptime(t, %A, %d-%b-%y %H:%M:%S %Z, tm);
-if (!e || *e != 0)
-/* ANSI C */
-e = strptime(t, %a %b %d %H:%M:%S %Y, tm);
-if (!e || *e != 0)
-return -EINVAL;
-
-v = timegm(tm);
+loc = newlocale (LC_TIME_MASK, C, (locale_t)0);
+
+if (loc == (locale_t) 0)
+return -errno;
+
+/* RFC822 */
+e = strptime_l(t, %a, %d %b %Y %H:%M:%S %Z, tm, loc);
+
+if (!e || *e != 0)
+/* RFC 850 */
+e = strptime_l(t, %A, %d-%b-%y %H:%M:%S %Z, tm, loc);
+if (!e || *e != 0)
+/* ANSI C */
+e = strptime_l(t, %a %b %d %H:%M:%S %Y, tm, loc);
+if (!e || *e != 0) {
+freelocale(loc);
+return -EINVAL;
 }
 
+freelocale(loc);
+
+v = timegm(tm);
+
 if (v == (time_t) -1)
 return -EINVAL;
 
diff --git a/src/shared/util.c b/src/shared/util.c
index 884e782..599f3ca 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -507,19 +507,27 @@ int safe_atolli(const char *s, long long int *ret_lli) {
 int safe_atod(const char *s, double *ret_d) {
 char *x = NULL;
 double d = 0;
+locale_t loc;
 
 assert(s);
 assert(ret_d);
 
-RUN_WITH_LOCALE(LC_NUMERIC_MASK, C) {
-errno = 0;
-d = strtod(s, x);
-}
+loc = newlocale (LC_NUMERIC_MASK, C, (locale_t)0);
 
-if (!x || x == s || *x || errno)
+if(loc == (locale_t)0)
+return -errno;
+
+errno = 0;
+d = strtod_l(s, x, loc);
+
+if (!x || x == s || *x || errno) {
+freelocale(loc);
 return errno ? -errno : -EINVAL;
+}
 
 *ret_d = (double) d;
+freelocale(loc);
+
 return 0;
 }
 
diff --git a/src/shared/util.h b/src/shared/util.h
index fdb9fb6..8445371 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -942,32 +942,6 @@ int unlink_noerrno(const char *path);
 _r_;\
 })
 
-struct _locale_struct_ {
-locale_t saved_locale;
-locale_t new_locale;
-bool quit;
-};
-
-static inline void _reset_locale_(struct _locale_struct_ *s) {
-PROTECT_ERRNO;
-if (s-saved_locale != (locale_t) 0)
-uselocale(s-saved_locale);
-if (s-new_locale != (locale_t) 0)
-freelocale(s-new_locale);
-}
-
-#define RUN_WITH_LOCALE(mask, loc) \
-for (_cleanup_(_reset_locale_) struct _locale_struct_ _saved_locale_ = 
{ (locale_t) 0, (locale_t) 0, false }; \
- ({ \
- if (!_saved_locale_.quit) {\
- PROTECT_ERRNO; \
- _saved_locale_.new_locale = newlocale((mask), 
(loc), (locale_t) 0); \
- if (_saved_locale_.new_locale != (locale_t) 0)
 \
- _saved_locale_.saved_locale = 
uselocale(_saved_locale_.new_locale); \
- }  \
- !_saved_locale_.quit; }) ; \
- _saved_locale_.quit = true)
-
 bool id128_is_valid(const char *s) _pure_;
 
 int split_pair(const char *s, const char *sep, char **l, char **r);
-- 
2.2.1

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


Re: [systemd-devel] [PATCH] sysv-generator: only allow regular files in enumerate_sysv()

2015-01-14 Thread Cristian Rodríguez

El 14/01/15 a las 10:39, Colin Guthrie escribió:

Cristian Rodríguez wrote on 14/01/15 13:34:

El 14/01/15 a las 09:21, Colin Guthrie escribió:

If I read the dirent_ensure_type and dirent_is_file code properly, this
would mean that symlinks to valid sysvinit scripts are now skipped.


dirent_is_file() returns true for symlinks.


Jeez, I really failed at reading the code today sorry for the noise!

(that said, as a general question what happens in dirent_is_file() if
there is a symlink to a directory?)

Col



The other way around in this case is to ignore EISDIR like ENOENT is 
ignored in load_sysv()

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


[systemd-devel] [PATCH 1/2] remove unneeded libgen.h includes

2015-01-14 Thread Cristian Rodríguez
---
 src/core/mount-setup.c| 1 -
 src/journal/catalog.c | 1 -
 src/test/test-namespace.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index bd3a035..eb9641f 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -24,7 +24,6 @@
 #include sys/stat.h
 #include stdlib.h
 #include string.h
-#include libgen.h
 #include assert.h
 #include unistd.h
 #include ftw.h
diff --git a/src/journal/catalog.c b/src/journal/catalog.c
index 81a2e94..f170232 100644
--- a/src/journal/catalog.c
+++ b/src/journal/catalog.c
@@ -26,7 +26,6 @@
 #include string.h
 #include sys/mman.h
 #include locale.h
-#include libgen.h
 
 #include util.h
 #include log.h
diff --git a/src/test/test-namespace.c b/src/test/test-namespace.c
index e74fd0c..084a58f 100644
--- a/src/test/test-namespace.c
+++ b/src/test/test-namespace.c
@@ -19,7 +19,6 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
-#include libgen.h
 #include sys/socket.h
 
 #include namespace.h
-- 
2.2.1

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


[systemd-devel] [PATCH] sysv-generator: only allow regular files in enumerate_sysv()

2015-01-13 Thread Cristian Rodríguez
Otherwise, if the directory contains other directories we fail
at fopen in load_sysv() with EISDIR.
---
 src/sysv-generator/sysv-generator.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/sysv-generator/sysv-generator.c 
b/src/sysv-generator/sysv-generator.c
index 2f24ef2..e15a16b 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -727,8 +727,10 @@ static int enumerate_sysv(LookupPaths lp, Hashmap 
*all_services) {
 _cleanup_free_ char *fpath = NULL, *name = NULL;
 int r;
 
-if (hidden_file(de-d_name))
-continue;
+dirent_ensure_type(d, de);
+
+if (!dirent_is_file(de))
+continue;
 
 fpath = strjoin(*path, /, de-d_name, NULL);
 if (!fpath)
-- 
2.2.1

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


[systemd-devel] [PATCH 1/2] machinectl: use GNU basename, not the XPG version

2015-01-11 Thread Cristian Rodríguez
---
 src/machine/machinectl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/machine/machinectl.c b/src/machine/machinectl.c
index 749170e..980fba1 100644
--- a/src/machine/machinectl.c
+++ b/src/machine/machinectl.c
@@ -32,7 +32,7 @@
 #include net/if.h
 #include sys/mount.h
 #include libgen.h
-
+#undef basename
 #include sd-bus.h
 #include log.h
 #include util.h
-- 
2.2.1

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


Re: [systemd-devel] Second (erroneous) check of rootfs?

2015-01-07 Thread Cristian Rodríguez

El 07/01/15 a las 21:43, Lennart Poettering escribió:


Maybe suse forgot to include this service file in the initrd or so?


Correct. It appears to be a bug in the dracut package. I wonder why ..

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


Re: [systemd-devel] Second (erroneous) check of rootfs?

2015-01-07 Thread Cristian Rodríguez

El 07/01/15 a las 22:55, Nikolai Zhubr escribió:

08.01.2015 4:12, Cristian Rodríguez:

El 07/01/15 a las 21:43, Lennart Poettering escribió:


Maybe suse forgot to include this service file in the initrd or so?


Correct. It appears to be a bug in the dracut package. I wonder why ..


Ok. So should I file a report to opensuse bugtracker?


Yes, against BaseSystem component.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Second (erroneous) check of rootfs?

2015-01-07 Thread Cristian Rodríguez

El 07/01/15 a las 22:55, Nikolai Zhubr escribió:

08.01.2015 4:12, Cristian Rodríguez:

El 07/01/15 a las 21:43, Lennart Poettering escribió:


Maybe suse forgot to include this service file in the initrd or so?


Correct. It appears to be a bug in the dracut package. I wonder why ..


Ok. So should I file a report to opensuse bugtracker? I have no idea if
the issue is suse-specific actually... Although I know that dracut is
very new for suse, that might explain it...


Hrmm.. looking at the dracut upstream sources.. this service is not 
included in the required file list. so it is an upstream problem.


Attached is a patch to fix the problem.


From 81b8f407d84cb60e9d4df0e2f68b4bd3850448f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?= crrodrig...@opensuse.org
Date: Wed, 7 Jan 2015 23:22:00 -0300
Subject: [PATCH] 98systemd: Include systemd-root-fsck.service too

---
 modules.d/98systemd/module-setup.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/modules.d/98systemd/module-setup.sh b/modules.d/98systemd/module-setup.sh
index 51ea288..a28df30 100755
--- a/modules.d/98systemd/module-setup.sh
+++ b/modules.d/98systemd/module-setup.sh
@@ -91,6 +91,7 @@ install() {
 $systemdsystemunitdir/systemd-reboot.service \
 $systemdsystemunitdir/systemd-kexec.service \
 $systemdsystemunitdir/systemd-fsck@.service \
+$systemdsystemunitdir/systemd-fsck-root.service \
 $systemdsystemunitdir/systemd-udevd.service \
 $systemdsystemunitdir/systemd-udev-trigger.service \
 $systemdsystemunitdir/systemd-udev-settle.service \
-- 
2.2.1

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


[systemd-devel] [PATCH] timesync: remove square(), use pow instead

2014-12-23 Thread Cristian Rodríguez
In any case, the compiler generates the same code inline and never
actually calls the library function.
---
 src/timesync/timesyncd-manager.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index ef5854d..117ea8c 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -147,10 +147,6 @@ static double ts_to_d(const struct timespec *ts) {
 return ts-tv_sec + (1.0e-9 * ts-tv_nsec);
 }
 
-static double square(double d) {
-return d * d;
-}
-
 static int manager_timeout(sd_event_source *source, usec_t usec, void 
*userdata) {
 _cleanup_free_ char *pretty = NULL;
 Manager *m = userdata;
@@ -428,7 +424,7 @@ static bool manager_sample_spike_detection(Manager *m, 
double offset, double del
 
 j = 0;
 for (i = 0; i  ELEMENTSOF(m-samples); i++)
-j += square(m-samples[i].offset - m-samples[idx_min].offset);
+j += pow(m-samples[i].offset - m-samples[idx_min].offset, 2);
 m-samples_jitter = sqrt(j / (ELEMENTSOF(m-samples) - 1));
 
 /* ignore samples when resyncing */
-- 
2.2.0

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


  1   2   3   >