GNU = inventions that nobody wants?

Stumbled over this today on GNU/Linux, output from ps -fp :

UID        PID  PPID  C STIME TTY          TIME CMD
root      3516     1  0  2017 ?        00:00:13 syslogd -m 0
UID        PID  PPID  C STIME TTY          TIME CMD
syslog    2952     1  0  2017 ?        00:02:08 rsyslogd

STIME showing 2017? Who needs this gimmick? We have January 2018!
Much better on Unix:

     UID   PID  PPID   C    STIME TTY         TIME CMD
    root   906     1   0   Dec 16 ?           0:07 /usr/sbin/syslogd

May not be too satisfying, but that's the documented behaviour for ( man ps )

Using e.g. start or bsdstart as format specifiers, it will (presumably) behave like the Unix example that you gave above.

Ah yes, the non-standard "START" and "BSDSTART" say it correctly

ps -p 3516 -o stime,start,bsdstart,lstart,etime
STIME  STARTED  START                  STARTED     ELAPSED
 2017   Dec 19 Dec 19 Tue Dec 19 17:10:57 2017 15-21:43:58

But a casual ps -f gives STIME and that's unusable.
A bit more intelligent would have been to check the "etime" and switch to the year if the etime is > 360 days.

Interesting. To be honest i find the behavior of df -h much more annoying. Here is my PC:

# df -h
Filesystem                 Size  Used Avail Use% Mounted on
udev                        63G     0   63G   0% /dev
tmpfs                       13G   11M   13G   1% /run
/dev/mapper/rootvg-rootlv  9.8G  5.6G  3.7G  61% /
tmpfs                       63G  168K   63G   1% /dev/shm
tmpfs                      5.0M  4.0K  5.0M   1% /run/lock
tmpfs                       63G     0   63G   0% /sys/fs/cgroup
/dev/mapper/rootvg-altrlv  9.8G  8.2G  1.2G  88% /altroot
/dev/mapper/rootvg-homelv  9.8G  2.4G  7.0G  25% /home
/dev/mapper/rootvg-imglv    49G  6.5G   41G  14% /opt/images
/dev/sda1                  511M  4.6M  507M   1% /boot/efi
tmpfs                       13G   16K   13G   1% /run/user/1000

First: I would like to see the filesystems not all sorts of gimmicks. The output of mount is equally unusable, because ones wades through lists of "virtual filesystems", which are no filesystems at all.

But what takes the biscuit is the different units in which the output is formatted: MB, GB and even KB all mixed together and you have no immediate picture what is filled to which extent. In AIX i use df -g and know what i want to know within a second.

bakunin

df -Bg should work

Thanks a lot, i didn't know that. This still leaves the "tmpfs" entries and the "udev", but at least one of the problems is solved. Good catch!

bakunin

df -Bg -xtmpfs -xdevtmpfs ! Getting a tad unwieldy, but I guess you could alias it.

On systemd mount output is even worse on linux systems.

Debian home system, multiuser, hot seat, two gpu and 2 independent users.
There is one volume group (root) with one lvol and separate disk with one partition.

In my opinion, this is just wrong way to do things.
All the filesystems present on the machine are ext4.

root@box:~# mount -t ext4 | wc -l
3
root@box:~# mount | wc -l
37 # it's a party...
root@box:~# df -t ext4 | wc -l
4
root@box:~# df | wc -l
12

But i guess that is todays good enough ...

Regards
Peasant.

I understand your rant and frustration but they are file systems too in the sense they allow accessing directories and (possibly virtual) files, and are mounted somewhere. Implementations of the "df" command are required to show each and every mounted file system but the standard says nothing about virtual ones:

Moreover, this thread is named "GNU = inventions that nobody wants" while GNU is not responsible at all about all these virtual file systems which are implemented by the Linux kernel and its modules. On the opposite, GNU df is already filtering out by default several file systems not to pollute too much its output.
Try "df -a" on a GNU/Linux box to see what I mean.

Finally, there are similar non disk partition backed file systems on non Linux systems too like for example Solaris where df reports a file system which is only used to overlay mount a single file on top of /lib/libc.so.1.